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 sur le transport et la cryptographie sont à jour en janvier 2025.
Introduction
I2P est une couche réseau anonyme à commutation de paquets évolutive, auto-organisée et résiliente, sur laquelle peut fonctionner un nombre quelconque d’applications différentes soucieuses de l’anonymat ou de la sécurité. Chacune de ces applications peut effectuer ses propres compromis entre anonymat, latence et débit sans se soucier de la mise en œuvre correcte d’un mixnet à route libre, leur permettant de mélanger leur activité avec l’ensemble d’anonymat plus large des utilisateurs déjà en cours d’exécution sur I2P.
Les applications disponibles offrent déjà toute la gamme des activités Internet typiques — navigation web anonyme, hébergement web, chat, partage de fichiers, e-mail, blogging et syndication de contenu, ainsi que plusieurs autres applications en cours de développement.
- Navigation web : en utilisant n’importe quel 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 : en utilisant n’importe quel 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 traditionnels de style web, 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 permettant l’anonymat, I2P joue le rôle d’un middleware orienté messages — les applications indiquent qu’elles veulent envoyer des données vers un identifiant cryptographique (une “destination”) et I2P se charge de s’assurer que celles-ci arrivent de manière sécurisée et anonyme. I2P inclut également une bibliothèque de streaming simple pour permettre aux messages anonymes best-effort d’I2P de se transférer sous forme de flux fiables et ordonnés, offrant de manière transparente un algorithme de contrôle de congestion basé sur TCP adapté au 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 toutes les applications exposent 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 son bon fonctionnement et pour aider dans cette démarche, 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 d’anonymat suffisant à ceux qui en ont besoin. Il est en développement actif depuis le début de 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 , la majorité du code étant directement placée dans le domaine public, bien qu’utilisant quelques routines cryptographiques sous licences de style BSD. Les personnes travaillant sur I2P ne contrôlent pas sous quelle licence les gens publient les applications clientes, et plusieurs applications sous GPL sont disponibles (I2PTunnel , susimail , I2PSnark , I2P-Bote, I2Phex et autres). Le financement d’I2P provient entièrement de dons, et ne reçoit aucun avantage fiscal dans aucune juridiction pour le moment, 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. Tout d’abord, I2P fait une séparation stricte entre le logiciel participant au réseau (un “router”) et les points de terminaison anonymes (“destinations”) associés aux 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, le cas échéant, ainsi que sur 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 faisant du proxy vers les serveurs IRC, une autre prenant 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 de routers explicitement sélectionnés. Un 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 sens. Pour renvoyer des messages, un autre tunnel est nécessaire.
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) configure 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 tout autre utilisateur et les transmettra jusqu’au point de terminaison (“Bob”). Le point de terminaison du tunnel sortant devra envoyer 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 les instructions pour transférer le message à la passerelle entrante correcte (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 “routerInfo” et “leaseSets” — le routerInfo fournit aux routers les données nécessaires pour contacter un router particulier (leurs clés publiques, adresses de transport, etc.), tandis que le leaseSet fournit aux routers les informations nécessaires pour contacter une destination particulière. Un leaseSet contient un certain nombre de “leases” (baux). Chacun de ces baux spécifie une passerelle de tunnel, qui permet d’atteindre une destination spécifique. Les informations complètes contenues dans un bail :
- 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 permettant de chiffrer les messages (à envoyer à travers le tunnel et atteindre la destination).
Les routers eux-mêmes envoient leurs 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 router 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 des 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, jusqu’à ce que le tunnel ait été construit.
Quand Alice veut envoyer un message à Bob, elle fait 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 à travers celui-ci 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 jusqu’au router de Bob. Si Alice veut que Bob puisse répondre au message, elle doit transmettre explicitement sa propre destination dans le message lui-même. Cela peut se faire en introduisant une couche de niveau supérieur, ce qui est fait dans la bibliothèque de streaming . Alice peut aussi réduire le temps de réponse en groupant 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 c’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 (comme le fait la couche de transport elle-même pour empêcher la divulgation non autorisée aux pairs à l’extérieur du réseau), il est nécessaire d’ajouter une couche supplémentaire de chiffrement de bout en bout 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’emballer plusieurs messages dans un seul “message garlic”, chiffré vers 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ù sont destinés ces gousses individuelles. Pour une communication typique de bout en bout entre Alice et Bob, le garlic sera chiffré vers la clé publique publiée dans le leaseSet de Bob, permettant au message d’être chiffré sans divulguer 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 prendre en charge leurs propres besoins de contrôle de congestion et de fiabilité, mais la plupart seraient mieux servies en réutilisant la bibliothèque 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 de tunnel accumule un certain nombre de messages de tunnel, les préprocessant finalement en quelque chose pour la livraison de tunnel. Ensuite, la passerelle chiffre ces données préprocessées et les transmet au premier saut. Ce pair et les participants de tunnel suivants 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 network database (ci-dessous) ait ses propres critères pour choisir quels pairs interroger et sur lesquels stocker les 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 tandem 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 aléatoirement dans l’ensemble du réseau, de les ordonner aléatoirement 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 entre différents pairs pour gérer le basculement transparent, et de reconstruire le tunnel chaque fois que les informations de capacité changent. Alors que la première approche est à 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 avec du code de mesure sensible à 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, telle que 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 est exécutée 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é, sans défaillance, et en défaillance. 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 (rapide et haute capacité), et ceci 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 routers des niveaux “meilleurs”), permettant au pair d’échantillonner les routers plus largement, optimisant en effet la sélection de pairs par escalade de colline randomisée. Ces stratégies seules fuient cependant des informations concernant les pairs du niveau supérieur du router par des 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, répondront aux 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 lors d’attaques de prédécesseur et de collecte selon le taux d’échec des pairs et le renouvellement du niveau. Une autre stratégie simple pour traiter les 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 traiter les attaques de prédécesseur pour les adversaires que le client contacte, les points de sortie des tunnels sortants resteraient également fixes. La sélection du pair à fixer au 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 pannes d’autres routers. Ces deux stratégies peuvent à leur tour être combinées, en 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 le 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, le 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 router I2P contiennent une netDb locale, mais tous les router ne participent pas à la DHT ou ne répondent pas aux requêtes de leaseset. Les router qui participent à la DHT et répondent aux requêtes de leaseset sont appelés ‘floodfill’. Les router peuvent être configurés manuellement comme floodfill, ou devenir automatiquement floodfill s’ils ont suffisamment de capacité et répondent à d’autres critères pour un fonctionnement fiable.
Les autres routers I2P stockeront leurs données et rechercheront des données en envoyant de simples requêtes ‘store’ et ’lookup’ aux floodfills. Si un router floodfill reçoit une requête ‘store’, il propagera l’information vers d’autres routers floodfill 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 router 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 (ex. site web I2P, serveur e-mail…)
Toutes ces informations sont signées par la partie qui les publie et vérifiées par tout router I2P qui utilise ou stocke 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, en interrogeant occasionnellement quelques serveurs SNTP (le round robin pool.ntp.org par défaut) et en détectant le décalage temporel entre les routers au niveau de la couche transport.
Quelques remarques supplémentaires sont également importantes.
LeaseSet non publiés et chiffrés : On peut vouloir que seules des personnes spécifiques puissent atteindre une destination. Cela 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: L’amorçage 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, plusieurs 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 s’amorcer. I2P appelle ce processus d’amorçage “reseeding”.
Évolutivité des recherches : Les recherches dans le réseau I2P sont itératives, non 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 à un autre floodfill les données. Les recherches itératives sont évolutives pour les grands réseaux DHT.
Protocoles de transport
La communication entre les 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. Ceux-ci ont remplacé les versions précédentes des protocoles, NTCP et SSU , qui sont maintenant dépréciés. 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 supporté et adresse IP dans la base de données réseau. Les routers avec accès aux réseaux IPv4 et IPv6 publics publieront habituellement quatre adresses, une pour chaque combinaison de NTCP2/SSU2 avec IPv4/IPv6.
SSU2 prend en charge et étend les objectifs de SSU. SSU2 présente de nombreuses similitudes avec d’autres protocoles modernes basés sur UDP tels que Wireguard et QUIC. En plus du transport fiable des messages réseau sur UDP, SSU2 fournit des fonctionnalités spécialisées pour la détection coopérative d’adresses IP en peer-to-peer, 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 de 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 volumineuses à des débits suffisants pour les utilisateurs domestiques. De plus, il devrait supporter des techniques pour adresser les obstacles réseau, comme la plupart des NAT ou pare-feux.
NTCP2 prend en charge et étend les objectifs de NTCP. Il fournit un transport efficace et entièrement chiffré des messages réseau via 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. À mesure que la puissance de calcul disponible augmentait et que la recherche cryptographique évoluait considérablement au fil des années, I2P a dû mettre à jour ses primitives et protocoles. Par conséquent, nous avons ajouté un concept de “types de chiffrement” et de “types de signature”, et étendu nos protocoles pour inclure ces identifiants et indiquer le support. Cela nous permet de mettre à jour périodiquement et d’étendre le support réseau pour la cryptographie moderne et de préparer le réseau pour de nouvelles primitives, sans briser 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 pour 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 rétrocompatibilité lors de la communication avec des routers plus anciens. Certains anciens protocoles ont été dépréciés et/ou complètement supprimés. Dans un proche avenir, nous commencerons la recherche sur une migration vers un chiffrement et des signatures post-quantiques (PQ) ou hybrides-PQ pour 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 via 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 par un pair qui ne devrait pas avoir accès à l’information — par exemple, lorsqu’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 lorsqu’un client veut envoyer un message à une destination — le router de l’expéditeur encapsulera ce message de données (avec d’autres messages) dans un garlic, chiffrera ce garlic avec la clé publique publiée dans le leaseSet du destinataire, et le transmettra à 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 transféré 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’elles ne soient pas honorées tant que les délais non triviaux ne sont pas déployés. Il est possible de router explicitement les messages garlic un nombre quelconque 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 transférant 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.
Étiquettes 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 de nonces de 32 octets. Bien que ce protocole soit encore supporté, la plupart 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é 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 délivrés et chiffre AES la charge utile comme auparavant, en utilisant la clé de session utilisée avec ce session tag, préfixée par le session tag lui-même. Lorsqu’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, préapprovisionnant le destinataire avec suffisamment de tags pour couvrir une salve de messages. Les messages garlic peuvent détecter la livraison réussie du tag en regroupant un petit message supplémentaire comme un clove (un “message de statut de livraison”) — quand 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 cloves exposés et contient des instructions pour que le destinataire renvoie le clove à l’expéditeur original (via un tunnel entrant, bien sûr). Quand 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 elles-mêmes ont une durée de vie très courte, après laquelle elles sont supprimées si elles ne sont pas utilisées. De plus, la quantité stockée pour chaque clé est limitée, tout comme le nombre de clés lui-même — si trop arrivent, des messages nouveaux ou anciens peuvent être supprimés. L’expéditeur garde trace de si les messages utilisant des session tags passent, et s’il n’y a pas suffisamment de communication, il peut supprimer ceux précédemment supposés correctement livrés, revenant au chiffrement ElGamal complet et coûteux.
ECIES-X25519-AEAD-Ratchet
ElGamal/AES+SessionTags nécessitait une surcharge substantielle de plusieurs façons. L’utilisation du processeur était élevée car ElGamal est assez lent. La bande passante était excessive car un grand nombre de session tags devaient être livrés à 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 ratchetées” ou alterné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 offre 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 synchronisé déterministe 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 HMAC SHA-256, et est initialisé à partir du résultat DH X25519. Les tags de session ne sont jamais transmis à l’avance ; ils ne sont inclus qu’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 50 prochains tags par exemple), la surcharge consistant à regrouper périodiquement un grand nombre de tags est supprimée.
Avenir
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 toujours croissante. 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 overlay conçu pour fonctionner au-dessus d’un réseau à 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 route restreinte, où il y a des limites aux pairs qui sont 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 élémentaire, les routes restreintes existent quand un pair est 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 de 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 via 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 soit réutiliser leur pool exploratoire, publiant les passerelles entrantes de certains d’entre eux dans 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 à 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) soit indirectement à travers ses tunnels sortants. Quand les routers auxquels le pair a des connexions directes veulent l’atteindre (pour transférer des messages de tunnel, par exemple), ils priorisent simplement leur connexion directe par rapport à 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 capables 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 celles-ci. Nous prenons maintenant en charge UPnP pour ouvrir automatiquement les ports de pare-feu. Nous prenons en charge 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’adresse garantissent que les sauts de tunnel peuvent se connecter avant que le tunnel ne soit construit. GeoIP et l’identification par pays nous permettent d’éviter les pairs dans des pays avec des pare-feu restrictifs. Le support pour les routers “cachés” derrière ces pare-feu s’est amélioré. Certaines implémentations supportent également les connexions vers des 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épart en gardant à l’esprit les services à latence variable. Au niveau le plus élémentaire, les applications fonctionnant au-dessus d’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 soient passés, 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 détient le clove (qui lui-même serait probablement un message garlic) le transfère simplement comme demandé — vers un router, vers un tunnel, ou, le 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 pris en charge dans diverses applications de messagerie, comme i2p-bote. Au niveau 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 d’intergiciel orienté message, 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 cependant pas de concepts ou d’algorithmes novateurs, mais d’une ingénierie soignée 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 également la page de comparaisons de réseaux . Notez que ces descriptions ont été écrites par jrandom en 2003 et peuvent ne plus ê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 assume 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 contourner de manière transparente la congestion ou d’autres défaillances réseau, d’exploiter des chemins redondants et d’équilibrer la charge des données sur les ressources disponibles. Alors que Tor offre la fonctionnalité utile d’outproxy 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 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 existe de nombreuses similitudes lors de la comparaison des réseaux de base. 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 composant la requête sortiraient par un ou plusieurs tunnels sortants et les paquets composant 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 suffire à traiter les attaques de prédécesseur, si un passage à des tunnels bidirectionnels s’avérait nécessaire, nous pourrions simplement construire un tunnel entrant et un tunnel sortant le long des mêmes routers.
Un autre problème d’anonymat survient avec l’utilisation par Tor de la création de tunnels télescopiques, car un simple comptage de paquets et des mesures de chronométrage lorsque les cellules dans 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 utilise un seul message de sorte que ces données ne soient pas exposées. Protéger la position dans un tunnel est important, car un adversaire serait sinon 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 orientation — Tor vise à offrir un outproxying 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 tous deux leurs forces et leurs faiblesses. Les développeurs d’I2P ont considéré 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 rareté des ressources 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 étapes initiales de la conception d’I2P — prouvant 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 clairement montré que l’attention d’I2P devait rester strictement centrée sur la fourniture d’une couche de communication anonyme générique, plutôt que comme composant de Freenet. Au cours des années, les développeurs de Freenet ont reconnu les faiblesses de l’ancienne conception, les amenant à suggérer qu’ils auraient besoin d’une couche “premix” pour offrir un anonymat substantiel. En d’autres termes, Freenet doit fonctionner 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 mixage à 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, alors espérons que l’équipe Freenet poursuivra ses efforts dans cette direction, sinon en réutilisant simplement (ou en aidant à améliorer, si nécessaire) les 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 déroule dans les couches au-dessus. En soi, I2P peut être vu comme une couche IP anonyme et sécurisée, et la bibliothèque de streaming fournie 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 entrer dans le réseau I2P ou en sortir, plus diverses 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 (imitant les sockets TCP), et l’implémentation prend en charge un protocole de 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 de bande passante de la retransmission des messages perdus et la latence de messages multiples.
De plus, compte tenu du coût relativement élevé des messages suivants, le protocole de la bibliothèque de streaming pour la planification et la livraison des 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 via 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 s’y adapte généralement) et la réponse regroupe le SYN, FIN, ACK et la petite charge utile (de nombreuses réponses HTTP s’y adaptent). 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 (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 Naming and Address Book .
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 “la majorité l’emporte”. 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 de 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’humain, basé sur un réseau de confiance, ne sacrifiant que l’exigence que tous les noms lisibles par l’humain soient globalement uniques en n’imposant qu’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 de carnet d’adresses local pour “Alice” qui font référence à des destinations différentes. Les gens peuvent encore 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 cependant pas l’utilisation de services de type DNS, 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 s’appuie encore sur les registraires et les autorités de certification, tandis qu’avec I2P, les requêtes envoyées vers 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 bon nombre des 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 compte tenu de 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 conduire 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 pour 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 services 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 cliente la plus populaire et polyvalente d’I2P, permettant le 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 interrogation du 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 outproxy — les préoccupations d’anonymat et de sécurité inhérentes à un réseau de mixage qui transmet des données vers et depuis le mixage ont maintenu la conception d’I2P axée sur la fourniture d’un réseau anonyme capable de répondre aux besoins des utilisateurs 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 transmet la requête vers eux. Ces destinations sont simplement des instances I2PTunnel “server” 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 n’indique pas automatiquement aux autres personnes de passer par vous comme proxy. Bien que les outproxies aient des faiblesses inhérentes, ils 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 à la plupart des applications d’être utilisées. 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 tout serveur web peut être utilisé. N’importe qui peut faire fonctionner un “client” pointant vers l’un des serveurs IRC hébergés anonymement, chacun d’eux faisant fonctionner 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é depuis le client Snark de mjw
Fourni avec l’installation I2P, I2PSnark offre un client BitTorrent anonyme simple avec des capacités multitorrent, exposant toutes les fonctionnalités à travers une interface web HTML simple.
I2Pmail / Susimail
Développé par : postman, susi23, mastiejaner
I2Pmail est plus un service qu’une application — postman offre à la fois 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 utilisateurs 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 contre les dénis de service avec des quotas augmentés par hashcash. De plus, chaque utilisateur a le contrôle de sa stratégie de traitement par lots avant la livraison via les outproxies mail.i2p, qui sont séparés des serveurs SMTP et POP3 mail.i2p — à la fois les outproxies et les 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.