i2p.www/www.i2p2/pages/how_networkcomparisons_fr.html

{% extends "_layout_fr.html" %}
{% block title %}I2P Comparé à Tor et à Freenet{% endblock %}
{% block content %}
Traduction d'avril 2011. <a href="how_networkcomparisons.html">Version anglaise actuelle</a>
<p>Il existe un grand nombre d'autres applications et projets centrés sur la communication anonyme 
et I2P s'est inspiré de beaucoup de leurs efforts. Ceci n'est pas une liste exhaustive de références à l'anonymat : 
tant la <a href="http://freehaven.net/anonbib/topic.html">Anonymity Bibliography</a> de freehaven que les 
<a href="https://www.gnunet.org/links/">projets relatifs</a> de GNUnet s'en acquittent très bien. Ceci dit, 
très peu de systèmes supportent longtemps la comparaison. Ils sont exposés ici :</p>
<ul>
<li>Tor / Onion Routing</li>
<li>Freenet</li>
</ul>
<p>Les suivants sont présentés sur la page <a href="othernetworks.html">autres réseaux</a></p> :
<ul>
<li>Morphmix et Tarzan</li>
<li>Mixminion / Mixmaster</li>
<li>JAP</li>
<li>MUTE / AntsP2P</li>
<li>Haystack</li>
</ul>

<p>Le contenu de cette page est susceptible de mises à jour, de discutions et de débats, et nous accueillons les 
commentaires et les compléments. Vous pouvez contribuer à l'analyse en soumettant un ticket sur 
<a href="http://trac.i2p2.de/report/1">trac.i2p2.de</a>.
</p>

<h2>Tor / Onion Routing</h2>
<i><a href="http://www.torproject.org/">[Tor]</a> 
   <a href="http://www.onion-router.net">[Onion Routing]</a></i>
<p>Tor et Onion Routing sont tous deux des réseaux de mandataires anonymisants, permettant à leurs utilisateurs des 
sorties de tunnels à travers leur réseau croisé à basse latence. Les deux principales différences entre Tor / 
Onion-Routing et I2P résident dans leur modèle de prise en compte des menaces et la conception des mandataires sortants 
(bien que Tor supporte aussi les services cachés). De plus, Tor adopte l'approche basée sur un annuaire - en 
fournissant un point central de gestion de la "vue" globale du réseau et de collecte/rapports de statistiques, à la 
différence de la <a href="how_networkdatabase">base de données</a> et de la <a href="how_peerselection">sélection 
des pairs</a>, décentralisées dans I2P.</p>

<p>La fonctionnalité de mandataire sortant I2P/Tor soufrent de quelques faiblesses non négligeables envers certains 
attaquants - une fois que la communication quitte le réseau croisé, des adversaires globaux passifs peuvent facilement 
monter des analyses de trafic. De plus, les mandataires sortant ont l'accès au texte en clair des données transférées 
dans les deux sens, et ils sont prédisposés à abuser de cette possibilité, à côté de tous les autres problèmes de 
sécurité que nous avons appris à connaître et à aimer sur l'Internet normal.</p>

<p>Cependant, de nombreuses personnes n'ont pas besoin de se soucier de ces situations, car elles sont en dehors de 
leurs référentiels de menaces. Mais c'est, il faut le noter, en dehors de l'étendue (formelle) fonctionnelle d'I2P (si 
des utilisateurs veulent ajouter une fonctionnalité de mandataire sortant au dessus de la couche de communication 
anonyme, ils peuvent). En fait, certains utilisateurs d'I2P bénéficient actuellement de Tor pour sortir du réseau par 
un mandataire.</p>
<!--
<p>Pour avoir une comparaison Tor/I2P du point de vue de Tor, consultez 
la <a href="http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#ComparisonI2P">FAQ de Tor</a>.</p>
-->

