NOTE : Ce document a été écrit à l’origine par jrandom en 2003. Bien que nous nous efforcions de le maintenir à jour, certaines informations peuvent être obsolètes ou incomplètes. Les sections transport et cryptographie sont à jour en date de janvier 2025.
Introduction
I2P est une couche réseau anonyme commutée par paquets, évolutive, auto-organisée et résiliente, sur laquelle peut fonctionner un nombre quelconque d’applications soucieuses de l’anonymat ou de la sécurité. Chacune de ces applications peut faire ses propres compromis entre anonymat, latence et débit sans se préoccuper de l’implémentation correcte d’un mixnet à route libre, leur permettant de mélanger leur activité avec l’ensemble d’anonymat plus large des utilisateurs fonctionnant déjà au-dessus d’I2P.
Les applications déjà disponibles offrent toute la gamme d’activités Internet typiques — navigation web anonyme, hébergement web, chat, partage de fichiers, courrier électronique, blogs et syndication de contenu, ainsi que plusieurs autres applications en cours de développement.
- Navigation web : utilisation de tout navigateur existant qui prend en charge l’utilisation d’un proxy.
- Chat : IRC et autres protocoles
- Partage de fichiers : I2PSnark et autres applications
- E-mail : susimail et autres applications
- Blog : utilisation de tout serveur web local, ou plugins disponibles
Contrairement aux sites web hébergés dans des réseaux de distribution de contenu comme Freenet ou GNUnet , les services hébergés sur I2P sont entièrement interactifs — il y a des moteurs de recherche web traditionnels, des forums de discussion, des blogs sur lesquels vous pouvez commenter, des sites pilotés par base de données, et des passerelles pour interroger des systèmes statiques comme Freenet sans avoir besoin de l’installer localement.
Avec toutes ces applications à anonymat activé, I2P joue le rôle d’un middleware orienté message — les applications indiquent qu’elles veulent envoyer des données vers un identifiant cryptographique (une “destination”) et I2P se charge de s’assurer que les données arrivent de manière sécurisée et anonyme. I2P inclut également une simple bibliothèque de streaming pour permettre aux messages anonymes au mieux effort d’I2P d’être transférés sous forme de flux fiables et ordonnés, offrant de manière transparente un algorithme de contrôle de congestion basé sur TCP ajusté pour le produit bande passante-délai élevé du réseau. Bien qu’il y ait eu plusieurs proxies SOCKS simples disponibles pour connecter les applications existantes au réseau, leur valeur a été limitée car presque chaque application expose régulièrement ce qui, dans un contexte anonyme, constitue des informations sensibles. La seule façon sûre de procéder est d’auditer complètement une application pour garantir un fonctionnement approprié et pour aider dans cette tâche, nous fournissons une série d’API dans divers langages qui peuvent être utilisées pour tirer le meilleur parti du réseau.
I2P n’est pas un projet de recherche — académique, commercial ou gouvernemental — mais plutôt un effort d’ingénierie visant à faire tout ce qui est nécessaire pour fournir un niveau suffisant d’anonymat à ceux qui en ont besoin. Il est en développement actif depuis début 2003 avec un développeur à temps plein et un groupe dévoué de contributeurs à temps partiel du monde entier. Tout le travail effectué sur I2P est open source et librement disponible sur le site web , avec la majorité du code publié directement dans le domaine public, bien qu’utilisant quelques routines cryptographiques sous des licences de style BSD. Les personnes travaillant sur I2P ne contrôlent pas sous quelles licences les gens publient les applications clientes, et il existe plusieurs applications sous licence GPL disponibles (I2PTunnel , susimail , I2PSnark , I2P-Bote, I2Phex et autres). Le financement d’I2P provient entièrement de dons, et ne bénéficie d’aucun avantage fiscal dans aucune juridiction actuellement, car beaucoup des développeurs sont eux-mêmes anonymes.
Fonctionnement
Aperçu
Pour comprendre le fonctionnement d’I2P, il est essentiel de comprendre quelques concepts clés. Premièrement, I2P fait une séparation stricte entre le logiciel qui participe au réseau (un “router”) et les points de terminaison anonymes (“destinations”) associés à des applications individuelles. Le fait que quelqu’un utilise I2P n’est généralement pas un secret. Ce qui est caché, c’est l’information sur ce que fait l’utilisateur, s’il fait quoi que ce soit, ainsi que quel router une destination particulière est connectée. Les utilisateurs finaux auront généralement plusieurs destinations locales sur leur router — par exemple, une qui fait du proxy vers des serveurs IRC, une autre qui prend en charge le serveur web anonyme de l’utilisateur (“I2P Site”), une autre pour une instance I2Phex, une autre pour les torrents, etc.
Un autre concept critique à comprendre est le “tunnel”. Un tunnel est un chemin dirigé à travers une liste explicitement sélectionnée de routers. Le chiffrement en couches est utilisé, de sorte que chacun des routers ne peut déchiffrer qu’une seule couche. L’information déchiffrée contient l’IP du router suivant, ainsi que l’information chiffrée à transmettre. Chaque tunnel a un point de départ (le premier router, aussi connu sous le nom de “gateway”) et un point d’arrivée. Les messages ne peuvent être envoyés que dans un seul sens. Pour renvoyer des messages, un autre tunnel est requis.
Deux types de tunnels existent : les “tunnels sortants” envoient des messages loin du créateur du tunnel, tandis que les “tunnels entrants” apportent des messages au créateur du tunnel. La combinaison de ces deux tunnels permet aux utilisateurs de s’envoyer des messages. L’expéditeur (“Alice” dans l’image ci-dessus) met en place un tunnel sortant, tandis que le destinataire (“Bob” dans l’image ci-dessus) crée un tunnel entrant. La passerelle d’un tunnel entrant peut recevoir des messages de n’importe quel autre utilisateur et les transmettra jusqu’au point de terminaison (“Bob”). Le point de terminaison du tunnel sortant devra transmettre le message à la passerelle du tunnel entrant. Pour ce faire, l’expéditeur (“Alice”) ajoute des instructions à son message chiffré. Une fois que le point de terminaison du tunnel sortant déchiffre le message, il aura des instructions pour transférer le message vers la bonne passerelle entrante (la passerelle vers “Bob”).
Un troisième concept critique à comprendre est la “base de données réseau” d’I2P (ou “netDb”) — une paire d’algorithmes utilisés pour partager les métadonnées du réseau. Les deux types de métadonnées transportées sont les “routerInfo” et les “leaseSets” — les routerInfo fournissent aux routers les données nécessaires pour contacter un router particulier (leurs clés publiques, adresses de transport, etc), tandis que les leaseSet fournissent aux routers les informations nécessaires pour contacter une destination particulière. Un leaseSet contient un nombre de “leases”. Chacun de ces leases spécifie une passerelle tunnel, qui permet d’atteindre une destination spécifique. L’information complète contenue dans un lease :
- Passerelle d’entrée pour un tunnel qui permet d’atteindre une destination spécifique.
- Moment où un tunnel expire.
- Paire de clés publiques pour pouvoir chiffrer les messages (à envoyer à travers le tunnel et atteindre la destination).
Les routeurs eux-mêmes envoient leur routerInfo directement au netDb, tandis que les leaseSets sont envoyés via des tunnels sortants (les leaseSets doivent être envoyés de manière anonyme pour éviter de corréler un routeur avec ses leaseSets).
Nous pouvons combiner les concepts ci-dessus pour établir des connexions réussies dans le réseau.
Pour construire ses propres tunnels entrants et sortants, Alice effectue une recherche dans la netDb pour collecter les routerInfo. De cette façon, elle rassemble des listes de pairs qu’elle peut utiliser comme relais dans ses tunnels. Elle peut ensuite envoyer un message de construction au premier relais, demandant la construction d’un tunnel et demandant à ce router de transmettre le message de construction plus loin, jusqu’à ce que le tunnel ait été construit.
Quand Alice veut envoyer un message à Bob, elle effectue d’abord une recherche dans la netDb pour trouver le leaseSet de Bob, ce qui lui donne ses passerelles de tunnel entrant actuelles. Elle choisit ensuite l’un de ses tunnels sortants et envoie le message avec des instructions pour que le point de terminaison du tunnel sortant transmette le message à l’une des passerelles de tunnel entrant de Bob. Quand le point de terminaison du tunnel sortant reçoit ces instructions, il transmet le message comme demandé, et quand la passerelle de tunnel entrant de Bob le reçoit, il est transmis dans le tunnel vers le router de Bob. Si Alice veut que Bob puisse répondre au message, elle doit transmettre sa propre destination explicitement dans le message lui-même. Ceci peut être fait en introduisant une couche de niveau supérieur, ce qui est fait dans la bibliothèque de streaming . Alice peut également réduire le temps de réponse en incluant son leaseSet le plus récent avec le message pour que Bob n’ait pas besoin de faire une recherche netDb quand il veut répondre, mais ceci est optionnel.
Bien que les tunnels eux-mêmes disposent d’un chiffrement en couches pour empêcher la divulgation non autorisée aux pairs à l’intérieur du réseau (tout comme la couche de transport elle-même le fait pour empêcher la divulgation non autorisée aux pairs à l’extérieur du réseau), il est nécessaire d’ajouter une couche de chiffrement de bout en bout supplémentaire pour cacher le message du point de sortie du tunnel sortant et de la passerelle du tunnel entrant. Ce “garlic encryption ” permet au router d’Alice d’envelopper plusieurs messages dans un seul “message garlic”, chiffré avec une clé publique particulière afin que les pairs intermédiaires ne puissent déterminer ni combien de messages se trouvent dans le garlic, ni ce que disent ces messages, ni où ces gousses individuelles sont destinées. Pour une communication typique de bout en bout entre Alice et Bob, le garlic sera chiffré avec la clé publique publiée dans le leaseSet de Bob, permettant au message d’être chiffré sans révéler la clé publique au router de Bob lui-même.
Un autre fait important à garder à l’esprit est qu’I2P est entièrement basé sur les messages et que certains messages peuvent être perdus en cours de route. Les applications utilisant I2P peuvent utiliser les interfaces orientées message et gérer leurs propres besoins de contrôle de congestion et de fiabilité, mais la plupart seraient mieux servies en réutilisant la bibliothèque de streaming fournie pour considérer I2P comme un réseau basé sur les flux.
Tunnels
Les tunnels entrants et sortants fonctionnent selon des principes similaires. La passerelle du tunnel accumule un certain nombre de messages de tunnel, les préprocessant finalement en quelque chose adapté à la livraison par tunnel. Ensuite, la passerelle chiffre ces données préprocessées et les transmet au premier saut. Ce pair et les participants suivants du tunnel ajoutent une couche de chiffrement après avoir vérifié qu’il ne s’agit pas d’un doublon avant de le transmettre au pair suivant. Finalement, le message arrive au point de terminaison où les messages sont à nouveau séparés et transmis comme demandé. La différence réside dans ce que fait le créateur du tunnel — pour les tunnels entrants, le créateur est le point de terminaison et il déchiffre simplement toutes les couches ajoutées, tandis que pour les tunnels sortants, le créateur est la passerelle et il pré-déchiffre toutes les couches de sorte qu’après l’ajout de toutes les couches de chiffrement par saut, le message arrive en clair au point de terminaison du tunnel.
Le choix de pairs spécifiques pour transmettre les messages ainsi que leur ordre particulier est important pour comprendre les caractéristiques d’anonymat et de performance d’I2P. Bien que la base de données réseau (ci-dessous) ait ses propres critères pour choisir quels pairs interroger et sur lesquels stocker des entrées, les créateurs de tunnel peuvent utiliser n’importe quels pairs du réseau dans n’importe quel ordre (et même n’importe quel nombre de fois) dans un seul tunnel. Si des données parfaites de latence et de capacité étaient connues globalement, la sélection et l’ordonnancement seraient guidés par les besoins particuliers du client en parallèle avec leur modèle de menace. Malheureusement, les données de latence et de capacité ne sont pas triviales à collecter de manière anonyme, et dépendre de pairs non fiables pour fournir ces informations a ses propres implications sérieuses en matière d’anonymat.
Du point de vue de l’anonymat, la technique la plus simple serait de choisir des pairs de manière aléatoire dans l’ensemble du réseau, de les ordonner de façon aléatoire et d’utiliser ces pairs dans cet ordre pour l’éternité. Du point de vue des performances, la technique la plus simple serait de choisir les pairs les plus rapides avec la capacité de réserve nécessaire, en répartissant la charge sur différents pairs pour gérer la basculement transparent, et de reconstruire le tunnel chaque fois que les informations de capacité changent. Bien que la première approche soit à la fois fragile et inefficace, la seconde nécessite des informations inaccessibles et offre un anonymat insuffisant. I2P travaille plutôt à offrir une gamme de stratégies de sélection de pairs, couplées à du code de mesure conscient de l’anonymat pour organiser les pairs selon leurs profils.
En tant que base, I2P profile constamment les pairs avec lesquels il interagit en mesurant leur comportement indirect — par exemple, lorsqu’un pair répond à une recherche netDb en 1,3 seconde, cette latence d’aller-retour est enregistrée dans les profils de tous les routers impliqués dans les deux tunnels (entrant et sortant) par lesquels la requête et la réponse sont passées, ainsi que dans le profil du pair interrogé. La mesure directe, comme la latence de la couche transport ou la congestion, n’est pas utilisée dans le cadre du profil, car elle peut être manipulée et associée au router qui mesure, l’exposant à des attaques triviales. Lors de la collecte de ces profils, une série de calculs sont effectués sur chacun pour résumer ses performances — sa latence, sa capacité à gérer beaucoup d’activité, s’il est actuellement surchargé, et à quel point il semble bien intégré dans le réseau. Ces calculs sont ensuite comparés pour les pairs actifs afin d’organiser les routers en quatre niveaux — rapide et haute capacité, haute capacité, ne défaillant pas, et défaillant. Les seuils pour ces niveaux sont déterminés dynamiquement, et bien qu’ils utilisent actuellement des algorithmes assez simples, des alternatives existent.
En utilisant ces données de profil, la stratégie de sélection de pairs la plus simple et raisonnable consiste à choisir des pairs aléatoirement dans le niveau supérieur (rapides et haute capacité), et c’est actuellement déployé pour les tunnels clients. Les tunnels exploratoires (utilisés pour la netDb et la gestion des tunnels) choisissent des pairs aléatoirement dans le niveau “sans échec” (qui inclut également les routeurs des niveaux “meilleurs”), permettant au pair d’échantillonner les routeurs plus largement, optimisant en effet la sélection de pairs grâce à une escalade de collines aléatoire. Ces stratégies seules divulguent cependant des informations concernant les pairs dans le niveau supérieur du router par le biais d’attaques de prédécesseur et de collecte de netDb. À leur tour, plusieurs alternatives existent qui, bien qu’elles n’équilibrent pas la charge aussi uniformément, traiteront les attaques menées par des classes particulières d’adversaires.
En choisissant une clé aléatoire et en ordonnant les pairs selon leur distance XOR par rapport à celle-ci, les informations divulguées sont réduites dans les attaques de prédécesseur et de collecte selon le taux de défaillance des pairs et le renouvellement du niveau. Une autre stratégie simple pour faire face aux attaques de collecte netDb consiste simplement à fixer la ou les passerelles de tunnel entrant tout en randomisant les pairs plus loin dans les tunnels. Pour faire face aux attaques de prédécesseur pour les adversaires que le client contacte, les points de terminaison de tunnel sortant resteraient également fixes. La sélection du pair à fixer sur le point le plus exposé devrait bien sûr avoir une limite de durée, car tous les pairs finissent par échouer, donc cela pourrait être ajusté de manière réactive ou évité de manière proactive pour imiter un temps moyen mesuré entre les défaillances d’autres routeurs. Ces deux stratégies peuvent à leur tour être combinées, utilisant un pair exposé fixe et un ordonnancement basé sur XOR dans les tunnels eux-mêmes. Une stratégie plus rigide fixerait les pairs exacts et l’ordonnancement d’un tunnel potentiel, n’utilisant des pairs individuels que si tous acceptent de participer de la même manière à chaque fois. Cela diffère de l’ordonnancement basé sur XOR en ce que le prédécesseur et le successeur de chaque pair sont toujours les mêmes, tandis que XOR s’assure seulement que leur ordre ne change pas.
Comme mentionné précédemment, I2P inclut actuellement (version 0.8) la stratégie aléatoire à niveaux ci-dessus, avec un ordonnancement basé sur XOR. Une discussion plus détaillée des mécanismes impliqués dans le fonctionnement des tunnels, leur gestion, et la sélection des pairs peut être trouvée dans la spécification des tunnels .
Base de données réseau (netDb)
Comme mentionné précédemment, la netDb d’I2P fonctionne pour partager les métadonnées du réseau. Ceci est détaillé dans la page base de données réseau , mais une explication de base est disponible ci-dessous.
Tous les routers I2P contiennent une netDb locale, mais tous les routers ne participent pas à la DHT ou ne répondent pas aux recherches de leaseSet. Les routers qui participent à la DHT et répondent aux recherches de leaseSet sont appelés ‘floodfills’. Les routers peuvent être configurés manuellement comme floodfills, ou devenir automatiquement floodfill s’ils ont suffisamment de capacité et répondent à d’autres critères de fonctionnement fiable.
Les autres routeurs I2P stockeront leurs données et rechercheront des données en envoyant de simples requêtes ‘store’ et ’lookup’ aux floodfills. Si un routeur floodfill reçoit une requête ‘store’, il diffusera l’information vers d’autres routeurs floodfills en utilisant l’algorithme Kademlia . Les requêtes ’lookup’ fonctionnent actuellement différemment, pour éviter un problème de sécurité important. Quand une lookup est effectuée, le routeur floodfill ne transmettra pas la lookup vers d’autres pairs, mais répondra toujours par lui-même (s’il possède les données demandées).
Deux types d’informations sont stockés dans la base de données réseau.
- Un RouterInfo stocke les informations sur un router I2P spécifique et comment le contacter
- Un LeaseSet stocke les informations sur une destination spécifique (par exemple un site web I2P, un serveur e-mail…)
Toutes ces informations sont signées par la partie qui les publie et vérifiées par tout router I2P utilisant ou stockant ces informations. De plus, les données contiennent des informations de timing, pour éviter le stockage d’anciennes entrées et d’éventuelles attaques. C’est aussi pourquoi I2P intègre le code nécessaire pour maintenir l’heure correcte, interrogeant occasionnellement quelques serveurs SNTP (le round robin pool.ntp.org par défaut) et détectant les décalages entre routers au niveau de la couche transport.
Quelques remarques supplémentaires sont également importantes.
LeaseSet non publiés et chiffrés : On pourrait vouloir que seules des personnes spécifiques puissent atteindre une destination. Ceci est possible en ne publiant pas la destination dans la netDb. Vous devrez cependant transmettre la destination par d’autres moyens. Ceci est pris en charge par les ’encrypted leaseSets’. Ces leaseSets ne peuvent être décodés que par les personnes ayant accès à la clé de déchiffrement.
Bootstrapping : Le bootstrapping de la netDb est assez simple. Une fois qu’un router parvient à recevoir un seul routerInfo d’un pair accessible, il peut interroger ce router pour obtenir des références vers d’autres routers du réseau. Actuellement, un certain nombre d’utilisateurs publient leurs fichiers routerInfo sur un site web pour rendre cette information disponible. I2P se connecte automatiquement à l’un de ces sites web pour collecter les fichiers routerInfo et effectuer le bootstrap. I2P appelle ce processus de bootstrap « reseeding ».
Évolutivité des recherches : Les recherches dans le réseau I2P sont itératives, pas récursives. Si une recherche depuis un floodfill échoue, la recherche sera répétée vers le floodfill le plus proche suivant. Le floodfill ne demande pas récursivement les données à un autre floodfill. Les recherches itératives sont évolutives pour les grands réseaux DHT.
Protocoles de transport
La communication entre routers doit fournir la confidentialité et l’intégrité contre les adversaires externes tout en authentifiant que le router contacté est bien celui qui devrait recevoir un message donné. Les détails de la façon dont les routers communiquent avec d’autres routers ne sont pas critiques — trois protocoles distincts ont été utilisés à différents moments pour fournir ces nécessités de base.
I2P prend actuellement en charge deux protocoles de transport, NTCP2 sur TCP, et SSU2 sur UDP. Ces protocoles ont remplacé les versions précédentes, NTCP et SSU , qui sont maintenant obsolètes. Les deux protocoles prennent en charge IPv4 et IPv6. En supportant les transports TCP et UDP, I2P peut efficacement traverser la plupart des pare-feux, y compris ceux destinés à bloquer le trafic dans des régimes de censure restrictifs. NTCP2 et SSU2 ont été conçus pour utiliser des standards de chiffrement modernes, améliorer la résistance à l’identification du trafic, augmenter l’efficacité et la sécurité, et rendre la traversée NAT plus robuste. Les routers publient chaque transport pris en charge et adresse IP dans la base de données réseau. Les routers avec accès aux réseaux IPv4 et IPv6 publics publieront généralement quatre adresses, une pour chaque combinaison de NTCP2/SSU2 avec IPv4/IPv6.
SSU2 soutient et étend les objectifs de SSU. SSU2 présente de nombreuses similitudes avec d’autres protocoles UDP modernes tels que Wireguard et QUIC. En plus du transport fiable des messages réseau via UDP, SSU2 fournit des facilités spécialisées pour la détection coopérative d’adresses IP pair-à-pair, la détection de pare-feu et la traversée NAT. Comme décrit dans la spécification SSU :
L’objectif de ce protocole est de fournir une livraison de messages sécurisée, authentifiée, semi-fiable et non ordonnée, en exposant seulement une quantité minimale de données facilement discernables par des tiers. Il devrait supporter une communication à haut degré ainsi qu’un contrôle de congestion compatible TCP et peut inclure la détection PMTU. Il devrait être capable de déplacer efficacement des données en masse à des débits suffisants pour les utilisateurs domestiques. De plus, il devrait supporter des techniques pour contourner les obstacles réseau, comme la plupart des NAT ou pare-feu.
NTCP2 prend en charge et étend les objectifs de NTCP. Il fournit un transport efficace et entièrement chiffré des messages réseau sur TCP, ainsi qu’une résistance à l’identification du trafic, en utilisant des standards de chiffrement modernes.
I2P prend en charge plusieurs transports simultanément. Un transport particulier pour une connexion sortante est sélectionné avec des “enchères”. Chaque transport fait une enchère pour la connexion et la valeur relative de ces enchères détermine la priorité. Les transports peuvent répondre avec des enchères différentes, selon qu’il existe déjà une connexion établie avec le pair.
Les valeurs d’enchère (priorité) dépendent de l’implémentation et peuvent varier selon les conditions de trafic, le nombre de connexions et d’autres facteurs. Les routers publient également leurs préférences de transport pour les connexions entrantes dans la base de données réseau sous forme de “coûts” de transport pour chaque transport et adresse.
Cryptographie
I2P utilise la cryptographie à plusieurs couches de protocole pour le chiffrement, l’authentification et la vérification. Les principales couches de protocole sont : les transports, les messages de construction de tunnel, le chiffrement de couche tunnel, les messages de base de données réseau, et les messages de bout en bout (garlic). La conception originale d’I2P utilisait un petit ensemble de primitives cryptographiques qui étaient considérées comme sécurisées à l’époque. Celles-ci incluaient le chiffrement asymétrique ElGamal, les signatures DSA-SHA1, le chiffrement symétrique AES256/CBC, et les hachages SHA-256. Alors que la puissance de calcul disponible augmentait et que la recherche cryptographique évoluait considérablement au fil des ans, I2P devait mettre à niveau ses primitives et protocoles. Par conséquent, nous avons ajouté un concept de “types de chiffrement” et “types de signature”, et étendu nos protocoles pour inclure ces identifiants et indiquer la prise en charge. Cela nous permet de mettre à jour et d’étendre périodiquement la prise en charge réseau pour la cryptographie moderne et de préparer le réseau pour de nouvelles primitives, sans rompre la compatibilité ascendante ou nécessiter un “jour J” pour les mises à jour réseau. Certains types de signature et de chiffrement sont également réservés à un usage expérimental.
Les primitives actuelles utilisées dans la plupart des couches de protocole sont l’échange de clés X25519, les signatures EdDSA, le chiffrement symétrique authentifié ChaCha20/Poly1305, et les hachages SHA-256. AES256 est encore utilisé pour le chiffrement de la couche tunnel. Ces protocoles modernes sont utilisés pour la grande majorité des communications réseau. Les primitives plus anciennes incluant ElGamal, ECDSA, et DSA-SHA1 continuent d’être supportées par la plupart des implémentations pour la compatibilité ascendante lors de la communication avec des routers plus anciens. Certains anciens protocoles ont été dépréciés et/ou supprimés complètement. Dans un avenir proche, nous commencerons la recherche sur une migration vers le chiffrement et les signatures post-quantiques (PQ) ou hybrides-PQ afin de maintenir nos standards de sécurité robustes.
Ces primitives cryptographiques sont combinées ensemble pour fournir les défenses en couches d’I2P contre une variété d’adversaires. Au niveau le plus bas, la communication inter-router est protégée par la sécurité de la couche de transport. Les messages de tunnel transmis sur les transports ont leur propre chiffrement en couches. Divers autres messages sont transmis à l’intérieur de “garlic messages”, qui sont également chiffrés.
Messages Garlic
Les messages garlic sont une extension du chiffrement en couches “onion”, permettant au contenu d’un seul message de contenir plusieurs “cloves” — des messages entièrement formés accompagnés de leurs propres instructions de livraison. Les messages sont encapsulés dans un message garlic chaque fois que le message passerait autrement en texte clair à travers un pair qui ne devrait pas avoir accès à l’information — par exemple, quand un router veut demander à un autre router de participer à un tunnel, il encapsule la requête dans un garlic, chiffre ce garlic avec la clé publique du router destinataire, et le transmet à travers un tunnel. Un autre exemple est quand un client veut envoyer un message à une destination — le router de l’expéditeur va encapsuler ce message de données (avec quelques autres messages) dans un garlic, chiffrer ce garlic avec la clé publique publiée dans le leaseSet du destinataire, et le transmettre à travers les tunnels appropriés.
Les “instructions” attachées à chaque clove à l’intérieur de la couche de chiffrement incluent la capacité de demander que le clove soit transmis localement, vers un router distant, ou vers un tunnel distant sur un router distant. Il y a des champs dans ces instructions permettant à un pair de demander que la livraison soit retardée jusqu’à ce qu’un certain moment ou qu’une certaine condition soit remplie, bien qu’ils ne soient pas honorés tant que les délais non triviaux ne sont pas déployés. Il est possible de router explicitement les messages garlic sur n’importe quel nombre de sauts sans construire de tunnels, ou même de rediriger les messages de tunnel en les enveloppant dans des messages garlic et en les transmettant sur un certain nombre de sauts avant de les livrer au saut suivant dans le tunnel, mais ces techniques ne sont pas actuellement utilisées dans l’implémentation existante.
Balises de session
En tant que système non fiable, non ordonné et basé sur les messages, I2P utilise une combinaison simple d’algorithmes de chiffrement asymétrique et symétrique pour fournir la confidentialité et l’intégrité des données aux garlic messages. La combinaison originale était appelée ElGamal/AES+SessionTags, mais c’est une façon excessivement verbeuse de décrire la simple utilisation d’ElGamal 2048 bits, AES256, SHA256 et des nonces de 32 octets. Bien que ce protocole soit toujours pris en charge, la majeure partie du réseau a migré vers un nouveau protocole, ECIES-X25519-AEAD-Ratchet. Ce protocole combine X25519, ChaCha20/Poly1305 et un PRNG synchronisé pour générer les nonces de 32 octets. Les deux protocoles seront brièvement décrits ci-dessous.
ElGamal/AES+SessionTags
La première fois qu’un router veut chiffrer un message garlic vers un autre router, il chiffre le matériel de clés pour une clé de session AES256 avec ElGamal et ajoute la charge utile chiffrée AES256/CBC après ce bloc ElGamal chiffré. En plus de la charge utile chiffrée, la section chiffrée AES contient la longueur de la charge utile, le hachage SHA256 de la charge utile non chiffrée, ainsi qu’un certain nombre de “session tags” — des nonces aléatoires de 32 octets. La prochaine fois que l’expéditeur veut chiffrer un message garlic vers un autre router, plutôt que de chiffrer ElGamal une nouvelle clé de session, il sélectionne simplement l’un des session tags précédemment livrés et chiffre AES la charge utile comme avant, en utilisant la clé de session utilisée avec ce session tag, précédé du session tag lui-même. Quand un router reçoit un message chiffré garlic, il vérifie les 32 premiers octets pour voir s’ils correspondent à un session tag disponible — si c’est le cas, il déchiffre simplement le message AES, mais sinon, il déchiffre ElGamal le premier bloc.
Chaque tag de session ne peut être utilisé qu’une seule fois afin d’empêcher les adversaires internes de corréler inutilement différents messages comme étant entre les mêmes routeurs. L’expéditeur d’un message chiffré ElGamal/AES+SessionTag choisit quand et combien de tags livrer, approvisionnant à l’avance le destinataire avec suffisamment de tags pour couvrir une volée de messages. Les messages garlic peuvent détecter la livraison réussie des tags en regroupant un petit message supplémentaire comme un clou (un “message de statut de livraison”) — lorsque le message garlic arrive au destinataire prévu et est déchiffré avec succès, ce petit message de statut de livraison est l’un des clous exposés et contient des instructions pour que le destinataire renvoie le clou à l’expéditeur original (à travers un tunnel entrant, bien sûr). Lorsque l’expéditeur original reçoit ce message de statut de livraison, il sait que les tags de session regroupés dans le message garlic ont été livrés avec succès.
Les session tags eux-mêmes ont une durée de vie très courte, après laquelle ils sont supprimés s’ils ne sont pas utilisés. De plus, la quantité stockée pour chaque clé est limitée, tout comme le nombre de clés elles-mêmes — si trop arrivent, les messages nouveaux ou anciens peuvent être supprimés. L’expéditeur suit si les messages utilisant des session tags passent bien, et s’il n’y a pas suffisamment de communication, il peut supprimer ceux précédemment supposés être correctement livrés, revenant au chiffrement ElGamal complet coûteux.
ECIES-X25519-AEAD-Ratchet
ElGamal/AES+SessionTags nécessitait une surcharge substantielle de plusieurs façons. L’utilisation du CPU était élevée car ElGamal est assez lent. La bande passante était excessive car un grand nombre de session tags devait être livré à l’avance, et parce que les clés publiques ElGamal sont très volumineuses. L’utilisation de la mémoire était élevée en raison de l’exigence de stocker de grandes quantités de session tags. La fiabilité était entravée par la perte de livraison des session tags.
ECIES-X25519-AEAD-Ratchet a été conçu pour résoudre ces problèmes. X25519 est utilisé pour l’échange de clés. ChaCha20/Poly1305 est utilisé pour le chiffrement symétrique authentifié. Les clés de chiffrement sont “double ratcheted” ou pivotées périodiquement. Les balises de session sont réduites de 32 octets à 8 octets et sont générées avec un PRNG. Le protocole présente de nombreuses similitudes avec le protocole signal utilisé dans Signal et WhatsApp. Ce protocole fournit une surcharge considérablement réduite en termes de CPU, RAM et bande passante.
Les tags de session sont générés à partir d’un PRNG déterministe synchronisé fonctionnant aux deux extrémités de la session pour générer les tags de session et les clés de session. Le PRNG est un HKDF utilisant un SHA-256 HMAC, et est amorcé à partir du résultat X25519 DH. Les tags de session ne sont jamais transmis à l’avance ; ils sont seulement inclus avec le message. Le récepteur stocke un nombre limité de clés de session, indexées par tag de session. L’expéditeur n’a pas besoin de stocker de tags ou clés de session car ils ne sont pas envoyés à l’avance ; ils peuvent être générés à la demande. En maintenant ce PRNG approximativement synchronisé entre l’expéditeur et le destinataire (le destinataire précalcule une fenêtre des prochains 50 tags par exemple), la surcharge de regrouper périodiquement un grand nombre de tags est supprimée.
Futur
Les protocoles d’I2P sont efficaces sur la plupart des plateformes, y compris les téléphones portables, et sécurisés pour la plupart des modèles de menaces. Cependant, il existe plusieurs domaines qui nécessitent des améliorations supplémentaires pour répondre aux besoins de ceux qui font face à des adversaires puissants soutenus par l’État, et pour faire face aux menaces des avancées cryptographiques continues et de la puissance de calcul en constante augmentation. Deux fonctionnalités possibles, les routes restreintes et la latence variable, ont été proposées par jrandom en 2003. Bien que nous ne prévoyions plus d’implémenter ces fonctionnalités, elles sont décrites ci-dessous.
Fonctionnement de Route Restreinte
I2P est un réseau superposé conçu pour fonctionner au-dessus d’un réseau de commutation de paquets fonctionnel, exploitant le principe de bout en bout pour offrir anonymat et sécurité. Bien qu’Internet n’embrasse plus pleinement le principe de bout en bout (en raison de l’utilisation du NAT), I2P nécessite qu’une partie substantielle du réseau soit accessible — il peut y avoir un certain nombre de pairs en périphérie fonctionnant avec des routes restreintes, mais I2P n’inclut pas d’algorithme de routage approprié pour le cas dégénéré où la plupart des pairs sont inaccessibles. Il fonctionnerait cependant au-dessus d’un réseau employant un tel algorithme.
Le fonctionnement de routes restreintes, où il existe des limites quant aux pairs directement accessibles, a plusieurs implications fonctionnelles et d’anonymat différentes, selon la façon dont les routes restreintes sont gérées. Au niveau le plus basique, les routes restreintes existent quand un pair se trouve derrière un NAT ou un pare-feu qui n’autorise pas les connexions entrantes. Cela a été largement résolu en intégrant le perçage distribué de trous dans la couche transport, permettant aux personnes derrière la plupart des NAT et pare-feu de recevoir des connexions non sollicitées sans aucune configuration. Cependant, cela ne limite pas l’exposition de l’adresse IP du pair aux routers à l’intérieur du réseau, car ils peuvent simplement être présentés au pair par l’introducer publié.
Au-delà de la gestion fonctionnelle des routes restreintes, il existe deux niveaux d’opération restreinte qui peuvent être utilisés pour limiter l’exposition de son adresse IP — utiliser des tunnels spécifiques au router pour la communication, et offrir des ‘client routers’. Pour le premier cas, les routers peuvent soit construire un nouveau pool de tunnels ou réutiliser leur pool exploratoire, publiant les passerelles entrantes vers certains d’entre eux dans le cadre de leur routerInfo à la place de leurs adresses de transport. Quand un pair veut entrer en contact avec eux, il voit ces passerelles de tunnel dans la netDb et envoie simplement le message pertinent vers elles à travers l’un des tunnels publiés. Si le pair derrière la route restreinte veut répondre, il peut le faire soit directement (s’il est disposé à exposer son IP au pair) ou indirectement à travers ses tunnels sortants. Quand les routers avec lesquels le pair a des connexions directes veulent l’atteindre (pour transférer des messages de tunnel, par exemple), ils priorisent simplement leur connexion directe plutôt que la passerelle de tunnel publiée. Le concept de ‘client routers’ étend simplement la route restreinte en ne publiant aucune adresse de router. Un tel router n’aurait même pas besoin de publier son routerInfo dans la netDb, fournissant simplement son routerInfo auto-signé aux pairs qu’il contacte (nécessaire pour transmettre les clés publiques du router).
Il y a des compromis pour ceux qui se trouvent derrière des routes restreintes, car ils participeraient probablement moins fréquemment aux tunnels d’autres personnes, et les routers auxquels ils sont connectés seraient en mesure de déduire des modèles de trafic qui ne seraient pas autrement exposés. D’autre part, si le coût de cette exposition est inférieur au coût de la mise à disposition d’une IP, cela peut valoir la peine. Ceci, bien sûr, suppose que les pairs que le router derrière une route restreinte contacte ne sont pas hostiles — soit le réseau est suffisamment large pour que la probabilité d’utiliser un pair hostile pour se connecter soit suffisamment faible, soit des pairs de confiance (et peut-être temporaires) sont utilisés à la place.
Les routes restreintes sont complexes, et l’objectif global a été largement abandonné. Plusieurs améliorations connexes ont considérablement réduit le besoin de ces routes. Nous prenons désormais en charge UPnP pour ouvrir automatiquement les ports du pare-feu. Nous prenons en charge à la fois IPv4 et IPv6. SSU2 a amélioré la détection d’adresse, la détermination de l’état du pare-feu et le perçage coopératif de NAT. SSU2, NTCP2 et les vérifications de compatibilité d’adresses garantissent que les sauts de tunnel peuvent se connecter avant que le tunnel ne soit construit. GeoIP et l’identification de pays nous permettent d’éviter les pairs dans des pays avec des pare-feux restrictifs. La prise en charge des routers “cachés” derrière ces pare-feux s’est améliorée. Certaines implémentations prennent également en charge les connexions aux pairs sur des réseaux de superposition tels qu’Yggdrasil.
Latence Variable
Bien que la majeure partie des efforts initiaux d’I2P ait porté sur la communication à faible latence, il a été conçu dès le début en gardant à l’esprit les services à latence variable. Au niveau le plus basique, les applications fonctionnant sur I2P peuvent offrir l’anonymat de la communication à latence moyenne et élevée tout en mélangeant leurs modèles de trafic avec le trafic à faible latence. Cependant, en interne, I2P peut offrir sa propre communication à latence moyenne et élevée grâce au garlic encryption — en spécifiant que le message doit être envoyé après un certain délai, à un moment précis, après qu’un certain nombre de messages aient été transmis, ou selon une autre stratégie de mélange. Avec le chiffrement en couches, seul le router auquel le clove a exposé la demande de délai saurait que le message nécessite une latence élevée, permettant au trafic de se fondre davantage avec le trafic à faible latence. Une fois que la précondition de transmission est remplie, le router qui retient le clove (qui serait lui-même probablement un message garlic) le transmet simplement comme demandé — vers un router, vers un tunnel, ou, plus probablement, vers une destination client distante.
L’objectif des services à latence variable nécessite des ressources substantielles pour les mécanismes de stockage et retransmission qui les supportent. Ces mécanismes peuvent être et sont supportés dans diverses applications de messagerie, comme i2p-bote. Au niveau du réseau, des réseaux alternatifs comme Freenet fournissent ces services. Nous avons décidé de ne pas poursuivre cet objectif au niveau du router I2P.
Systèmes similaires
L’architecture d’I2P s’appuie sur les concepts de middleware orienté messages, la topologie des DHT, l’anonymat et la cryptographie des mixnets à routage libre, et l’adaptabilité des réseaux à commutation de paquets. La valeur ne provient pas de concepts ou d’algorithmes novateurs, mais d’une ingénierie soigneuse combinant les résultats de recherche de systèmes et d’articles existants. Bien qu’il existe quelques efforts similaires qui méritent d’être examinés, tant pour des comparaisons techniques que fonctionnelles, deux en particulier sont mis en avant ici — Tor et Freenet.
Voir aussi la page de comparaison des réseaux . Notez que ces descriptions ont été écrites par jrandom en 2003 et peuvent ne pas être exactes actuellement.
Tor
À première vue, Tor et I2P présentent de nombreuses similitudes fonctionnelles et liées à l’anonymat. Bien que le développement d’I2P ait commencé avant que nous ayons connaissance des premiers efforts sur Tor, de nombreuses leçons du routage en oignon original et des efforts ZKS ont été intégrées dans la conception d’I2P. Plutôt que de construire un système essentiellement de confiance et centralisé avec des serveurs d’annuaire, I2P dispose d’une base de données réseau auto-organisée où chaque pair prend la responsabilité de profiler les autres routers pour déterminer comment exploiter au mieux les ressources disponibles. Une autre différence clé est que bien qu’I2P et Tor utilisent tous deux des chemins en couches et ordonnés (tunnels et circuits/flux), I2P est fondamentalement un réseau à commutation de paquets, tandis que Tor est fondamentalement un réseau à commutation de circuits, permettant à I2P de router de manière transparente autour de la congestion ou d’autres pannes réseau, d’opérer des chemins redondants, et d’équilibrer la charge des données sur les ressources disponibles. Alors que Tor offre la fonctionnalité outproxy utile en proposant une découverte et sélection d’outproxy intégrées, I2P laisse de telles décisions de couche application aux applications fonctionnant au-dessus d’I2P — en fait, I2P a même externalisé la bibliothèque de streaming de type TCP elle-même vers la couche application, permettant aux développeurs d’expérimenter avec différentes stratégies, exploitant leurs connaissances spécifiques au domaine pour offrir de meilleures performances.
Du point de vue de l’anonymat, il y a beaucoup de similitudes lorsque les réseaux de base sont comparés. Cependant, il y a quelques différences clés. Lorsqu’il s’agit d’un adversaire interne ou de la plupart des adversaires externes, les tunnels simplex d’I2P exposent moitié moins de données de trafic que ne le feraient les circuits duplex de Tor en regardant simplement les flux eux-mêmes — une requête et une réponse HTTP suivraient le même chemin dans Tor, tandis que dans I2P les paquets constituant la requête sortiraient par un ou plusieurs tunnels sortants et les paquets constituant la réponse reviendraient par un ou plusieurs tunnels entrants différents. Bien que les stratégies de sélection et d’ordonnancement des pairs d’I2P devraient suffisamment traiter les attaques de prédécesseur, si un passage aux tunnels bidirectionnels était nécessaire, nous pourrions simplement construire un tunnel entrant et sortant le long des mêmes routers.
Un autre problème d’anonymat apparaît dans l’utilisation par Tor de la création de tunnel télescopique, car un simple comptage de paquets et des mesures de temporisation lorsque les cellules d’un circuit passent par le nœud d’un adversaire exposent des informations statistiques concernant la position de l’adversaire dans le circuit. La création de tunnel unidirectionnel d’I2P avec un seul message fait que ces données ne sont pas exposées. Protéger la position dans un tunnel est important, car un adversaire pourrait autrement être capable de monter une série d’attaques puissantes de type prédécesseur, intersection et confirmation de trafic.
Dans l’ensemble, Tor et I2P se complètent dans leur approche — Tor vise à offrir un proxy sortant Internet anonyme à haute vitesse, tandis qu’I2P vise à offrir un réseau décentralisé et résilient en lui-même. En théorie, les deux peuvent être utilisés pour atteindre ces deux objectifs, mais compte tenu des ressources de développement limitées, ils ont chacun leurs forces et leurs faiblesses. Les développeurs d’I2P ont étudié les étapes nécessaires pour modifier Tor afin de tirer parti de la conception d’I2P, mais les préoccupations concernant la viabilité de Tor dans des conditions de ressources rares suggèrent que l’architecture de commutation de paquets d’I2P sera capable d’exploiter les ressources rares plus efficacement.
Freenet
Freenet a joué un rôle important dans les premières étapes de la conception d’I2P — apportant la preuve de la viabilité d’une communauté pseudonyme dynamique entièrement contenue dans le réseau, démontrant que les dangers inhérents aux outproxies pouvaient être évités. La première graine d’I2P a commencé comme une couche de communication de remplacement pour Freenet, tentant de séparer les complexités d’une communication point à point évolutive, anonyme et sécurisée des complexités d’un magasin de données distribué résistant à la censure. Au fil du temps cependant, certains des problèmes d’anonymat et d’évolutivité inhérents aux algorithmes de Freenet ont rendu évident qu’I2P devait se concentrer strictement sur la fourniture d’une couche de communication anonyme générique, plutôt que comme composant de Freenet. Au fil des années, les développeurs de Freenet ont pris conscience des faiblesses de l’ancienne conception, les incitant à suggérer qu’ils auraient besoin d’une couche de “premix” pour offrir un anonymat substantiel. En d’autres termes, Freenet doit s’exécuter au-dessus d’un mixnet tel qu’I2P ou Tor, avec des “nœuds clients” demandant et publiant des données à travers le mixnet vers les “nœuds serveurs” qui récupèrent et stockent ensuite les données selon les algorithmes heuristiques de stockage de données distribué de Freenet.
La fonctionnalité de Freenet est très complémentaire à celle d’I2P, car Freenet fournit nativement de nombreux outils pour faire fonctionner des systèmes à latence moyenne et élevée, tandis qu’I2P fournit nativement le réseau de mélange à faible latence adapté pour offrir un anonymat adéquat. La logique de séparer le mixnet du stockage de données distribué résistant à la censure semble toujours évidente d’un point de vue ingénierie, anonymat, sécurité et allocation des ressources, donc j’espère que l’équipe Freenet poursuivra des efforts dans cette direction, sinon en réutilisant simplement (ou en aidant à améliorer, si nécessaire) des mixnets existants comme I2P ou Tor.
Annexe A : Couche Application
I2P lui-même ne fait pas vraiment grand-chose — il envoie simplement des messages vers des destinations distantes et reçoit des messages ciblant des destinations locales — la plupart du travail intéressant se fait dans les couches au-dessus. En soi, I2P pourrait être vu comme une couche IP anonyme et sécurisée, et la bibliothèque de streaming incluse comme une implémentation d’une couche TCP anonyme et sécurisée par-dessus. Au-delà de cela, I2PTunnel expose un système de proxy TCP générique pour soit entrer dans le réseau I2P soit en sortir, plus une variété d’applications réseau qui fournissent des fonctionnalités supplémentaires pour les utilisateurs finaux.
Bibliothèque de streaming
La bibliothèque de streaming I2P peut être considérée comme une interface de streaming générique (qui reproduit les sockets TCP), et l’implémentation prend en charge un protocole à fenêtre glissante avec plusieurs optimisations, pour tenir compte de la latence élevée sur I2P. Les flux individuels peuvent ajuster la taille maximale des paquets et d’autres options, bien que la valeur par défaut de 4KB compressés semble être un compromis raisonnable entre les coûts en bande passante de la retransmission des messages perdus et la latence de plusieurs messages.
De plus, compte tenu du coût relativement élevé des messages ultérieurs, le protocole de la bibliothèque de streaming pour planifier et livrer les messages a été optimisé pour permettre aux messages individuels transmis de contenir autant d’informations que possible. Par exemple, une petite transaction HTTP proxifiée à travers la bibliothèque de streaming peut être complétée en un seul aller-retour — le premier message regroupe un SYN, FIN et la petite charge utile (une requête HTTP entre typiquement) et la réponse regroupe le SYN, FIN, ACK et la petite charge utile (de nombreuses réponses HTTP rentrent). Bien qu’un ACK supplémentaire doive être transmis pour indiquer au serveur HTTP que le SYN/FIN/ACK a été reçu, le proxy HTTP local peut livrer la réponse complète au navigateur immédiatement.
Dans l’ensemble, cependant, la bibliothèque de streaming ressemble beaucoup à une abstraction de TCP, avec ses fenêtres glissantes, ses algorithmes de contrôle de congestion (à la fois démarrage lent et évitement de congestion), et son comportement général des paquets (ACK, SYN, FIN, RST, etc).
Bibliothèque de nommage et carnet d’adresses
Pour plus d’informations, consultez la page Nommage et carnet d’adresses .
Développé par : mihi, Ragnarok
Le nommage au sein d’I2P a été un sujet souvent débattu depuis le tout début avec des défenseurs à travers tout le spectre des possibilités. Cependant, étant donné la demande inhérente d’I2P pour une communication sécurisée et un fonctionnement décentralisé, le système de nommage traditionnel de style DNS est clairement exclu, tout comme les systèmes de vote “majorité gagnante”. Au lieu de cela, I2P est livré avec une bibliothèque de nommage générique et une implémentation de base conçue pour fonctionner à partir d’un mappage local nom vers destination, ainsi qu’une application complémentaire optionnelle appelée “Address Book” (carnet d’adresses). Le carnet d’adresses est un système de nommage sécurisé, distribué et lisible par l’homme, basé sur un réseau de confiance, ne sacrifiant que l’exigence que tous les noms lisibles par l’homme soient globalement uniques en imposant seulement une unicité locale. Bien que tous les messages dans I2P soient adressés cryptographiquement par leur destination, différentes personnes peuvent avoir des entrées locales dans leur carnet d’adresses pour “Alice” qui font référence à différentes destinations. Les gens peuvent toujours découvrir de nouveaux noms en important des carnets d’adresses publiés de pairs spécifiés dans leur réseau de confiance, en ajoutant les entrées fournies par un tiers, ou (si certaines personnes organisent une série de carnets d’adresses publiés utilisant un système d’enregistrement premier arrivé premier servi) les gens peuvent choisir de traiter ces carnets d’adresses comme des serveurs de noms, émulant le DNS traditionnel.
I2P ne promeut pas l’utilisation de services de type DNS cependant, car les dommages causés par le détournement d’un site peuvent être énormes — et les destinations non sécurisées n’ont aucune valeur. DNSsec lui-même se rabat encore sur les registraires et les autorités de certification, alors qu’avec I2P, les requêtes envoyées à une destination ne peuvent pas être interceptées ou la réponse usurpée, car elles sont chiffrées avec les clés publiques de la destination, et une destination elle-même n’est qu’une paire de clés publiques et un certificat. Les systèmes de type DNS d’autre part permettent à n’importe lequel des serveurs de noms sur le chemin de résolution de monter de simples attaques par déni de service et d’usurpation d’identité. Ajouter un certificat authentifiant les réponses comme signées par une autorité de certification centralisée résoudrait de nombreux problèmes de serveurs de noms hostiles mais laisserait ouvertes les attaques par rejeu ainsi que les attaques d’autorités de certification hostiles.
Le système de nommage par vote est également dangereux, surtout étant donné l’efficacité des attaques Sybil dans les systèmes anonymes — l’attaquant peut simplement créer un nombre arbitrairement élevé de pairs et « voter » avec chacun pour s’emparer d’un nom donné. Les méthodes de preuve de travail peuvent être utilisées pour rendre l’identité non-gratuite, mais à mesure que le réseau grandit, la charge requise pour contacter tout le monde afin de mener un vote en ligne devient irréalisable, ou si l’ensemble du réseau n’est pas interrogé, différents ensembles de réponses peuvent être accessibles.
Comme avec Internet cependant, I2P maintient la conception et le fonctionnement d’un système de nommage en dehors de la couche de communication (similaire à IP). La bibliothèque de nommage intégrée inclut une interface de fournisseur de service simple dans laquelle des systèmes de nommage alternatifs peuvent se connecter, permettant aux utilisateurs finaux de choisir le type de compromis de nommage qu’ils préfèrent.
I2PTunnel
Développé par : mihi
I2PTunnel est probablement l’application client la plus populaire et la plus polyvalente d’I2P, permettant un proxying générique à la fois vers et depuis le réseau I2P. I2PTunnel peut être considéré comme quatre applications de proxying distinctes — un “client” qui reçoit les connexions TCP entrantes et les transmet vers une destination I2P donnée, un “httpclient” (alias “eepproxy”) qui agit comme un proxy HTTP et transmet les requêtes vers la destination I2P appropriée (après avoir interrogé le service de nommage si nécessaire), un “server” qui reçoit les connexions de streaming I2P entrantes sur une destination et les transmet vers un hôte+port TCP donné, et un “httpserver” qui étend le “server” en analysant les requêtes et réponses HTTP pour permettre un fonctionnement plus sûr. Il existe une application “socksclient” supplémentaire, mais son utilisation n’est pas encouragée pour les raisons mentionnées précédemment.
I2P lui-même n’est pas un réseau d’outproxy — les préoccupations d’anonymat et de sécurité inhérentes à un réseau de mixage qui transfère des données vers et depuis le mélange ont maintenu la conception d’I2P centrée sur la fourniture d’un réseau anonyme capable de répondre aux besoins de l’utilisateur sans nécessiter de ressources externes. Cependant, l’application I2PTunnel “httpclient” offre un point d’ancrage pour l’outproxying — si le nom d’hôte demandé ne se termine pas par “.i2p”, elle choisit une destination aléatoire parmi un ensemble d’outproxies fourni par l’utilisateur et lui transmet la requête. Ces destinations sont simplement des instances de “serveur” I2PTunnel gérées par des volontaires qui ont explicitement choisi d’exécuter des outproxies — personne n’est un outproxy par défaut, et exécuter un outproxy ne dit pas automatiquement aux autres personnes de passer par vous comme proxy. Bien que les outproxies aient des faiblesses inhérentes, elles offrent une preuve de concept simple pour utiliser I2P et fournissent certaines fonctionnalités sous un modèle de menace qui peut être suffisant pour certains utilisateurs.
I2PTunnel permet l’utilisation de la plupart des applications. Un “httpserver” pointant vers un serveur web permet à quiconque de faire fonctionner son propre site web anonyme (ou “Site I2P”) — un serveur web est fourni avec I2P à cette fin, mais n’importe quel serveur web peut être utilisé. N’importe qui peut faire fonctionner un “client” pointant vers l’un des serveurs IRC hébergés de manière anonyme, chacun d’eux exécutant un “server” pointant vers leur IRCd local et communiquant entre IRCds via leurs propres tunnels “client”. Les utilisateurs finaux ont également des tunnels “client” pointant vers les destinations POP3 et SMTP d’I2Pmail (qui à leur tour sont simplement des instances “server” pointant vers des serveurs POP3 et SMTP), ainsi que des tunnels “client” pointant vers le serveur CVS d’I2P, permettant un développement anonyme. Parfois, les gens ont même fait fonctionner des proxies “client” pour accéder aux instances “server” pointant vers un serveur NNTP.
I2PSnark
I2PSnark développé par : jrandom, et al, porté du client Snark de mjw
Fourni avec l’installation I2P, I2PSnark offre un client BitTorrent anonyme simple avec des capacités multi-torrent, exposant toutes les fonctionnalités via une interface web HTML simple.
I2Pmail / Susimail
Développé par : postman, susi23, mastiejaner
I2Pmail est plus un service qu’une application — postman offre un courrier électronique interne et externe avec un service POP3 et SMTP via des instances I2PTunnel accédant à une série de composants développés avec mastiejaner, permettant aux personnes d’utiliser leurs clients de messagerie préférés pour envoyer et recevoir du courrier de manière pseudonyme. Cependant, comme la plupart des clients de messagerie exposent des informations d’identification substantielles, I2P inclut le client web susimail de susi23 qui a été conçu spécifiquement en tenant compte des besoins d’anonymat d’I2P. Le service I2Pmail/mail.i2p offre un filtrage antivirus transparent ainsi qu’une prévention du déni de service avec des quotas augmentés par hashcash. De plus, chaque utilisateur a le contrôle de sa stratégie de regroupement avant la livraison via les outproxies mail.i2p, qui sont séparés des serveurs SMTP et POP3 mail.i2p — les outproxies et inproxies communiquent avec les serveurs SMTP et POP3 mail.i2p via I2P lui-même, donc compromettre ces emplacements non-anonymes ne donne pas accès aux comptes de messagerie ou aux modèles d’activité de l’utilisateur.