Tor / Onion Routing

Tor et le routage en oignon sont tous deux des réseaux mandataires d’anonymisation, permettant aux gens de tunnelliser par leur réseau de mélange à latence faible. Les deux principales différences entre Tor, le routage en oignon et I2P sont, encore une fois, liées à des différences dans le modèle de menaces et la conception du mandataire sortant (bien que Tor prenne aussi en charge les services cachés). De plus, Tor utilise une approche basée sur un annuaire, fournissant un point centralisé de gestion de la « vue » d’ensemble du réseau, recueille et rapporte aussi des statistiques, contrairement à la base de données de réseau distribuée d’I2P et la sélection de pairs.

La fonction de mandataire sortant d’I2P/Tor présente quelques faiblesses importantes contre certains assaillants. Une fois que la communication quitte le réseau de mélange, les adversaires passifs de partout peuvent plus facilement mettre en place une analyse du trafic. De plus, les mandataires sortants ont accès aux données en clair transférées dans les deux sens, et les mandataires sortants sont sujets aux abus, en plus de tous les autres problèmes de sécurité inhérents au trafic normal d’Internet, que nous avons appris à connaître et à aimer.

Cependant, la plupart des gens ne doivent pas s’inquiéter de ces situations, car elles ne correspondent pas à leur modèle de menace. Et cela dépasse aussi le champ d’action fonctionnel (officiel) d’I2P (si des personnes veulent construire une fonction de mandataire sortant par-dessus une couche de communication anonyme, elles le peuvent). En fait, certains utilisateurs d’I2P utilisent actuellement Tor comme mandataire sortant.

Comparaison de terminologie entre Tor et I2P

Alors que Tor et I2P sont similaires à bien des égards, une grande partie de la terminologie est différente.

Avantages de Tor sur I2P

• Plus grand nombre d’utilisateurs ; beaucoup plus de visibilité dans les communautés universitaires et hackers ; bénéficie d’études formelles d’anonymat, de résistance, et de performance ; a un chef de file universitaire non-anonyme, visible
• A déjà résolu certains problèmes d’échelle que I2P n’a pas eu encore à aborder
• A un financement important
• À plus de développeurs, dont plusieurs sont financés
• Plus résistant au blocage au niveau d’un État en raison de la couche transport TLS et des ponts (I2P a des propositions pour des "routes restreintes pleines" mais celles-ci ne sont pas encore mises en œuvre)
• Assez grand pour avoir dû s’adapter aux tentatives de blocage et de DOS
• Conçu et optimisé pour le trafic sortant, avec un grand nombre de nœuds de sortie
• Une meilleure documentation avec des articles et des spécifications formelles, un meilleur site Web, beaucoup plus de traductions
• Plus efficace concernant l’utilisation de la mémoire
• Les nœuds client de Tor ont une très faible surcharge de la bande passante
• Le contrôle centralisé réduit la complexité à chaque nœud et peut répondre efficacement à des attaques Sybil
• Un coeur de nœuds à grande capacité a la possibilité de fournir un plus haut débit tout en gardant une faible latence
• C, pas Java

Avantages d’I2P sur Tor

• Conçu et optimisé pour les services cachés, qui sont beaucoup plus rapide que dans Tor
• Entièrement distribué et auto-organisé
• Les pairs sont choisis par profilage continu et par classement de leurs performances, plutôt que de se contenter de faire confiance à la capacité qu’ils revendiquent
• Les pairs de remplissage par diffusion (serveurs annuaires) varient et ne sont pas fiables, plutôt que figés dans le code
• Tellement petit qu’il n’a pas été bloqué ni subi beaucoup de DOS, ou pas du tout
• Favorable au pair-à-pair
• Commutation de paquets à la place de commutation de circuit
  • équilibrage de charge transparent et implicite des messages à travers plusieurs pairs, plutôt que par un seul chemin
  • résistance contre les défaillances, ceci par exécution de plusieurs tunnels en parallèle, ainsi que par rotation des tunnels
  • s’adapte à l’échelle des connexions de chaque client à O(1) au lieu de O(N) (Alice a par exemple 2 tunnels entrants qui sont utilisés par tous les pairs avec lesquels parle Alice, plutôt qu’un circuit pour chaque)
• Tunnels unidirectionnels au lieu de circuits bidirectionnel, doublant le nombre de nœuds qu’un pair doit avoir à compromettre pour obtenir la même information. Contre-arguments et discussion plus poussée ici.
• Protection contre la détection de l’activité du client, même si un assaillant participe au tunnel, puisque les tunnels ne sont pas juste utilisés pour passer simplement des messages de bout en bout (p. ex. BDréseau, gestion de tunnels, test de tunnels)
• Dans I2P, les tunnels ont une durée de vie courte, diminuant ainsi le nombre d’échantillons qu’un assaillant peut utiliser pour lancer une attaque active, contrairement aux circuits dans Tor, qui ont généralement une durée de vie longue.
• Les API d’I2P sont conçues précisément pour assurer anonymat et sécurité, tandis que SOCKS est conçu pour la fonctionnalité.
• Par essence, tous les pairs participent à acheminer pour d’autres
• Être un pair à part entière ne présente qu’une faible surcharge de bande passante, alors que dans Tor, bien que les nœuds client n’exigent que peu de bande passante, ils ne participent pas complètement au réseau de mélange.
• Mécanisme intégré de mise à jour automatique
• Utilise à la fois les transports TCP et UDP
• Java, pas C

Autres avantages potentiels d’I2P, mais pas encore mis en œuvre

… et qui pourraient ne jamais être mis en œuvre, alors ne comptez pas sur eux !

• Défense contre l’analyse du nombre de messages par enveloppement en ail de plusieurs messages
• Défense contre intersection long terme en ajoutant des retards à différents sauts (où les retards ne sont pas discernables par d’autres sauts)
• Diverses stratégies de mélange au niveau du tunnel (par exemple créer un tunnel qui va gérer 500 messages / minute, dans lequel le point final va injecter des messages factices si il y a une nombre de messages insuffisant, etc)