<h3>Comparaison des terminologies de Tor et d'I2P</h3>
Bien que Tor et I2P aient de nombreuses similarités, une grande part de leur terminologies respectives est différente.
<table>
<tr><th align="left">Tor<th align="left">I2P
<tr><td>Cellule<td>Message
<tr><td>Client<td>Router ou Client
<tr><td>Circuit<td>Tunnel
<tr><td>Directory<td>NetDb
<tr><td>Directory Server<td>Floodfill Router (diffuseurs)
<tr><td>Entry Guards<td>Pairs rapides
<tr><td>Entry Node<td>Mandataire entrant
<tr><td>Exit Node<td>Mandataire sortant
<tr><td>Hidden Service<td>Eepsite ou Destination
<tr><td>Hidden Service Descriptor<td>Jeux de baux
<tr><td>Introduction point<td>Passerelle entrante
<tr><td>Node<td>Router
<tr><td>Onion Proxy<td>Client I2PTunnel (grosso modo)
<tr><td>Relay<td>Router
<tr><td>Rendezvous Point<td>quelque chose comme la paire Passerelle entrante + Point terminal sortant
<tr><td>Router Descriptor<td>RouterInfo
<tr><td>Server<td>Router
</table>

<h3>Avantages de Tor sur I2P</h3>
<ul>
 <li>Base d'utilisateurs bien plus grosse; plus grande visibilité dans les communautés universitaires et de hackers ; 
bénéficie des études formelles sur l'anonymat, la résistance et les performances ; dispose d'un leader appuyé par 
l'université, non anonyme et visible</li>
 <li>A déjà résolu des problèmes d'échelle qu'I2P n'a pas encore à résoudre</li>
 <li>Dispose d'un financement significatif</li>
 <li>A plus de développeurs, dont plusieurs sont rémunérés</li>
 <li>Plus résistant aux blocages d'état (state-level) grâce à la couche transport TLS et aux ponts (I2P a des projets 
de routes réservés mais elles ne sont pas encore implémentées)</li>
 <li>Assez gros pour avoir déjà eu a s'adapter aux tentatives de blocage et de déni de service</li>
 <li>Conçu et optimisé pour le trafic sortant, avec un grand nombre de nœuds de sortie</li>
 <li>Meilleure documentation, avec ses articles formels et ses spécifications, meilleur site web, bien plus de 
traductions</li>
 <li>Plus efficace en utilisation mémoire</li>
 <li>Les nœuds clients Tor subissent une très légère surcharge de bande passante</li>
 <li>Le contrôle centralisé réduit la complexité de chaque nœud et résout efficacement les attaques de Sibylle</li>
 <li>Un noyau de nœuds à hautes capacités fournit un débit supérieur et une latence plus faible</li>
 <li>C, pas Java (beurk!)</li>
</ul>

<h3>Avantages d'I2P sur Tor</h3>
<ul>
 <li>Conçu et optimisé pour les services cachés, qui sont plus rapides que dans Tor</li>
 <li>Entièrement décentralisé et auto organisant</li>
 <li>Pairs sélectionnés par profilage continu et mesure des performances, plutôt que sur la foi des capacités annoncées
     </li>
 <li>Diffuseurs ("directory servers") changeants et sans relation de confiance, plutôt que codés en dur</li>
 <li>Assez petit pour n'avoir jamais été bloqué ni soumis à des DdS</li>
 <li>Gentiment <s>Pomme-à-Pomme</s>&hellip;<s>Poire-à-Poire</s>&hellip; bon, Peer-to-peer</li>
 <li>Un traducteur pour le français qui se la pète pas</li>
 <li>Commutation de paquets plutôt que commutation de circuits
  <ul>
   <li>Équilibrage de charge implicite transparent des messages à travers de multiples pairs, plutôt chemin unique </li>
   <li>Tolérance de pannes par parallélisme multi-tunnels et rotation des tunnels plutôt que pannes</li>
   <li>Dimensionne chaque connexion client à O(1) plutôt qu'à O(N) (Alice a p.ex 2 tunnels entrants qui sont utilisés 
par tous les pairs avec lesquels elle communique, plutôt qu'un circuit pour chacun)</li>
  </ul></li>
 <li>Tunnels Unidirectionnels plutôt que circuits bidirectionnels, doublant ainsi le nombre de nœuds à compromettre 
pour obtenir la même information</li>
 <li>Protection contre la détection de l'activité du client, même quand l'attaquant fait partie du tunnel car celui-ci 
fait plus que simplement passer les messages de bout en bout (netDB, gestion et test des tunnels)</li>
 <li>Tunnels à courte durée de vie, diminuant le nombre d'échantillons qu'un attaquant peut utiliser pour une attaque 
active, plutôt que des circuits à vie typiquement longue</li>
 <li>APIs I2P spécialement conçues pour l'anonymat et la sécurité, plutôt que SOCKS conçu pour les fonctionnalités</li>
 <li>Essentiellement tous les pairs participent au routage pour les autres</li>
 <li>Faible surcharge de bande passante d'un pair à part entière, plutôt que minime dans Tor où les nœuds ne 
participent pas pleinement au réseau croisé.</li>
 <li>Mécanisme intégré de mise à jour automatique</li>
 <li>Transports TCP et UDP</li>
 <li>Java, not C (beark!)</li>
</ul>

<h3>Autres bénéfices potentiels d'I2P, mais pas encore implémentés</h3>
<p>...et peut-être jamais implémentés, alors ne comptez pas dessus!</p>
<ul>
 <li>Protection contre les analyses de dénombrement de messages, grâce au regroupement de gousses de messages multiples
</li>
 <li>Protection contre les attaques d'intersection à long terme, par l'ajout de retards au niveau de divers sauts (où 
les retards sont indiscernables par les autres sauts)</li>
 <li>Diverses stratégies de mélange au niveau tunnel (p.e. créer un tunnel qui gèrera 500 messages/mn, dans lequel le 
point terminal injectera des messages bidons s'il n'y en a pas assez ,etc&hellip;)</li>
</ul>


<h2>Freenet</h2>
<i><a href="http://freenetproject.org/">[Freenet]</a></i>

<p>Freenet est un réseau de publication P2P anonyme et complètement décentralisé, offrant des moyens de stockage 
sécurisés, ainsi que quelques approches pour résoudre les surcharges d'inondation ponctuelles. Si Freenet est conçu en 
tant que système de stockage décentralisé, des utilisateurs ont développé des applications compatibles pour faire de la 
communication anonyme plus générique, comme des sites web statiques et des panneaux à messages.</p>

<p>Comparé à I2P, Freenet offre des avantages substantiels - il fait du stockage décentralisé quand I2P ne le fait pas, 
permettant aux utilisateurs de retrouver le contenu déposé par d'autres qui ne sont plus forcément en ligne. De plus, 
il devrait pouvoir distribuer des données populaires de façon plutôt efficaces. I2P lui-même ne fournit (et ne 
fournira) pas cette fonctionnalité. D'un autre côté, il y a un recouvrement pour les utilisateurs qui veulent 
simplement communiquer anonymement via des sites web, des tableaux de messages, du partage de fichiers etc&hellip; Il y 
aussi eu quelques tentatives de développement de stockage décentralisé pour I2P (plus récemment, un portage de 
<a href="http://tahoe-lafs.org/trac/tahoe-lafs">Tahoe-LAFS</a>) mais rien n'est prêt pour un usage général.</p>

<p>Cependant, même en faisant abstraction des problèmes de mise en œuvre, il reste quelques inquiétudes au sujet des 
algorithmes de Freenet d'un point de vue anonymat et adaptabilité au facteur d'échelle, comptant beaucoup sur le 
routage heuristique de Freenet. Les interactions des diverses techniques pourraient certainement vouer à l'échec 
certaines attaques, et peut-être que certains aspects des algorithmes de routages pourraient résoudre les espoirs 
d'adaptabilité d'échelle. Malheureusement, trop peu d'analyses des algorithmes concernés ont donné des résultats 
probants bien qu'il reste de l'espoir. Et pour finir, Freenet apporte un réel anonymat contre un attaquant ne 
possédant pas les ressources nécessaires pour l'analyser plus avant.</p>

{% endblock %}