2011-03-06 21:34:26 +00:00
|
|
|
{% extends "_layout_fr.html" %}
|
2011-03-06 23:24:10 +00:00
|
|
|
{% block title %}Présentation d'I2P{% endblock %}
|
2011-03-06 21:34:26 +00:00
|
|
|
{% block content %}
|
2011-03-23 09:28:14 +00:00
|
|
|
Traduction de mars 2011. <a href="techintro.html">Version anglaise actuelle</a>
|
2011-12-21 18:20:26 +00:00
|
|
|
<h1 class="title">I2P: <span style="font-size:medium,">Une plate-forme modulaire pour la communication anonyme</span></h1>
|
2011-03-06 21:34:26 +00:00
|
|
|
<div id="toc">
|
|
|
|
<h2>Table des matières</h2>
|
|
|
|
<ul>
|
|
|
|
<li><a href="#intro">Introduction</a></li>
|
2011-03-23 23:43:03 +00:00
|
|
|
<li><a href="#op">Fonctionnement d'I2P</a>
|
2011-03-06 21:34:26 +00:00
|
|
|
<ul>
|
|
|
|
<li><a href="#op.overview">Aperçu</a></li>
|
|
|
|
<li><a href="#op.tunnels">Tunnels</a></li>
|
2011-03-21 11:22:48 +00:00
|
|
|
<li><a href="#op.netdb">Base de données du réseau</a></li>
|
2011-03-06 21:34:26 +00:00
|
|
|
<li><a href="#op.transport">Protocoles de transport </a></li>
|
2011-03-23 23:43:03 +00:00
|
|
|
<li><a href="#op.crypto">Cryptographie</a></li></ul>
|
2011-03-06 21:34:26 +00:00
|
|
|
</li>
|
2011-03-23 23:43:03 +00:00
|
|
|
<li><a href="#future">L'avenir</a></li>
|
|
|
|
<li><a href="#similar">Systèmes similaires</a>
|
|
|
|
<ul>
|
|
|
|
<li><a href="#similar.tor">Tor</a></li>
|
|
|
|
<li><a href="#similar.freenet">Freenet</a></li>
|
|
|
|
</ul>
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
</li>
|
|
|
|
<li><a href="#app">Appendice A: la couche applicative</a>
|
|
|
|
<ul>
|
|
|
|
<li><a href="#app.streaming">Bibliothèque de flux (streaming)</a></li>
|
|
|
|
<li><a href="#app.naming">Bibliothèque de nommage et carnet d'adresses</a></li>
|
|
|
|
<li><a href="#app.syndie">Syndie</a></li>
|
|
|
|
<li><a href="#app.i2ptunnel">I2PTunnel</a></li>
|
|
|
|
<li><a href="#app.i2pbt">i2p-bt</a></li>
|
|
|
|
<li><a href="#app.i2psnark">I2PSnark</a></li>
|
|
|
|
<li><a href="#app.robert">Robert</a></li>
|
|
|
|
<li><a href="#app.pybit">PyBit</a></li>
|
|
|
|
<li><a href="#app.i2phex">I2Phex</a></li>
|
|
|
|
<li><a href="#app.i2pmail">I2Pmail/susimail</a></li>
|
|
|
|
<li><a href="#app.i2pbote">I2P-Bote</a></li>
|
|
|
|
<li><a href="#app.i2pmessenger">I2P-messenger</a></li>
|
|
|
|
</ul>
|
|
|
|
</li>
|
2011-03-06 21:34:26 +00:00
|
|
|
</ul>
|
|
|
|
</div>
|
|
|
|
|
|
|
|
<br/>
|
|
|
|
<h1 id="intro">Introduction</h1>
|
|
|
|
<p>
|
2011-03-21 11:22:48 +00:00
|
|
|
I2P est une couche réseau à commutation de paquets, modulaire, à tolérance de panne, auto-adaptative, et anonyme
|
2011-03-06 23:24:10 +00:00
|
|
|
sur laquelle peuvent fonctionner n'importe quel nombre d'applications conçues pour l'anonymat ou la sécurité.
|
|
|
|
Chacune de ces applications peut gérer ses propres contraintes d'anonymat, de latence et de débit,
|
|
|
|
sans avoir à se soucier d'une implémentation correcte d'un
|
|
|
|
<a href="http://en.wikipedia.org/wiki/Mix_network">réseau croisé (mixnet)</a>
|
|
|
|
d'accès libre qui leur permet de mêler leur activité au grand groupe d'utilisateurs anonymisés
|
|
|
|
déjà présents sur I2P.
|
2011-03-06 21:34:26 +00:00
|
|
|
</p>
|
|
|
|
<p>
|
2011-03-06 23:24:10 +00:00
|
|
|
Des applications d'ores et déjà disponibles offrent un large éventail de fonctionnalités Internet classiques
|
|
|
|
<b>mais anonymes</b>: exploration web, hébergement, chat, partage de fichiers, e-mail,
|
|
|
|
blogs et publications simultanées, newsgroups, tout comme plusieurs autres applications en cours de développement.
|
2011-03-06 21:34:26 +00:00
|
|
|
<ul>
|
2011-03-06 23:24:10 +00:00
|
|
|
<li>Exploration web: en utilisant tout navigateur compatible avec un serveur mandataire (proxy).</li>
|
|
|
|
<li>Chat: IRC, Jabber, <a href="#app.i2pmessenger">I2P-messenger</a>, ou tout autre compatible proxy.</li>
|
|
|
|
<li>Partage de fichiers: <a href="#app.i2psnark">I2PSnark</a>, <a href="#app.robert">Robert</a>,
|
2011-03-06 21:34:26 +00:00
|
|
|
<a href="#app.i2phex">I2Phex</a>, <a href="#app.pybit">PyBit</a>, <a href="#app.i2pbt">I2P-bt</a>
|
2011-03-06 23:24:10 +00:00
|
|
|
et d'autres.
|
2011-03-06 21:34:26 +00:00
|
|
|
</li>
|
2011-03-06 23:24:10 +00:00
|
|
|
<li>E-mail: <a href="#app.i2pmail">susimail</a> et <a href="#app.i2pbote">I2P-Bote</a>.</li>
|
|
|
|
<li>Newsgroups: via un lecteur de newsgroups compatible proxy.</li>
|
2011-03-06 21:34:26 +00:00
|
|
|
</ul>
|
|
|
|
<p>
|
2011-03-09 12:39:38 +00:00
|
|
|
Contrairement aux sites web hébergés sur des réseaux de distribution de contenu comme
|
|
|
|
<a href="#similar.freenet">Freenet</a> ou <a href="http://www.ovmj.org/GNUnet/">GNUnet</a>,
|
|
|
|
les services hébergés sur I2P sont totalement interactifs: il y des moteurs de recherches traditionnels,
|
|
|
|
des BBS, des blogs sur lesquels vous pouvez déposer des commentaires, des sites pilotés par bases de données,
|
|
|
|
et des ponts pour interroger les systèmes statiques comme Freenet sans devoir en faire une installation locale.
|
2011-03-06 21:34:26 +00:00
|
|
|
</p>
|
|
|
|
<p>
|
2011-03-09 12:39:38 +00:00
|
|
|
Grâce à toutes ces applications prenant l'anonymat en considération, I2P prend le rôle
|
|
|
|
de plaque tournante "orientée messages": les applications demandent à envoyer des données
|
|
|
|
à un identifiant cryptographique (une "destination") et I2P prend soin de s'assurer qu'elles
|
|
|
|
y parviennent en toute sécurité et anonymat. I2P fournit aussi une bibliothèque simple pour les
|
|
|
|
<a href="#app.streaming">flux</a> (streaming) pour permettre le transfert fiable et ordonné de messages
|
|
|
|
de flux anonymes, en offrant de façon transparente un algorithme de contrôle de congestion basé sur TCP
|
|
|
|
et optimisé pour les applications à haute bande passante au sein réseau.
|
|
|
|
Bien qu'il y ait eu plusieurs simple mandataires SOCKS disponibles pour attirer des applications existantes
|
2011-03-21 11:22:48 +00:00
|
|
|
dans le réseau, leur intérêt a été limité car presque toutes exposent intrinsèquement ce qui, du point de vue
|
2011-03-09 12:39:38 +00:00
|
|
|
de l'anonymat, s'avère être des informations sensibles. La seule façon d'avancer est d'analyser complètement
|
|
|
|
une application pour s'assurer d'un fonctionnement irréprochable, et pour y aider, nous fournissons
|
|
|
|
une série d'API dans divers langages, qui permettent d'en faire le plus possible en dehors du réseau.
|
|
|
|
</p>
|
2011-03-06 21:34:26 +00:00
|
|
|
<p>
|
2011-03-10 10:45:56 +00:00
|
|
|
I2P n'est pas un projet de recherche (universitaire, commercial, ou gouvernemental), mais un effort
|
|
|
|
d'ingénierie dont le but est de faire tout le nécessaire pour assurer
|
|
|
|
un niveau d'anonymat suffisant à ceux qui en ont besoin. Il est en développement actif
|
|
|
|
depuis les débuts de 2003 avec un développeur à temps plein et un groupe dédié de
|
|
|
|
contributeurs à temps partiel répartis dans le monde entier. Tout le travail fourni pour I2P
|
|
|
|
est "open source" et gratuitement disponible sur le <a href="index_fr.html">site</a>,
|
|
|
|
pour lequel la plus grande partie du code est publié directement dans le domaine public, bien que
|
|
|
|
faisant usage de quelques routines cryptographiques sous licences de style BSD. L'équipe d'I2P
|
|
|
|
ne contrôle pas le cadre légal de publication des applications tierce partie. Il y a plusieurs
|
|
|
|
applications disponibles sous licence GPL (<a href="#app.i2ptunnel">I2PTunnel</a>,
|
2011-03-06 21:34:26 +00:00
|
|
|
<a href="#app.i2pmail">susimail</a>, <a href="#app.i2psnark">I2PSnark</a>,
|
2011-03-10 10:45:56 +00:00
|
|
|
<a href="#app.i2phex">I2Phex</a> et d'autres).
|
|
|
|
Le <a href="http://www.i2p.net/halloffame">financement</a> d'I2P vient entièrement de dons,
|
|
|
|
et ne bénéficie pour l'instant d'aucune dispense d'impôts de la part de quelque juridiction que ce soit,
|
|
|
|
vu que la plupart des développeurs sont anonymes.
|
2011-03-06 21:34:26 +00:00
|
|
|
</p>
|
2011-03-10 10:45:56 +00:00
|
|
|
<h1 id="op">Fonctionnement</h1>
|
|
|
|
<h2 id="op.overview">Aperçu</h2>
|
2011-03-06 21:34:26 +00:00
|
|
|
<p>
|
2011-03-10 10:45:56 +00:00
|
|
|
Pour comprendre le fonctionnement d'I2P, quelques concepts fondamentaux sont prérequis.
|
|
|
|
Tout d'abord, I2P fait une séparation stricte entre le logiciel participant au réseau
|
|
|
|
(un "routeur") et les point terminaux anonymes (les "destinations") associés aux applications particulières.
|
|
|
|
Que quelqu'un utilise I2P n'est généralement pas un secret. Ce qui est caché, c'est
|
|
|
|
c'est tout ce que l'utilisateur en fait, aussi bien qu'à quelle destination particulière le routeur est connecté.
|
|
|
|
En général, l'utilisateur dispose sur son routeur de plusieurs destinations locales: une, par exemple,
|
|
|
|
pour se connecter en proxy aux serveurs IRC, une autre pour héberger son propre site Internet
|
|
|
|
anonyme ("eepsite"), une autre pour une instance I2Phex, une autre encore pour les torrents, etc...
|
2011-03-06 21:34:26 +00:00
|
|
|
</p>
|
|
|
|
<p>
|
2011-03-10 10:45:56 +00:00
|
|
|
Un autre concept majeur est celui de "tunnel".
|
|
|
|
Un tunnel un chemin orienté passant par une liste de routeurs explicitement sélectionnés.
|
|
|
|
Un cryptage en couches est utilisé pour que chacun des routeurs n'en puisse décrypter qu'une seule.
|
|
|
|
L'information décryptée contient l'IP du routeur suivant, avec l'information cryptée à faire suivre.
|
|
|
|
Chaque tunnel a un point de départ (le premier routeur, appelé "passerelle")
|
|
|
|
et un point terminal. Les messages ne peuvent être envoyés que dans un seul sens. Pour les réponses,
|
|
|
|
un autre tunnel est nécessaire.
|
2011-03-06 21:34:26 +00:00
|
|
|
</p>
|
2011-12-21 18:20:26 +00:00
|
|
|
<div class="box" style="text-align:center;">
|
2011-03-10 15:02:04 +00:00
|
|
|
<img src="_static/images/tunnels_fr.png" alt="Schéma de tunnels entrant et sortant"
|
2011-03-10 10:45:56 +00:00
|
|
|
title="Schéma de tunnels entrant et sortant" />
|
2011-03-06 21:34:26 +00:00
|
|
|
<br /><br />
|
2011-03-10 10:45:56 +00:00
|
|
|
Figure 1: Les deux types de tunnels: entrant et sortant.
|
2011-03-06 21:34:26 +00:00
|
|
|
</div>
|
2011-12-21 18:20:26 +00:00
|
|
|
<br/>
|
2011-03-06 21:34:26 +00:00
|
|
|
<p>
|
2011-03-10 10:59:00 +00:00
|
|
|
Il y deux types de tunnels:
|
|
|
|
Les <b>tunnels "sortants"</b> expédient des messages depuis le créateur du tunnel, alors
|
|
|
|
que les <b>tunnels "entrants"</b> ramènent des messages vers le créateur du tunnel.
|
|
|
|
La combinaison de ces deux tunnels permet aux utilisateurs de s'envoyer des messages les uns aux autres.
|
|
|
|
L'expéditeur ("Alice" dans l'illustration ci-dessus) crée un tunnel sortant,
|
|
|
|
et le récepteur ("Bob" 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 envoie jusqu'au point terminal ("Bob").
|
2011-03-10 16:16:47 +00:00
|
|
|
Le point terminal du tunnel sortant devra pouvoir envoyer le message vers la passerelle du tunnel entrant.
|
|
|
|
Pour le permettre, l'expéditeur ("Alice") ajoute à son message crypté des instructions cryptées à l'intention
|
|
|
|
du point terminal sortant. Une fois décryptées par celui-ci, il dispose alors des informations nécessaires
|
2011-03-21 11:22:48 +00:00
|
|
|
au transfert vers la bonne passerelle entrante (la passerelle vers "Bob").
|
2011-03-06 21:34:26 +00:00
|
|
|
</p>
|
|
|
|
<p>
|
2011-03-10 16:16:47 +00:00
|
|
|
Le troisième concept fondamental est la <b>"base de données"</b> I2P (ou "netDb"):
|
|
|
|
une paire d'algorithmes utilisés pour le partage des métadonnées du réseau. Les deux types de métadonnées
|
2011-03-10 16:17:25 +00:00
|
|
|
transportées sont la <b>"routerInfo"</b> et les <b>"jeux de baux"</b> (leaseSets):
|
2011-03-10 16:16:47 +00:00
|
|
|
la routerInfo donne aux routeurs les données nécessaires pour contacter un autre routeur particulier
|
2011-03-10 16:17:25 +00:00
|
|
|
(ses clés publiques, adresse de transport, etc...), et les jeux de baux donnent au routeurs les informations
|
2011-03-10 16:16:47 +00:00
|
|
|
nécessaires pour joindre une destination particulière. Un jeu de baux contient un certain nombre de "baux".
|
2011-03-10 16:17:25 +00:00
|
|
|
Chacun de ces baux indique une passerelle de tunnel qui permet d'atteindre une destination particulière.
|
2011-03-10 16:16:47 +00:00
|
|
|
Détail complet des informations contenues dans un bail:
|
2011-03-06 21:34:26 +00:00
|
|
|
<ul>
|
2011-03-15 09:56:05 +00:00
|
|
|
<li>Passerelle entrante pour un tunnel permettant d'atteindre une certaine destination.</li>
|
|
|
|
<li>Moment d'expiration du tunnel.</li>
|
|
|
|
<li>Paire de clés publiques pour pouvoir crypter les messages (à envoyer à travers le tunnel
|
|
|
|
et atteindre la destination).</li>
|
2011-03-06 21:34:26 +00:00
|
|
|
</ul>
|
2011-03-21 11:22:48 +00:00
|
|
|
Les routeurs envoient eux-mêmes directement leur "routerInfo" à la base de données,
|
2011-03-15 09:56:05 +00:00
|
|
|
alors que les jeux de baux sont envoyés par des tunnels sortants (ils doivent rester anonymes, pour
|
|
|
|
empêcher toute tentative de corrélation entre un routeur et ses jeux de baux).
|
2011-03-06 21:34:26 +00:00
|
|
|
</p>
|
2011-03-15 09:56:05 +00:00
|
|
|
<p>On peut combiner les trois concepts exposés ci-dessus pour établir des connexions effectives dans le réseau.
|
2011-03-06 21:34:26 +00:00
|
|
|
</p>
|
|
|
|
<p>
|
2011-03-15 09:56:05 +00:00
|
|
|
Pour créer ses propres tunnels entrants et sortants, Alice fait une recherche dans la "netDb" pour obtenir
|
|
|
|
des "routerInfo".
|
|
|
|
De cette façon, elle constitue des listes de pairs qu'elle peut utiliser en tant que sauts dans ses tunnels.
|
|
|
|
Ensuite elle peut envoyer au premier saut un message élaboré, demandant la création d'un tunnel, et de faire passer
|
|
|
|
cette demande plus loin, jusqu'à ce que le tunnel soit entièrement créé.
|
2011-03-06 21:34:26 +00:00
|
|
|
</p>
|
2011-12-21 18:20:26 +00:00
|
|
|
<div class="box" style="text-align:center;">
|
2011-03-10 16:17:25 +00:00
|
|
|
<img src="_static/images/netdb_get_routerinfo_1_fr.png" alt="Demande d'informations sur d'autres routeurs"
|
|
|
|
title="Demande d'informations sur d'autres routeurs" />
|
2011-03-06 21:34:26 +00:00
|
|
|
|
2011-03-10 16:17:25 +00:00
|
|
|
<img src="_static/images/netdb_get_routerinfo_2_fr.png"
|
|
|
|
alt="Construction d'un tunnel grâce aux informations sur les routeurs"
|
|
|
|
title="Construction d'un tunnel grâce aux informations sur les routeurs" />
|
2011-03-06 21:34:26 +00:00
|
|
|
<br /><br />
|
2011-03-10 10:45:56 +00:00
|
|
|
Figure 2: Les informations sur les routeurs servent à construire les tunnels.
|
2011-03-06 21:34:26 +00:00
|
|
|
</div>
|
2011-12-21 18:20:26 +00:00
|
|
|
<br/>
|
2011-03-06 21:34:26 +00:00
|
|
|
<p>
|
2011-03-15 09:56:05 +00:00
|
|
|
Quand Alice désire envoyer un message à Bob, elle recherche tout d'abord dans la netDb
|
|
|
|
un jeu de baux de Bob, ce qui lui donne ses passerelles entrantes de tunnels.
|
|
|
|
Elle choisit ensuite un de ses tunnels sortants et y envoie le message avec les
|
|
|
|
instructions pour le point terminal afin qu'il fasse suivre le message à l'une des
|
|
|
|
passerelles de tunnels entrants de Bob. Quand le point terminal reçois ces instructions,
|
|
|
|
il transfère le message comme demandé, et quand la passerelle de tunnel entrant de Bob le reçoit,
|
|
|
|
elle le transfère dans le tunnel vers le routeur de Bob. Si Alice veut que Bob puisse répondre,
|
|
|
|
elle doit lui indiquer explicitement sa propre destination en tant qu'élément du message lui-même.
|
|
|
|
On y parvient en introduisant une couche de haut niveau, ce qui est fait par la bibliothèque de flux
|
|
|
|
<a href="#app.streaming">flux</a> (streaming).
|
|
|
|
Alice peut aussi raccourcir le temps de réponse en fournissant dans le message son jeu de baux le plus récent,
|
|
|
|
en sorte que Bob soit dispensé d'une requête à netDb quand il voudra répondre. Mais ceci est optionnel.
|
2011-03-06 21:34:26 +00:00
|
|
|
</p>
|
2011-12-21 18:20:26 +00:00
|
|
|
<div class="box" style="text-align:center;">
|
2011-03-10 16:17:25 +00:00
|
|
|
<img src="_static/images/netdb_get_leaseset_fr.png" alt="Connexion de tunnels grâce au jeux de baux"
|
|
|
|
title="Connexion de tunnels grâce au jeux de baux" />
|
2011-03-06 21:34:26 +00:00
|
|
|
<br /><br />
|
2011-03-10 16:17:25 +00:00
|
|
|
Figure 3: Les jeux de baux sont utilisés pour connecter les tunnels sortants et entrants.
|
2011-03-06 21:34:26 +00:00
|
|
|
</div>
|
2011-12-21 18:20:26 +00:00
|
|
|
<br/>
|
2011-03-06 21:34:26 +00:00
|
|
|
<p>
|
2011-03-15 09:56:05 +00:00
|
|
|
De même que les tunnels ont eux-mêmes un cryptage étagé pour empêcher un dévoilement non autorisé
|
|
|
|
par les pairs au sein du réseau (comme la couche transport le fait elle-même pour protéger des pairs
|
|
|
|
les contenus en dehors du réseau), il est nécessaire d'ajouter une couche additionnelle
|
|
|
|
de cryptage de bout en bout pour cacher le message au point terminal sortant et à la passerelle entrante.
|
|
|
|
Ce cryptage "<a href="#op.garlic">en tête d'ail</a>" (garlic)
|
|
|
|
fait que le routeur d'Alice va "emballer" de multiples messages dans un seul message
|
|
|
|
(la tête d'ail="garlic message"), crypté pour une certaine clé publique en sorte que les pairs intermédiaires
|
|
|
|
ne puissent déterminer ni combien il y a de messages (des gousses ou caïeux si on veut pousser plus loin
|
|
|
|
l'analogie botanique) dans le bulbe, ni si ces messages sont amers ou sucrés (ce qu'ils disent), ni si ces gousses
|
|
|
|
vont servir à frotter un plat à cassoulet, finir fondus dans un gigot
|
|
|
|
ou hachés/grillés sur une dorade (à qui elles sont destinées). Pour une communication typique
|
|
|
|
de point à point entre Alice et Bob, la tête d'ail va être cryptée avec la clé publique annoncée
|
|
|
|
dans le jeu de baux de Bob, ce qui permet le cryptage sans donner la clé publique du routeur de Bob.
|
2011-03-06 21:34:26 +00:00
|
|
|
</p>
|
|
|
|
<p>
|
2011-03-15 09:56:05 +00:00
|
|
|
Une autre donnée importante qu'il faut garder à l'esprit, est qu'I2P est entièrement basé sur l'échange
|
|
|
|
de messages et que quelques messages pourraient se perdre en chemin. Les applications utilisant I2P peuvent
|
|
|
|
utiliser les interfaces "orientées messages" et s'occuper de leur propre contrôle de congestion et besoins de
|
|
|
|
fiabilité, mais elles seront mieux servies en utilisant la bibliothèque de <a href="#app.streaming">streaming</a>
|
|
|
|
fournie en vue de voir I2P comme un réseau "orienté flux".
|
2011-03-06 21:34:26 +00:00
|
|
|
</p>
|
2011-03-15 09:56:05 +00:00
|
|
|
<h2 id="op.tunnels">Les tunnels</h2>
|
2011-03-06 21:34:26 +00:00
|
|
|
<p>
|
2011-03-15 09:56:05 +00:00
|
|
|
Les tunnels entrants et sortants partagent les mêmes principes de fonctionnement.
|
|
|
|
La passerelle de tunnel accumule un certain nombre de messages, en les pré-traitant éventuellement
|
|
|
|
en vue d'une distribution dans le tunnel. Ensuite, elle crypte ces données préparées
|
|
|
|
et les transfère vers le premier saut. Ce pair et les participants suivants du tunnel
|
|
|
|
y ajoutent une couche de cryptage après avoir vérifié qu'il ne s'agit pas d'un doublon et avant
|
|
|
|
de le transférer au pair suivant. Le message arrive éventuellement au point terminal
|
|
|
|
où les messages sont de nouveau séparés et transférés comme demandé. La différence réside
|
|
|
|
dans l'action du créateur du tunnel: pour les tunnels entrants, le créateur est le point terminal,
|
|
|
|
et il déchiffre simplement toutes les couches ajoutées, alors que pour les tunnels sortants,
|
|
|
|
le créateur est la passerelle, et il pré-déchiffre toutes les couches pour qu'une fois toutes
|
2011-03-21 11:22:48 +00:00
|
|
|
les couches de cryptage par saut ajoutées, le message arrive en clair au point terminal.
|
2011-03-06 21:34:26 +00:00
|
|
|
</p>
|
|
|
|
<p>
|
2011-03-15 09:56:05 +00:00
|
|
|
Le choix de pairs spécifiques pour passer les messages, ainsi que la définition de leur séquence,
|
2011-03-21 11:22:48 +00:00
|
|
|
est important pour une bonne compréhension de l'anatomie et des performances d'I2P.
|
2011-03-15 09:56:05 +00:00
|
|
|
Alors que la base de données dispose de ses propres critères de sélection lors du choix
|
2011-03-21 11:22:48 +00:00
|
|
|
des pairs à interroger et pour mémoriser les entrées correspondantes, les créateurs de tunnels utilisent
|
2011-03-15 09:56:05 +00:00
|
|
|
n'importe quels pairs du réseau et dans n'importe quel ordre (et même un nombre de fois indéfini) dans le
|
|
|
|
même tunnel. Si des données précises de latence et de capacité étaient globalement connues, la sélection et
|
|
|
|
le tri seraient pilotés par les besoins particuliers du client en relation avec leur modèle de sécurité.
|
|
|
|
Malheureusement, la latence et les capacités ne sont pas simples à collecter anonymement, et avoir besoin
|
|
|
|
besoin de pairs sans confiance établie pour fournir ces informations pose de sérieux problèmes d'anonymat.
|
2011-03-06 21:34:26 +00:00
|
|
|
</p>
|
|
|
|
<p>
|
2011-03-15 09:56:05 +00:00
|
|
|
Du point de vue de l'anonymat, la technique la plus simple serait de sélectionner des pairs au hasard
|
|
|
|
dans la totalité du réseau, de les trier aléatoirement, et de les utiliser dans cet ordre ad vitam æternam.
|
|
|
|
Mais pour les performances, la plus simple façon serait de ne retenir que les plus rapides disposant de la
|
|
|
|
réserve de capacité suffisante, de répartir la charge sur différents pairs pour gérer les défaillances
|
|
|
|
de façon transparente, et de recréer le tunnel chaque fois que l'information de capacité est modifiée.
|
|
|
|
alors que la première façon est à la fois fragile et inefficace, la seconde demande des informations
|
|
|
|
indisponibles et n'offre qu'un anonymat insuffisant.
|
|
|
|
I2P fonctionne plutôt en utilisant une gamme de stratégies de sélection des pairs,
|
|
|
|
couplée à du code d'évaluation du niveau d'anonymat pour organiser ces pairs selon leur profil.
|
2011-03-06 21:34:26 +00:00
|
|
|
</p>
|
|
|
|
<p>
|
2011-03-21 11:22:48 +00:00
|
|
|
À la base, I2P classe en permanence les pairs avec lesquels il interagit en mesurant indirectement
|
2011-03-15 09:56:05 +00:00
|
|
|
leur comportement: par exemple, quand un pair répond à une requête netDb en 1,3s,
|
|
|
|
cette latence d'aller-retour est enregistrée dans les profils pour tous les routeurs impliqués
|
|
|
|
dans les deux tunnels (entrant et sortant) au travers desquels la requête et la réponse sont passées,
|
|
|
|
ainsi que le profil du pair. Les mesures directes, telles que la latence de la couche transport ou la congestion,
|
|
|
|
ne sont pas utilisées en tant que données de profil car elles peuvent être manipulées au routeur mesurant,
|
|
|
|
l'exposant ainsi à des attaques basiques. En rassemblant ces profils, une série de calculs est lancée
|
|
|
|
sur chacun pour synthétiser ses performances: sa latence, sa capacité à gérer beaucoup d'activités, s'il est
|
|
|
|
actuellement surchargé, et à quel point il semble bien intégré au réseau.
|
|
|
|
Les résultats de ces calculs sont alors comparés pour les pairs actifs afin de
|
|
|
|
répartir les routeurs en quatre groupes: les rapides à hautes capacités, ceux de hautes capacités, les non
|
|
|
|
défaillants, et les défaillants. Les seuils de ces groupes sont déterminés dynamiquement, et comme ils n'utilisent
|
|
|
|
actuellement que des algorithmes assez simples, il y a d'autres possibilités.
|
2011-03-06 21:34:26 +00:00
|
|
|
</p>
|
2011-03-15 09:56:05 +00:00
|
|
|
<p> Pour utiliser ces données de profils, la stratégie de sélection la plus simple consiste à
|
|
|
|
les prendre aléatoirement dans le premier groupe (celui des plus rapides à fortes capacités),
|
|
|
|
et c'est ce qui est actuellement employé pour les tunnels clients.
|
|
|
|
Les tunnels exploratoires (utilisés pour les communications avec la base de données et la gestion des tunnels)
|
|
|
|
prennent les pairs aléatoirement dans le troisième groupe des non défaillants (qui inclut ceux du premier),
|
|
|
|
ce qui permet une base de sélection plus étoffée avec pour effet l'optimisation de la sélection
|
|
|
|
via une progression aléatoire. Ces stratégies laissent cependant fuir des informations concernant les pairs
|
2011-03-21 11:22:48 +00:00
|
|
|
du premier groupe utilisables par des attaques du type collecte de base de données et du type prédécesseur.
|
2011-03-15 09:56:05 +00:00
|
|
|
En retour, il y a plusieurs alternatives qui bien que n'équilibrant pas la charge aussi uniformément,
|
|
|
|
bloquent les attaques lancées par certains types d'ennemis.
|
2011-03-06 21:34:26 +00:00
|
|
|
</p>
|
|
|
|
<p>
|
2011-03-15 09:56:05 +00:00
|
|
|
En sélectionnant une clé aléatoire et en triant les pairs selon leur distance "eXORisée" à cette clé,
|
|
|
|
la fuite d'information est réduite pour les attaques prédécesseur et collecte, suivant le taux de défaillance
|
|
|
|
des pairs et le renouvellement des seuils des groupes. Une autre stratégie simple pour parer aux
|
|
|
|
attaques par collecte de la netDb consiste simplement à obliger la passerelle entrante à figer
|
2011-03-21 11:22:48 +00:00
|
|
|
aléatoirement la position des pairs situés plus loin dans le tunnel. Pour gérer les attaques de prédécesseur
|
2011-03-15 09:56:05 +00:00
|
|
|
par des adversaires que le client contacte, le point terminal de tunnel devrait aussi rester statique.
|
|
|
|
La sélection du pair à figer au point le plus vulnérable doit bien sûr être limitée en durée,
|
2011-03-21 11:22:48 +00:00
|
|
|
car tous les pairs sont susceptibles de défaillance, et donc elle doit soit être ajustée en réaction, ou
|
2011-03-15 09:56:05 +00:00
|
|
|
préventivement empêchée pour simuler le MTBF (temps moyen entre défaillances) mesuré d'autres routeurs.
|
|
|
|
Ces deux stratégies peuvent ensuite être combinées, en utilisant un pair vulnérable figé et un tri sur XOR
|
|
|
|
dans les tunnels eux-mêmes. Une stratégie plus stricte consisterait à définir les pairs précis et leur ordre
|
|
|
|
dans un tunnel potentiel, en utilisant uniquement de pairs qui accepteraient tous de participer de la même
|
|
|
|
façon à chaque fois. Ceci diffère du tri basé sur le résultat de l'XOR en ce que le prédécesseur
|
|
|
|
et le successeur de chaque pair serait toujours les mêmes, alors que le tri sur l'XOR ne permet que de s'assurer
|
|
|
|
que leur ordre ne change pas.
|
2011-03-06 21:34:26 +00:00
|
|
|
</p>
|
|
|
|
<p>
|
2011-03-15 09:56:05 +00:00
|
|
|
Comme déjà mentionné, I2P, actuellement en version 0.8 inclut la stratégie basée sur les groupes,
|
|
|
|
avec le tri basé sur le XOR. Une discussion plus poussée des mécanismes impliqués dans les opérations de tunnel
|
|
|
|
la gestion et la sélection des pairs est disponible sur la page
|
|
|
|
<a href="tunnel-alt.html">spécification des tunnels</a>.
|
2011-03-06 21:34:26 +00:00
|
|
|
</p>
|
2011-03-15 10:57:29 +00:00
|
|
|
<h2 id="op.netdb">Base de données</h2>
|
2011-03-06 21:34:26 +00:00
|
|
|
<p>
|
2011-03-15 10:57:29 +00:00
|
|
|
Comme indiqué précédemment, la base de données d'I2P sert à partager les métadonnées du réseau.
|
|
|
|
Ceci est détaillé sur la page <a href="how_networkdatabase.html">La base de données du réseau</a>,
|
|
|
|
mais en voici une explication simplifiée:
|
2011-03-06 21:34:26 +00:00
|
|
|
</p>
|
|
|
|
<p>
|
2011-03-15 10:57:29 +00:00
|
|
|
Un certain pourcentage des utilisateurs d'I2P sont crédités du statut de 'floodfill peers', pairs remplisseurs par
|
|
|
|
diffusion, diffuseurs dans la suite.
|
|
|
|
Actuellement, les installations d'2P qui on une bonne bande passante et qui sont assez rapides se
|
|
|
|
déclarent elles-mêmes en tant que diffuseur dès que le nombre de routeurs diffuseurs tombe à un niveau trop faible.
|
2011-03-06 21:34:26 +00:00
|
|
|
</p>
|
|
|
|
<p>
|
2011-03-15 10:57:29 +00:00
|
|
|
Les autres routeurs I2P vont y enregistrer leurs données et recherches en envoyant de simples requêtes
|
|
|
|
'store' et 'lookup' aux diffuseurs.
|
2011-03-15 11:32:58 +00:00
|
|
|
Quand un diffuseur reçoit un requête 'store', il la diffuse aux autres diffuseurs en utilisant
|
|
|
|
l'<a href="http://fr.wikipedia.org/wiki/Kademlia">algorithme Kademlia</a>.
|
2011-03-15 10:57:29 +00:00
|
|
|
Les requêtes 'lookup' fonctionnent actuellement de façon différente, pour éviter
|
|
|
|
<a href="how_networkdatabase.html#lookup">un problème de sécurité important</a>.
|
|
|
|
Lorsqu'une recherche est lancée, le diffuseur ne la diffuse pas, mais y répond lui-même s'il dispose
|
|
|
|
des données demandées.
|
2011-03-06 21:34:26 +00:00
|
|
|
</p>
|
|
|
|
<p>
|
2011-03-15 10:57:29 +00:00
|
|
|
Deux types d'informations sont stockées dans la netDb.
|
2011-03-06 21:34:26 +00:00
|
|
|
<ul>
|
2011-03-15 11:32:58 +00:00
|
|
|
<li><b>routerInfo</b>, un routeur I2P spécifique et la façon de le joindre.</li>
|
|
|
|
<li><b>leaseSet</b>, une destination spécifique (p.e. un site web I2P, un serveur de messagerie, etc...)</li>
|
2011-03-06 21:34:26 +00:00
|
|
|
</ul>
|
2011-03-15 11:32:58 +00:00
|
|
|
Toutes ces infos sont signées par leur propriétaire, et vérifiées par tout routeur I2P qui les utilise
|
|
|
|
ou les stocke.
|
2011-03-15 10:57:29 +00:00
|
|
|
De plus, les données contiennent des informations de temps, pour éviter le stockage de vielles entrées
|
|
|
|
et empêcher d'éventuelles attaques. C'est aussi pourquoi I2P fournit le code nécessaire pour conserver
|
|
|
|
une heure correcte, en interrogeant de temps en temps des serveurs SNTP (dans le
|
|
|
|
tourniquet du réservoir <a href="http://www.pool.ntp.org/fr/">pool.ntp.org</a> par défaut)
|
|
|
|
et en détectant les dérives entre routeurs au niveau de la couche transport.
|
2011-03-06 21:34:26 +00:00
|
|
|
</p>
|
|
|
|
<p>
|
2011-03-15 11:32:58 +00:00
|
|
|
Autres remarques importantes.
|
2011-03-06 21:34:26 +00:00
|
|
|
<ul>
|
|
|
|
<li>
|
2011-03-15 11:32:58 +00:00
|
|
|
<b>Jeux de baux non publiés et cryptés:</b>
|
2011-03-06 21:34:26 +00:00
|
|
|
<p>
|
2011-03-15 11:32:58 +00:00
|
|
|
On pourrait souhaiter que seulement une personne particulière puisse joindre une certaine destination.
|
|
|
|
Ceci est possible par la non publication de la destination dans la base de données.
|
|
|
|
Il faudra alors transmettre la destination par quelqu'autre moyen. Ou alors en utilisant des jeux de baux
|
|
|
|
cryptés, uniquement décryptables par les gens pour lesquels ils ont été cryptés.
|
2011-03-06 21:34:26 +00:00
|
|
|
</p>
|
|
|
|
</li>
|
|
|
|
<li>
|
2011-03-15 11:32:58 +00:00
|
|
|
<b>Amorçage:</b>
|
2011-03-06 21:34:26 +00:00
|
|
|
<p>
|
2011-03-15 11:32:58 +00:00
|
|
|
L'amorçage de la base de données est assez simple. Une fois qu'un routeur réussit à recevoir la routerInfo
|
|
|
|
d'un seul autre pair joignable, il peut interroger ce routeur pour obtenir les informations d'autres routeurs
|
|
|
|
du réseau. Actuellement, bon nombre d'utilisateurs publient leur routerInfo files sur un site web
|
|
|
|
pour rendre cette information disponible. I2P se connecte automatiquement à l'un de ces sites pour
|
|
|
|
collecter des fichiers routerInfo files et d'amorcer.
|
2011-03-06 21:34:26 +00:00
|
|
|
</p>
|
|
|
|
</li>
|
|
|
|
<li>
|
2011-03-15 11:32:58 +00:00
|
|
|
<b>Adaptativité des recherches:</b>
|
2011-03-06 21:34:26 +00:00
|
|
|
<p>
|
2011-03-15 11:32:58 +00:00
|
|
|
Les recherches dans le réseau I2P ne sont pas transmises à d'autres routeurs de la base de données.
|
|
|
|
Actuellement, ce n'est pas un problème majeur, dans la mesure où le réseau n'est pas très grand.
|
|
|
|
Cependant, au fur et à mesure de sa croissance, chaque routeur n'aura pas toutes les routerInfo et tous
|
|
|
|
les jeux de baux de tout le réseau. Ceci provoquera une dégradation du pourcentage de requêtes réussies.
|
|
|
|
Pour ceci, des améliorations de la base de données sont au programme des prochaines versions.
|
2011-03-06 21:34:26 +00:00
|
|
|
</p>
|
|
|
|
</li>
|
|
|
|
</ul>
|
|
|
|
</p>
|
2011-03-15 11:32:58 +00:00
|
|
|
<h2 id="op.transport">Protocoles de transport</h2>
|
2011-03-15 20:54:03 +00:00
|
|
|
<p> Les communications entre routeurs doivent apporter confidentialité et intégrité
|
|
|
|
contre des menaces externes tout en certifiant que le routeur contacté est bien celui
|
|
|
|
qui doit recevoir un message donné. Les particularités sur la façon dont les routeurs communiquent
|
|
|
|
les uns avec les autres ne sont pas critiques: trois protocoles distincts ont été retenus
|
|
|
|
pour répondre à ces exigences. </p>
|
|
|
|
<p> I2P commença avec un protocole basé sur TCP qui depuis a été désactivé.
|
|
|
|
Puis, pour résoudre le problème du besoin élevé en terme de nombre de communications
|
|
|
|
(vu qu'un grand nombre de routeurs peuvent cesser de parler avec plusieurs autres), I2P a migré
|
|
|
|
de TCP vers un protocole <a href="udp.html">basé sur UDP</a> - "Secure
|
|
|
|
Semireliable UDP", UDP Sécurisé Semi-fiable, ou "SSU". </p>
|
|
|
|
<p> Comme expliqué dans la <a href="udp.html">spécification de SSU</a>:</p>
|
|
|
|
<blockquote> Le but de ce protocole est de fournir une livraison sécurisée, authentifiée,
|
|
|
|
semi-fiable, et non ordonnée, dévoilant uniquement une quantité minimale de données facilement
|
2011-03-21 11:22:48 +00:00
|
|
|
discernables par les tierces parties. Il doit tolérer un fort taux de communications
|
2011-03-15 20:54:03 +00:00
|
|
|
tout comme le contrôle de congestion TCP, et inclure la découverte MTU
|
|
|
|
<a href="http://fr.wikipedia.org/wiki/Path_MTU_discovery">PMTU</a>.
|
|
|
|
Il doit pouvoir transférer efficacement des données en vrac à un débit suffisant pour l'utilisation résidentielle.
|
|
|
|
De plus, il doit être compatible avec les techniques de contournement d'obstacles du le réseau
|
|
|
|
tels que les translateurs d'adresses (NAT) ou les pare-feux. </blockquote>
|
|
|
|
<p> Suite à l'introduction de SSU, après l'apparition de problèmes de congestion, un nouveau
|
|
|
|
transport TCP basé sur les <a href="http://en.wikipedia.org/wiki/New_I/O">NIO Java</a> appelé
|
|
|
|
<a href="ntcp.html">NTCP</a> fut implémenté.
|
|
|
|
Il est activé pour les connexions sortantes uniquement. Ceux qui configurent leur pare-feu/NAT
|
|
|
|
pour autoriser les connexions entrantes et précisent l'hôte et le port (même en style DynDNS, etc...)
|
|
|
|
dans la configuration peuvent recevoir des connexions entrantes.
|
2011-03-21 11:22:48 +00:00
|
|
|
Comme NTCP est bâti avec les NIO il n'est pas astreint au problème de "une connexion=une tâche" dont souffrait
|
2011-03-15 20:54:03 +00:00
|
|
|
l'ancien transport TCP. </p>
|
|
|
|
<p> I2P permet de multiples transports simultanément. Un transport particulier pour une connexion sortante
|
2011-03-16 20:58:34 +00:00
|
|
|
est sélectionné par des enchères. Chaque transport fait une offre pour obtenir la connexion, et la valeur relative
|
|
|
|
de l'offre décide de la priorité. Les transports peuvent répondre avec des offres différentes,
|
2011-03-15 20:54:03 +00:00
|
|
|
suivant s'il y a déjà une connexion établie avec le pair. </p>
|
|
|
|
<p> L'implémentation actuelle attribuent la plus haute priorité de transport à NTCP pour les connexions sortantes
|
|
|
|
dans la plupart des cas. SSU est activé à la fois pour les connexions sortantes et entrantes. Votre pare-feu/NAT
|
|
|
|
et votre routeur I2P doivent être configurés pour autoriser les connexions entrantes NTCP.
|
|
|
|
Voir les détails <a href="ntcp.html">ici</a> sur la page NTCP. </p>
|
|
|
|
<h2 id="op.crypto">Cryptographie</h2>
|
|
|
|
<p> Un petit minimum d'algorithmes cryptographiques de base sont combinés pour fournir
|
|
|
|
à I2P les protections étagées contre diverses menaces. Au niveau le plus bas, la communication inter routeurs
|
|
|
|
est protégée par la sécurité de la couche transport: SSU crypte chaque paquet avec
|
|
|
|
l'<a href="http://fr.wikipedia.org/wiki/Advanced_Encryption_Standard">AES</a>256/
|
|
|
|
<a href="http://fr.wikipedia.org/wiki/Mode_d%27op%C3%A9ration_%28cryptographie%29#
|
|
|
|
Encha.C3.AEnement_des_blocs_:_.C2.AB_Cipher_Block_Chaining_.C2.BB_.28CBC.29">CBC</a>
|
|
|
|
conjugué à un vecteur d'initialisation explicite et un code d'authentification de message
|
|
|
|
(<a href="http://fr.wikipedia.org/wiki/Keyed-Hash_Message_Authentication_Code">HMAC</a>-MD5-128) après
|
|
|
|
négociation préalable d'une clé de session via un échange
|
|
|
|
<a href="http://fr.wikipedia.org/wiki/Diffie-Hellman">Diffie-Hellman</a> à 2048 bits et
|
|
|
|
une authentification mutuelle avec la clé <a href="http://fr.wikipedia.org/wiki/Digital_Signature_Algorithm">DSA</a>
|
|
|
|
de l'autre routeur,
|
|
|
|
plus une vérification locale d'intégrité avec le propre hachage du message.
|
|
|
|
|
|
|
|
Les messages de <a href="#op.tunnels">tunnel</a> passés par les transports
|
|
|
|
disposent de leur propre cryptage étagé en AES256/CBC à VI explicite et sont vérifiés
|
|
|
|
au point terminal du tunnel à l'aide d'un hachage <a href="http://fr.wikipedia.org/wiki/SHA-256">SHA256</a>
|
2011-03-21 11:22:48 +00:00
|
|
|
supplémentaire. Divers autres messages sont passés regroupés dans des "garlic messages",
|
2011-03-15 20:54:03 +00:00
|
|
|
qui sont cryptés en
|
|
|
|
<a href="http://fr.wikipedia.org/wiki/Cryptosyst%C3%A8me_de_ElGamal">ElGamal</a>/AES+SessionTags
|
|
|
|
(expliqués ci-dessous).</p>
|
|
|
|
<h3 id="op.garlic">Messages "Garlic" : en têtes d'ail</h3>
|
|
|
|
<p> Ces messages sont une extension du cryptage "onion" en couches, permettant aux contenus d'un seul message
|
|
|
|
de contenir plusieurs "gousses", des messages complets juxtaposés à leurs propres instructions de livraison.
|
|
|
|
Les messages sont empaquetés chaque fois qu'il seraient sinon passés en clair au travers d'un pair qui n'aurait pas
|
|
|
|
accès aux informations de routage: par exemple, quand un routeur veut demander à un autre de participer à un
|
|
|
|
tunnel, ils ajoutent la requête dans un garlic qu'il cryptent à l'intention du routeur destinataire avec sa
|
|
|
|
clé publique ElGamal 2048 bits publiée dans son jeu de baux, et le font suivre dans un tunnel. Dans un autre
|
|
|
|
exemple, un client veut envoyer un message à une destination: le routeur du client va joindre ce message de
|
2011-03-21 11:22:48 +00:00
|
|
|
données (à côté de quelques autres messages) dans un garlic qu'il crypte en ElGamal 2048 à l'intention de la
|
2011-03-15 20:54:03 +00:00
|
|
|
destination avec sa clé publiée dans son jeu de baux, et l'envoie aux tunnels appropriés.</p>
|
2011-03-21 11:22:48 +00:00
|
|
|
<p> Les "instructions" attachées à chaque gousse dans la couche de cryptage incluent la possibilité
|
2011-03-15 20:54:03 +00:00
|
|
|
de demander que cette gousse soit transmise localement, à un routeur distant, ou à un tunnel distant sur un routeur
|
|
|
|
distant. Il y a des champs dans ces instructions permettant à un pair de demander que la livraison soit retardée
|
2011-03-21 11:22:48 +00:00
|
|
|
un certain temps ou jusqu'à ce qu'une condition soit remplie, bien qu'ils ne seront pas pris en compte avant que
|
|
|
|
les <a href="#future.variablelatency">retards variables</a> soient déployés. Il est possible
|
2011-03-15 20:54:03 +00:00
|
|
|
de router explicitement les messages en tête d'ail sur n'importe quel nombre de sauts sans construire de tunnels,
|
2011-03-21 11:22:48 +00:00
|
|
|
ou même de rerouter les messages de tunnels en les joignant à un garlic et en le faisant suivre à un certain
|
2011-03-15 20:54:03 +00:00
|
|
|
nombre de saut avant de le passer au saut suivant du tunnel, mais ces techniques ne sont pas actuellement utilisées
|
|
|
|
dans l'implémentation en cours. </p>
|
|
|
|
<h3 id="op.sessiontags">Balises de session</h3>
|
2011-03-21 11:22:48 +00:00
|
|
|
<p> En tant que système orienté messages non fiable et non ordonné, I2P utilise une simple combinaison
|
|
|
|
d'algorithmes de cryptage symétriques et asymétriques pour apporter la confidentialité et l'intégrité
|
2011-03-16 10:37:40 +00:00
|
|
|
des données aux messages garlics. Considérée comme un tout, la combinaison est appelée ElGamal/AES+SessionTags,
|
|
|
|
mais c'est un poil trop verbeux pour décrire une simple utilisation d'ElGamal 2048 bits, d'AES256, d'SHA256,
|
|
|
|
et de vecteurs d'initialisation de 32 octets. </p>
|
|
|
|
<p> La première fois qu'un routeur veut crypter un message garlic à l'usage d'un autre routeur,
|
|
|
|
il crypte les données de clés d'une session AES256 avec ElGamal et joint la charge utile cryptée en AES256/CBC
|
2011-03-21 11:22:48 +00:00
|
|
|
après le bloc crypté avec ElGamal. En plus de la charge utile cryptée, la section encryptée en AES contient
|
2011-03-16 10:37:40 +00:00
|
|
|
la longueur de la charge utile, le hachage de la charge non cryptée, ainsi qu'un certain nombre de balises de
|
|
|
|
session de 32 octets aléatoires. La fois suivante, plutôt que de crypter une nouvelle clé de session en ElGamal,
|
2011-03-21 11:22:48 +00:00
|
|
|
il va simplement prendre une des balises précédemment envoyées et crypter la charge en AES comme avant en utilisant
|
2011-03-16 10:37:40 +00:00
|
|
|
la clé de session associée à la balise, et préfixer la charge cryptée avec la balise. Quand un routeur reçoit
|
|
|
|
un message garlic, il cherche si les 32 premiers octets correspondent à une balise déjà disponible, auquel cas il
|
2011-03-21 11:22:48 +00:00
|
|
|
décryptent l'AES. En l'absence de correspondance, il décryptent le premier bloc en ElGamal.</p>
|
2011-03-16 10:37:40 +00:00
|
|
|
<p> Chaque balise de session est à usage unique, tant pour empêcher une attaque interne de mettre en corrélation
|
|
|
|
différents messages, que venant d'un point situé entre les mêmes routeurs. L'émetteur d'un message crypté
|
2011-03-21 11:22:48 +00:00
|
|
|
ElGamal/AES+SessionTag choisit quand et combien de balises il faut envoyer pour en fournir suffisamment au
|
|
|
|
destinataire afin de couvrir les besoins nécessaires au transfert d'un bouquet de messages.
|
2011-03-16 10:37:40 +00:00
|
|
|
Les messages garlics peuvent détecter la livraison correcte de balises en joignant un petit message supplémentaire
|
|
|
|
en tant que gousse (un accusé de réception): quand la tête d'ail arrive au destinataire prévu et est décryptée
|
|
|
|
avec succès, ce petit message de réussite pré fourni est un de ceux dévoilés dans la gousse, et il contient
|
|
|
|
les instructions pour le destinataire pour la renvoyer à l'émetteur (via un tunnel entrant, évidement).
|
|
|
|
Quand celui-ci reçoit ce message d'état de livraison, il sait que les balises de session ont bien été reçues.</p>
|
|
|
|
<p>Les balises ont une très courte durée de vie, passée laquelle elles sont invalidées faute d'avoir été utilisées.
|
|
|
|
De plus, leur nombre pour chaque clé est limité, tout comme le nombre de clés lui-même:
|
|
|
|
s'il en arrive trop, des messages récents ou plus anciens pourraient être perdus. L'émetteur fait un suivi
|
|
|
|
des messages qui utilisent les balises pour s'assurer qu'ils passent, et dans le cas contraire il se replie sur
|
|
|
|
l'algorithme ElGamal plus coûteux.</p>
|
|
|
|
<p> Une alternative consiste à ne transmettre qu'une seule balise de session, et de là,
|
|
|
|
initialiser un
|
|
|
|
<a href="http://fr.wikipedia.org/wiki/G%C3%A9n%C3%A9rateur_de_nombres_pseudo-al%C3%A9atoires">
|
|
|
|
générateur de nombres pseudo-aléatoires</a> (PRNG) déterministe pour déduire quelles balises utiliser ou attendre.
|
|
|
|
En tenant ce générateur sommairement synchronisé entre l'émetteur et le destinataire (qui calcule par anticipation
|
|
|
|
par exemple une cinquantaine de balises), la surcharge induite par la fourniture périodique d'un grand nombre de
|
|
|
|
balises est supprimée, permettant ainsi plus d'options d'arbitrage dans l'espace et le temps, et éventuellement
|
|
|
|
la réduction du nombre d'encryptages ElGamal nécessaires. Cependant, il dépend de la robustesse du générateur de
|
|
|
|
fournir la protection contre les menaces internes, bien qu'on puisse minimiser toute faiblesse en limitant le
|
|
|
|
nombre d'utilisations de chaque générateur. Pour l'instant, il n'a pas de plans immédiats de migration vers ce
|
|
|
|
système de PRNGs synchronisés. </p>
|
|
|
|
<h1 id="future">L'avenir</h1>
|
|
|
|
<p> Bien qu'I2P soit actuellement opérationnel et suffisant dans de nombreux scenarii, il reste plusieurs zones qui
|
|
|
|
demandent de profondes améliorations pour atteindre les besoins de ceux devant faire face à des adversaires
|
|
|
|
puissants comme pour l'amélioration de l'utilisation quotidienne par les utilisateurs.
|
2011-03-06 21:34:26 +00:00
|
|
|
</p>
|
2011-03-16 10:37:40 +00:00
|
|
|
<h2 id="future.restricted">Les routes réservées</h2>
|
2011-03-17 21:58:46 +00:00
|
|
|
<p> I2P est une "sur-couche" réseau conçue pour fonctionner sur un réseau commuté par paquets,
|
2011-03-16 10:37:40 +00:00
|
|
|
exploitant la notion de "point à point" pour offrir l'anonymat et la sécurité.
|
|
|
|
Alors qu'Internet ne respecte plus le principe du bout en bout (à cause de l'utilisation du NAT),
|
2011-03-21 11:22:48 +00:00
|
|
|
I2P requiert qu'une portion substantielle du réseau soit joignable: il pourrait y avoir un bon nombre
|
2011-03-16 10:37:40 +00:00
|
|
|
de pairs utilisant des routes privées, mais I2P n'inclut pas d'algorithme de routage approprié à un scenario
|
|
|
|
de dégradation dans lequel la plus grande partie des pairs seraient injoignables. Il pourrait cependant fonctionner
|
|
|
|
sur un réseau utilisant un tel algorithme. </p>
|
|
|
|
<p> L'utilisation de routes réservées, où il y a des limites aux pairs joignables directement,
|
|
|
|
induit plusieurs conséquences sur le fonctionnement et l'anonymat, suivant la façon selon laquelle ces routes
|
|
|
|
sont gérées. Au niveau le plus basique, des routes réservées sont présentes quand un pair se trouve derrière
|
|
|
|
un pare-feu ou un NAT qui ne permet pas les connexions entrantes. Ceci a été grandement pris en compte depuis la
|
|
|
|
0.6.0.6 en intégrant le percement de trous distribué dans la couche transport, permettant ainsi aux gens situés
|
2011-03-21 11:22:48 +00:00
|
|
|
derrière la plupart de pare-feux ou NATs de recevoir des connexions non sollicitées sans aucune configuration.
|
2011-03-16 20:58:34 +00:00
|
|
|
Cependant, ceci ne réduit pas l'exposition de l'adresse IP du pair aux routeurs du réseau,
|
|
|
|
car ils peuvent être présentés au pair au travers de l'intermédiaire publié.</p>
|
|
|
|
<p> Au-delà de la gestion fonctionnelle des routes privées, il y a deux niveaux d'opérations privées qui peuvent être
|
|
|
|
mis en œuvre pour limiter l'exposition des adresses IP: l'utilisation de tunnels dédiés à la communication et de
|
2011-03-21 11:22:48 +00:00
|
|
|
'routeurs clients'. Pour le premier, les routeurs peuvent soit construire un nouveau groupe de tunnels ou
|
2011-03-16 20:58:34 +00:00
|
|
|
réutiliser leur groupe exploratoire, en publiant les passerelles entrantes vers quelques-uns d'entre eux en tant
|
|
|
|
que partie de leur routerInfo au lieu de leur adresse de transport. Quand un pair veut les contacter, il voit
|
|
|
|
ces passerelles de tunnel dans la base de données et leur envoient simplement le message concerné via un des tunnels
|
|
|
|
publiés. Si le pair situé derrière une route privée veut répondre, il peut le faire soit directement (s'il acceptent
|
|
|
|
de dévoiler leur adresse IP au pair) ou indirectement via leurs tunnels sortants. Quand les routeurs
|
|
|
|
auxquels le pair a une connexion directe veulent le joindre (p.e. pour faire suivre des messages de tunnels), ils
|
|
|
|
doivent simplement prioriser leur connexion directe par rapport à la passerelle de tunnels publiée.
|
|
|
|
Le concept de 'routeur client' étends simplement la route réservée en ne publiant aucune adresse de routeur.
|
|
|
|
Un tel routeur n'aurait même plus besoin de publier leur routerInfo dans la netDb, mais plutôt de fournir leur
|
|
|
|
leur routerInfo auto-signée aux pairs qu'il contacterait (nécessaire au transfert de ses clés publiques).
|
|
|
|
Ces deux niveaux d'opération sur routes privées sont prévus pour la version 2.0 d'I2P. </p>
|
|
|
|
<p> Il y a des choix à établir pour ceux situés sur des routes privées, vu qu'ils participeraient moins souvent aux
|
|
|
|
tunnels des autres utilisateurs, et que les routeurs auxquels ils sont connectés pourraient déduire des motifs
|
|
|
|
de trafic qui ne sont normalement pas exposés. D'un autre côté, si le coût de cette exposition est inférieur à
|
|
|
|
celui de rendre l'adresse IP disponible, cela peut être intéressant. Ceci, bien sûr, suppose que les pairs contactés
|
|
|
|
par celui qui est derrière une route réservée ne soient pas hostiles, ou que le réseau soit assez grand pour que la
|
2011-03-21 11:22:48 +00:00
|
|
|
probabilité de tomber sur un pairs hostile pour se connecter soit suffisamment faible. On pourrait aussi préférer
|
2011-03-16 20:58:34 +00:00
|
|
|
utiliser des pairs de confiance (et peut-être temporaires).</p>
|
|
|
|
<h2 id="future.variablelatency">Latence variable</h2>
|
|
|
|
<p> Même si le gros des efforts initiaux d'I2P ont porté sur une communication à faible latence,
|
|
|
|
il fut dès le départ conçu en gardant à l'esprit des services à latence variable.
|
|
|
|
Au niveau le plus bas, les applications s'exécutant sur I2P peuvent offrir l'anonymat du médium des communications
|
2011-03-21 11:22:48 +00:00
|
|
|
à haute latence tout en mêlant leurs motifs de trafic à du trafic à faible latence. En interne cependant,
|
|
|
|
I2P peut offrir son propre médium et une haute latence de communication via le cryptage garlic en tête d'ail:
|
2011-03-16 20:58:34 +00:00
|
|
|
en spécifiant que le message doit être envoyé après un certain délai, à un certain moment, après le passage d'un
|
|
|
|
certain nombre de messages, ou une autre stratégie combinant ces éléments. Avec le cryptage en couches,
|
|
|
|
seul le routeur pour lequel la gousse a dévoilé la requête de retard saura que le message demande une haute
|
2011-03-21 11:22:48 +00:00
|
|
|
latence, au trafic correspondant d'être mélangé ultérieurement à du trafic à faible latence. Une fois la condition
|
2011-03-16 20:58:34 +00:00
|
|
|
de transmission atteinte, le routeur retenant la gousse (qui peut aussi bien être un message garlic) le fait
|
|
|
|
simplement suivre comme demandé: à un routeur, à un tunnel, ou plus probablement à une destination cliente.</p>
|
|
|
|
<p> Il y a un nombre conséquent de manières d'exploiter cette possibilité pour les communications à haute latence
|
|
|
|
dans I2P, mais pour l'instant, son utilisation est planifiée pour la version 3.0. En attendant, ceux qui ont besoin
|
|
|
|
de l'anonymat offert par les communications à latence élevée peuvent se tourner vers la couche applicative pour
|
|
|
|
l'obtenir.</p>
|
|
|
|
<h2 id="future.open">Questions ouvertes</h2>
|
2011-03-06 21:34:26 +00:00
|
|
|
<pre>
|
2011-03-21 11:22:48 +00:00
|
|
|
Comment se débarrasser de la contrainte de temps?
|
|
|
|
Y a-t-il un moyen plus efficace de gérer les balises de session?
|
2011-03-16 20:58:34 +00:00
|
|
|
Quelles stratégies de regroupement/mélange devraient-elles être disponibles dans les tunnels?
|
|
|
|
Quelles autre stratégies de sélection/tri des pairs de tunnels devrait-elles être disponibles?
|
2011-03-06 21:34:26 +00:00
|
|
|
</pre>
|
2011-03-16 20:58:34 +00:00
|
|
|
<h1 id="similar">Systèmes similaires</h1>
|
|
|
|
<p> L'architecture d'I2P repose sur les concepts de logiciel intermédiaire orienté messages, de topologie de table
|
|
|
|
de hachage décentralisée, de l'anonymat et de la cryptographie des réseaux croisés à routes libres et de
|
|
|
|
l'adaptabilité des réseaux à paquets commutés. L'apport ne vient cependant pas de nouveaux concepts d'algorithmes,
|
|
|
|
mais de l'analyse attentive des résultats de recherches et documentations des systèmes existants.
|
|
|
|
Bien qu'il y ait peu d'efforts similaires qui vaillent d'être analysés en détail, tant au niveau technique que
|
|
|
|
fonctionnel, il en est néanmoins deux qui sortent du lot: Tor et Freenet.</p>
|
|
|
|
<p> Voir aussi la page de <a href="how_networkcomparisons.html">comparaisons des réseaux</a>.
|
2011-03-06 21:34:26 +00:00
|
|
|
</p>
|
|
|
|
|
|
|
|
<h2 id="similar.tor">Tor</h2>
|
2011-03-20 14:48:19 +00:00
|
|
|
<p><i><a href="http://www.torproject.org/">Site officiel</a></i></p>
|
2011-03-16 20:58:34 +00:00
|
|
|
<p>Au premier coup d'œil, Tor et I2P ont plusieurs ressemblances fonctionnelles et d'anonymat.
|
|
|
|
Bien que le développement d'I2P ait commencé avant que nous ne fussions au courant des premières étapes du travail
|
|
|
|
sur Tor, plusieurs des leçons du travail d'origine du routage en oignon et de ZKS furent intégrées
|
|
|
|
dans sa conception. Plutôt que de construire un système centralisé de confiance, avec des serveurs d'annuaires, I2P
|
2011-03-21 11:22:48 +00:00
|
|
|
dispose d'une base de données réseau auto-organisée dans laquelle chaque pair assume la responsabilité du profilage
|
2011-03-16 20:58:34 +00:00
|
|
|
des autres routeurs pour déterminer la meilleure façon d'exploiter les ressources disponibles. Une autre différence
|
|
|
|
majeure réside dans le fait que bien qu'utilisant tous les deux des chemins étagés et ordonnés, I2P est
|
|
|
|
fondamentalement un réseau à commutation de paquets alors que Tor est un réseau à commutation de circuits, ce qui
|
|
|
|
permet à I2P de contourner de façon transparente les congestions et autres défaillances du réseau, de gérer des
|
|
|
|
chemins redondants, et de faire de l'équilibrage de charge sur les ressources disponibles.
|
|
|
|
Si Tor offre nativement la fonctionnalité très utile de découverte et de sélection de mandataire de sortie
|
2011-03-19 08:28:04 +00:00
|
|
|
(outproxy), I2P délègue cette décision de couche applicative... aux applications: dans les faits, I2P a même
|
|
|
|
externalisé vers la couche applicative la bibliothèque de flux (streaming) "style TCP" permettant ainsi aux
|
|
|
|
développeurs d'expérimenter diverses stratégies afin d'en tirer les meilleures performances.</p>
|
2011-03-17 21:58:46 +00:00
|
|
|
<p> Du point de vue de l'anonymat, la comparaison du cœur des réseaux présente beaucoup de similarités.
|
2011-03-18 19:09:33 +00:00
|
|
|
Il y a malgré tout quelques différences fondamentales. Pour la prise en compte des menaces internes et de la
|
2011-03-17 21:58:46 +00:00
|
|
|
plupart des menaces externes, les tunnels simplex d'I2P n'exposent au plus que la moitié des données de trafic
|
|
|
|
que ne le font les circuits duplex de Tor, rien qu'au niveau de l'observation des flux: une requête HTTP et sa
|
|
|
|
réponse suivent le même chemin dans Tor, alors que dans I2P, les paquets constituant la requête passent par un ou
|
2011-03-21 11:22:48 +00:00
|
|
|
plusieurs tunnels sortants, et ceux de la réponse empruntent un ou plusieurs tunnels entrants.
|
2011-03-19 07:53:55 +00:00
|
|
|
Les stratégies de sélection et de tri des pairs dans I2P entrave suffisamment les attaques par prédécesseur,
|
|
|
|
mais il peut aussi mimer les tunnels duplex de Tor en créant les tunnels entrants et sortants en suivant les
|
|
|
|
mêmes routeurs.</p>
|
2011-03-19 08:28:04 +00:00
|
|
|
<p> Une autre faille d'anonymat dans Tor vient de la création télescopique de tunnels: le comptage et les mesures de
|
2011-03-20 11:33:46 +00:00
|
|
|
timing des paquets dans un circuit passant à travers le nœud ennemi lui permettent l'extraction de données
|
2011-03-21 11:22:48 +00:00
|
|
|
statistiques pouvant lui révéler sa position dans le circuit. Dans I2P, la création de tunnels unidirectionnels
|
2011-03-19 07:53:55 +00:00
|
|
|
en un seul message masque cette information. La confidentialité de la position occupée dans un tunnel est
|
|
|
|
importante car un attaquant pourrait profiter de cette donnée pour lancer une série d'attaques de prédécesseur,
|
|
|
|
d'intersection, et de confirmation de trafic.
|
2011-03-06 21:34:26 +00:00
|
|
|
</p>
|
2011-03-19 07:53:55 +00:00
|
|
|
<p> Le deuxième niveau de mandataires "oignons" de Tor apporte un bon anonymat à faible coût d'entrée, alors q'I2P
|
|
|
|
ne permettra pas cette topologie avant la version <a href="#future.restricted">2.0</a>. </p>
|
|
|
|
<p> Globalement, Tor et I2P se complètent mutuellement: Tor se focalise sur la mise à disposition de mandataires
|
|
|
|
sortants rapides et anonymes, et I2P s'oriente vers un réseau robuste et décentralisé. En théorie, chacune de ces
|
|
|
|
deux approches sont destinées à des fins différentes, mais étant donné les faibles ressources en développement,
|
2011-03-21 11:22:48 +00:00
|
|
|
elles ont chacune leurs propres forces et faiblesses. Les développeurs d'I2P ont étudié les étapes nécessaires
|
2011-03-19 08:28:04 +00:00
|
|
|
à la modification de Tor pour qu'il puisse bénéficier de la conception d'I2P, mais les inquiétudes quand à la
|
2011-03-20 09:59:34 +00:00
|
|
|
viabilité de Tor en régime de ressources raréfiées suggèrent que l'architecture à commutation de paquets choisie
|
|
|
|
par I2P est à même d'exploiter plus efficacement des ressources rares. </p>
|
2011-03-06 21:34:26 +00:00
|
|
|
|
|
|
|
<h2 id="similar.freenet">Freenet</h2>
|
2011-03-19 07:53:55 +00:00
|
|
|
<p><i><a href="http://www.freenetproject.org/">Le site</a></i></p>
|
2011-03-19 08:28:04 +00:00
|
|
|
<p> Freenet a largement contribué aux premières étapes de conception d'I2P, en donnant la preuve de la viabilité
|
|
|
|
d'une communauté enthousiaste entièrement contenue dans un réseau et en démontrant que les dangers inhérents aux
|
2011-03-19 08:13:04 +00:00
|
|
|
mandataires sortants pouvaient être évités. La première graine d'I2P germa en tant que couche de communication
|
2011-03-20 09:59:34 +00:00
|
|
|
pour Freenet visant à séparer les complexités d'une communication point à point sécurisée, anonyme et adaptable,
|
|
|
|
de celles d'un réservoir de données décentralisé et résistant à la censure.
|
|
|
|
Le temps passant, les problèmes d'anonymat et d'adaptabilité intrinsèques des algorithmes retenus pour la
|
|
|
|
conception de Freenet confirmèrent que la visée d'I2P devait strictement s'en tenir à fournir une couche
|
|
|
|
de communication banalisée plutôt que de rester un composant de Freenet. Après quelques années, les développeurs de
|
|
|
|
Freenet furent amenés à reconnaître les faiblesses de cette conception déjà fort ancienne qui les conduisait à
|
|
|
|
y répondre en proposant une couche de "pré-mélange" pour obtenir un anonymat plus solide. En d'autres termes,
|
|
|
|
Freenet a besoin de fonctionner sur un réseau croisé tel que Tor ou I2P, les nœuds clients demandant et publiant
|
2011-03-21 11:22:48 +00:00
|
|
|
les données via le réseau croisé sous-jacent sur les nœuds serveurs qui ensuite les ramènent et les stockent
|
2011-03-20 09:59:34 +00:00
|
|
|
conformément à ses propres algorithmes heuristiques de stockage distribué. </p>
|
|
|
|
<p> La fonctionnalité de Freenet est très complémentaire à celle d'I2P, car il apporte nativement plusieurs des
|
|
|
|
outils nécessaires aux systèmes à haute et moyenne latence, quand de son côté I2P apporte le réseau croisé à
|
|
|
|
faible latence adapté au niveau d'anonymat attendu. La logique de séparation du réseau croisé et du stockage
|
2011-03-20 11:33:46 +00:00
|
|
|
distribué résistant à la censure paraissant toujours pertinente d'un point de vue de l'allocation des ressources,
|
2011-03-23 23:43:03 +00:00
|
|
|
de la sécurité, de l'anonymat et de l'ingénierie, on peut espérer que l'équipe de Freenet persévère dans cette
|
|
|
|
voie, si ce n'est simplement en réutilisant (ou en améliorant, au besoin) des réseaux croisés existants tels qu'I2P
|
|
|
|
ou Tor.</p>
|
2011-03-20 09:59:34 +00:00
|
|
|
<p> Il est intéressant de signaler ici les débats et travaux des développeurs de Freenet concernant un "réseau masqué
|
2011-03-20 11:33:46 +00:00
|
|
|
globalement adaptable" qui utiliserait des routes privées entre pairs ayant des relations de confiance
|
|
|
|
disparates. Comme l'insuffisance des informations rendues publiques sur la façon de parvenir à faire fonctionner
|
|
|
|
un tel système empêche d'en faire une analyse exhaustive, les prétentions annoncées en terme d'anonymat et
|
|
|
|
d'adaptabilité doivent être prises avec beaucoup de réserve. En particulier la pertinence de son utilisation en
|
2011-03-21 11:22:48 +00:00
|
|
|
milieu hostile peuplé d'adversaires sur-vitaminés a été énormément surestimée, et toute analyse des conséquences de
|
2011-03-20 11:33:46 +00:00
|
|
|
la rareté des ressources sur l'adaptabilité du réseau a visiblement été oubliée. Restent aussi des questions sur la
|
|
|
|
vulnérabilité à l'analyse de trafic, la confiance et d'autres sujets, mais l'analyse en profondeur de ce "réseau
|
|
|
|
croisé globalement adaptable" devra attendre que l'équipe de Freenet en publie la documentation.</p>
|
2011-03-06 21:34:26 +00:00
|
|
|
|
2011-03-20 11:33:46 +00:00
|
|
|
<h1 id="app">Appendice A: La couche applicative</h1>
|
2011-03-06 21:34:26 +00:00
|
|
|
|
|
|
|
<p>
|
2011-03-20 11:33:46 +00:00
|
|
|
I2P en lui-même ne fait pas grand chose: il envoie simplement des messages à des destinations distantes et reçoit
|
|
|
|
des messages pour le compte de destinations locales. Le travail le plus intéressant se passe dans les étages
|
|
|
|
supérieur. En soi, I2P peut être considéré en tant que couche IP anonyme et sécurisée, et la
|
|
|
|
<a href="#app.streaming">bibliothèque de flux</a> fournie, comme un étage supérieur TCP anonyme et sécurisé.
|
|
|
|
Ensuite, <a href="#app.i2ptunnel">I2PTunnel</a> propose un système de délégation générique pour entrer et sortir du
|
|
|
|
réseau I2P, ainsi qu'une fournée d'applications réseau destinées à donner plus de fonctionnalités aux
|
|
|
|
utilisateurs.
|
2011-03-06 21:34:26 +00:00
|
|
|
</p>
|
|
|
|
|
2011-03-20 11:35:06 +00:00
|
|
|
<h2 id="app.streaming">Bibliothèque de flux (streaming)</h2>
|
2011-03-20 14:48:19 +00:00
|
|
|
<p>
|
|
|
|
La bibliothèque de flux d'I2P peut être considérée comme une interface pour les flux (des connecteurs TCP
|
|
|
|
en mirroir), et la mise en œuvre prend en charge un
|
|
|
|
<a href="http://en.wikipedia.org/wiki/Sliding_Window_Protocol">protocole à fenêtre glissante</a> doté de plusieurs
|
|
|
|
optimisations pour tenir compte du haut délai sur I2P. Les flux individuels peuvent ajuster la taille maximum des
|
|
|
|
des paquets ainsi que d'autres options, bien que les 4 ko compressés par défaut semblent un choix raisonnable
|
|
|
|
pour le coût en bande passante de la retransmission des messages perdus et la latence de messages multiples.
|
2011-03-06 21:34:26 +00:00
|
|
|
</p>
|
|
|
|
<p>
|
2011-03-20 14:48:19 +00:00
|
|
|
De plus, au regard du coût assez élevé des messages subséquents, le protocole de planification et de livraison de
|
|
|
|
la bibliothèque a été optimisé pour faire en sorte que les messages individuels transférés contiennent le plus
|
|
|
|
possible de l'information disponible. Par exemple, une petite transaction HTTP mandatée par la bibliothèque
|
|
|
|
peut être pliée en un unique aller-retour: le premier message embarque le SYN, le FIN et la petite charge utile (
|
|
|
|
une requête HTTP y contient en général), et la réponse contient le SYN, le FIN et le ACK, et aussi la petite charge
|
|
|
|
(plusieurs réponses HTTP tiennent dans la boîte de sardines). Lorsque un ACK supplémentaire doit être transmis pour
|
|
|
|
indiquer au serveur que le SYN/FIN/ACK a été reçu, le proxy HTTP local peut immédiatement livrer la réponse
|
|
|
|
complète au navigateur.</p>
|
2011-03-06 21:34:26 +00:00
|
|
|
<p>
|
2011-03-20 14:48:19 +00:00
|
|
|
Globalement, cependant, la bibliothèque de flux revêt beaucoup de ressemblance avec le modèle de TCP avec ses
|
|
|
|
fenêtres glissantes, ses algorithmes de contrôle de congestion (démarrage lent et évitement), et le comportement
|
|
|
|
général des paquets (ACK, SYN, FIN, RST, etc...)</p>
|
2011-03-06 21:34:26 +00:00
|
|
|
|
2011-03-21 11:22:48 +00:00
|
|
|
<h2 id="app.naming">Bibliothèque de nommage et carnet d'adresses</h2>
|
2011-04-24 12:29:30 +00:00
|
|
|
<p><i> <a href="naming_fr.html">Détails avancés</a></i></p>
|
2011-03-21 11:22:48 +00:00
|
|
|
<p><i>Développés par mihi et Ragnarok</i></p>
|
|
|
|
<p> Le nommage dans I2P a dès les tout débuts fait l'objet de nombreux débats entre les tenants de chaque
|
|
|
|
possibilités. Cependant, étant donné les demandes de communication sécurisée et de fonctionnement décentralisé aux
|
|
|
|
principe d'I2P, les traditionnels systèmes du type DNS comme ceux fondés sur des votes à la majorité furent
|
|
|
|
mis hors-jeu. En lieu et place, I2P s'appuie sur une bibliothèque de fonctions de nommage et une implémentation
|
|
|
|
de base conçue pour un fonctionner indifféremment grâce à une correspondance entre un nom local et une destination
|
|
|
|
ou à une application compagnon appelée "carnet d'adresses" (addressbook). Le carnet d'adresses est un système de
|
|
|
|
nommage sécurisé accessible au lecteur humain, décentralisé et piloté par un réseau de confiance, sacrifiant
|
|
|
|
uniquement la nécessité des noms humainement lisibles d'être globalement uniques, en n'exigeant seulement que
|
|
|
|
l'unicité locale. Comme tous les messages dans I2P sont référencés cryptographiquement par leur destination,
|
|
|
|
des personnes différentes peuvent avoir dans leur propre carnet d'adresses une entrée pour "Alice" se rapportant
|
|
|
|
à une destination différente. Les utilisateurs peuvent toujours trouver de nouveaux noms en important les carnets
|
|
|
|
d'adresses publics des pairs spécifiés dans leur réseau de confiance, en ajoutant les entrées procurées par un
|
|
|
|
tiers ou (si quelques uns organisent une série de carnets publiés en se servant d'une méthode d'enregistrement
|
|
|
|
premier entré premier servi) ils peuvent décider de considérer ces carnets d'adresses comme des serveurs de noms
|
|
|
|
fonctionnant à la façon du DNS habituel.</p>
|
|
|
|
<p> Cependant, I2P ne préconise pas l'utilisation de services semblables à DNS, car les dégâts causé par un
|
|
|
|
détournement de site peuvent être énormes - et les destinations non sécurisées n'ont aucune valeur.
|
|
|
|
DNSsec lui-même repose sur les registrars et les autorités de certification, alors qu'avec I2P, les requêtes
|
|
|
|
envoyées ne peuvent être interceptées ni leurs réponses usurpées car cryptées pour la destination qui n'est elle-
|
|
|
|
même qu'une paire de clés publiques et un certificat. Les systèmes de style DNS permettent à tout serveur de noms
|
|
|
|
situé dans le chemin de la requête de lancer des attaques de dénis de service et d'usurpations. L'adjonction aux
|
|
|
|
réponses d'un certificat les authentifiant signé par quelque autorité de certification centrale résoudrait
|
|
|
|
le problème de serveur de nom hostile sans apporter de solutions à ceux des attaques de replay ni à l'hypothèse de
|
|
|
|
l'autorité de certification hostile.</p>
|
|
|
|
<p> Le nommage par votes est dangereux lui aussi, étant donné l'efficacité des attaques de Sibylle dans les systèmes
|
|
|
|
anonymes: un attaquant peu créer des pairs en nombre suffisant pour s'assurer l'attribution d'un nom donné.
|
|
|
|
On pourrait utiliser des méthodes "Proof-of-work" pour donner un prix à l'identité, mais à mesure de la croissance
|
|
|
|
du réseau, le besoin de contacter tout le monde pour organiser un vote en ligne rendrait la charge du réseau
|
|
|
|
inenvisageable. Et renoncer à interroger tout le réseau conduirait à avoir différents jeux de réponses.</p>
|
|
|
|
<p> Comme avec Internet cependant, I2P maintient la structure et le fonctionnement d'un système de nommage en dehors
|
|
|
|
de la couche de communication (elle-même reprise du modèle IP, comme décrit plus haut). La bibliothèque fournie
|
|
|
|
inclut une interface de fournisseur de service permettant d'utiliser d'autres systèmes de nommage en fonction
|
|
|
|
des préférences des utilisateurs.</p>
|
2011-03-06 21:34:26 +00:00
|
|
|
|
|
|
|
<h2 id="app.syndie">Syndie</h2>
|
2011-03-21 11:22:48 +00:00
|
|
|
<p><i> Le vieux Syndie fourni avec I2P a été remplacé par un nouveau qui est distribué séparément.
|
|
|
|
Voir la page <a href="http://syndie.i2p2.de/">Syndie</a>.</i></p>
|
|
|
|
<p> Syndie est un système d'agrégation/publication/blogage anonyme et sécurisé. Vous pouvez créer de l'information,
|
|
|
|
la partager, et lire celle venant de qui vous intéresse, tout ça en prenant en compte vos besoins en sécurité et en
|
|
|
|
anonymat. Plutôt que d'utiliser un réseau de distribution de contenu spécifique, Syndie est conçu pour fonctionner
|
|
|
|
sur des réseaux existant, en réalisant la publication via les sites eep, les services Tor masqués, les freesites
|
|
|
|
Freenet, les sites Internet normaux, les newsgroups de Usenet, les listes de messagerie, les sources RSS, etc...
|
|
|
|
Les données sont publiées pour permettre le respect de la consultation et de l'archivage via une authentification
|
|
|
|
par pseudonyme.</p>
|
2011-03-06 21:34:26 +00:00
|
|
|
|
|
|
|
<h2 id="app.i2ptunnel">I2PTunnel</h2>
|
2011-03-21 11:22:48 +00:00
|
|
|
<p><i>Développé par mihi</i></p>
|
|
|
|
<p> I2PTunnel est assurément l'application I2P la plus appréciée et la plus polyvalente, de part sa capacité à
|
|
|
|
fournir un mandatement générique pour l'entrée et la sortie du réseau I2P. On peut se représenter I2PTunnel comme
|
|
|
|
quatre applications mandataires indépendantes: un "client" qui reçoit les connexions TCP et les transfère à une
|
|
|
|
destination I2P particulière, un "client http" (eepproxy) faisant office de mandataire HTTP qui transfère les
|
|
|
|
requêtes à la destination appropriée (après une éventuelle recherche dans le service de nommage), un "serveur" qui
|
|
|
|
reçoit les connexions de flux entrantes à une destination et les transfère au port/hôte TCP voulu et un "serveur
|
|
|
|
HTTP" qui étend le "serveur" en décortiquant les requêtes et les réponses pour permettre un fonctionnement plus
|
|
|
|
sûr. Il y a aussi une application "client socks", mais son utilisation est déconseillée pour les raisons
|
|
|
|
précédemment signalées.</p>
|
|
|
|
<p> I2P <b>n'est pas</b> un réseau mandataire de sortie: les préoccupations de sécurité et d'anonymat au cœur d'un
|
|
|
|
réseau croisé qui échange des données avec le monde extérieur ont centré la conception d'I2P pour qu'elle ne dérive
|
|
|
|
pas de ces préoccupations, et donc ne nécessite pas l'accès à des ressources externes. Cependant, le "client HTTP"
|
|
|
|
offre une possibilité de connexion pour du mandatage sortant: si le nom d'hôte demandé ne finit pas en ".i2p", elle
|
|
|
|
sélectionne aléatoirement une destination dans un groupe de mandataires sortants fournis par l'utilisateur et lui
|
|
|
|
transfère la requête. Ces destinations sont de simples instances de "serveur" I2PTunnel exécutées par des
|
|
|
|
volontaires ayant délibérément décidé de fonctionner en mandataire sortant. Personne n'est dans ce cas par défaut,
|
|
|
|
et rien n'indique automatiquement aux autres de passer votre proxy si vous avez décidé de jouer ce rôle.
|
|
|
|
Bien que les mandataires sortants soient intrinsèquement porteurs de faiblesses, ils démontrent la faisabilité
|
|
|
|
de l'utilisation d'I2P pour certaines utilisations dans lesquelles le modèle de sécurité resterait suffisant pour
|
|
|
|
certains utilisateurs.</p>
|
|
|
|
<p> I2PTunnel active l'utilisation de la plupart des applications. Un "serveur HTTP" pointant sur un serveur web
|
|
|
|
permet à chacun d'avoir son propre site web anonyme (appelé "eepsite"): un serveur web est fourni avec I2P à cet
|
|
|
|
effet, mais on peut utiliser n'importe lequel. Chacun peut utiliser un "client" pointant vers un des serveurs IRC
|
|
|
|
hébergés anonymement, chacun d'entre eux pointant vers son service local IRC et communicant entre services avec
|
|
|
|
leur propre tunnels "clients". Les utilisateurs ont aussi des tunnels "clients" pointant sur des destinations
|
|
|
|
POP3 et SMTP <a href="#app.i2pmail">I2Pmail</a> (qui sont également de simples instances "serveur" pointant sur des
|
|
|
|
serveurs POP3 et SMTP), ainsi que que des tunnels "clients" pour des serveurs CVS sur I2P (pour du développement
|
|
|
|
anonyme). Il y même eu des gens avec des "clients" mandataires pour accéder à des instances "serveur" pointant sur
|
|
|
|
un serveur NNTP.</p>
|
2011-03-06 21:34:26 +00:00
|
|
|
|
|
|
|
<h2 id="app.i2pbt">i2p-bt</h2>
|
2011-03-21 11:22:48 +00:00
|
|
|
<p><i>Développé par duck et al</i></p>
|
|
|
|
<p> i2p-bt est un portage du client BitTorrent python principal destiné à exécuter le tracker et gérer
|
|
|
|
la communication entre pairs I2P. Les demandes du tracker sont transmises par le mandataire eepproxy aux sites eep
|
|
|
|
indiqués dans le fichier torrent, et les réponses se rapportent explicitement aux pairs par leur destination: ceci
|
|
|
|
permet à i2p-bt d'ouvrir une connexion par la <a href="#app.streaming">bibliothèque de flux</a> pour demander les
|
|
|
|
blocs.</p>
|
|
|
|
<p> En complément à i2p-bt, un portage I2P de bytemonsoon a été réalisé, en faisant quelques modifications pour en
|
|
|
|
retirer quelques informations compromettant l'anonymat et prendre du fait que l'IP ne permet pas l'identification
|
|
|
|
des pairs.</p>
|
2011-03-06 21:34:26 +00:00
|
|
|
|
|
|
|
<h2 id="app.i2psnark">I2PSnark</h2>
|
2011-03-21 11:22:48 +00:00
|
|
|
<p><i>I2PSnark développé par jrandom et al, porté du client <a
|
|
|
|
href="http://www.klomp.org/snark/">Snark</a> de <a
|
|
|
|
href="http://www.klomp.org/mark/">mjw</a>.</i></p>
|
|
|
|
<p> Fourni à l'installation d'I2P, I2PSnark offre un client BitTorrent anonyme simple doté de possibilités
|
|
|
|
multitorrents, et entièrement interfacé en HTML</p>
|
2011-03-06 21:34:26 +00:00
|
|
|
|
|
|
|
<h2 id="app.robert">Robert</h2>
|
2011-03-21 11:22:48 +00:00
|
|
|
<p><i>Développé par sponge</i></p>
|
|
|
|
<p>Robert est un client Bittorrent écrit en Python.
|
|
|
|
Disponible sur <a href="http://bob.i2p/Robert.html">http://bob.i2p/Robert.html</a></p> <!-- TODO: expand -->
|
2011-03-06 21:34:26 +00:00
|
|
|
|
|
|
|
<h2 id="app.pybit">PyBit</h2>
|
2011-03-21 11:22:48 +00:00
|
|
|
<p><i>Développé par Blub</i></p>
|
|
|
|
<p>PyBit est un client Bittorrent écrit en Python.
|
|
|
|
Disponible sur <a href="http://pebcache.i2p/">http://pebcache.i2p/</a></p> <!-- TODO: expand -->
|
2011-03-06 21:34:26 +00:00
|
|
|
|
|
|
|
<h2 id="app.i2phex">I2Phex</h2>
|
2011-03-21 11:22:48 +00:00
|
|
|
<p><i>Développé par sirup</i></p>
|
|
|
|
<p> I2Phex est un portage assez direct du client de partage de fichiers Gnutella Phex. Bien que certaines
|
|
|
|
fonctionnalités aient été désactivées (comme l'intégration des caches web Gnutella), les fonctions basiques de
|
|
|
|
partage de fichiers et de chat sont pleinement opérationnelles.</p>
|
2011-03-06 21:34:26 +00:00
|
|
|
<h2 id="app.i2pmail">I2Pmail/susimail</h2>
|
2011-03-21 11:22:48 +00:00
|
|
|
<p><i>Développé par postman, susi23 et mastiejaner</i></p>
|
|
|
|
<p> I2Pmail est plus un service qu'une application: postman offre un service de mail interne et externe par
|
|
|
|
POP3 et SMTP via des instances I2PTunnel accédant à une série de composants développés avec mastiejaner,
|
|
|
|
permettant aux gens d'utiliser leur client de messagerie préféré pour envoyer et recevoir du courriel avec un
|
|
|
|
pseudonyme. Cependant, comme la plupart de ces clients ont la fâcheuse manie d'embarquer dans les messages des
|
|
|
|
informations compromettant l'anonymat, I2P fournit le client webmail de susi23 construit avec les toutes les
|
|
|
|
exigences d'anonymat en tête. Le service I2Pmail/mail.i2p offre un filtrage anti-virus transparent et une
|
|
|
|
prévention de déni de service par des quotas à pénalités incrémentielles. De plus, chaque utilisateur dispose du
|
|
|
|
contrôle de sa stratégie de traitement par lots avant l'envoi par les mandataires sortants de mail.i2p,
|
|
|
|
qui sont différents des serveurs de mail SMPT/POP3 de mail.i2p: les mandataires sortants et entrants communiquent
|
|
|
|
avec les serveurs de mail d'i2p via I2P lui-même, donc la compromission de ces emplacements non anonymes ne
|
|
|
|
donnerait accès aux comptes de messagerie ou aux motifs/profils d'activité des utilisateurs. En ce moment,
|
|
|
|
les développeurs travaillent sur un système de messagerie décentralisé, appelé "v2mail".
|
|
|
|
Plus d'infos sur le site eep <a href="http://hq.postman.i2p/">hq.postman.i2p</a>.</p>
|
2011-03-06 21:34:26 +00:00
|
|
|
|
|
|
|
<h2 id="app.i2pbote">I2P-Bote</h2>
|
2011-03-21 11:22:48 +00:00
|
|
|
<p><i>Développé par HungryHobo</i></p>
|
2011-03-06 21:34:26 +00:00
|
|
|
<p>
|
2011-03-21 11:22:48 +00:00
|
|
|
I2P-Bote est une application de messagerie décentralisée. Elle n'utilise pas le concept traditionnel
|
|
|
|
d'envoi/réception de messages à un serveur. Elle utilise une table de hachage décentralisée Kedemlia pour stocker
|
|
|
|
les messages. Un utilisateur peut envoyer son message vers la DHT, un autre peut en extraire les siens destinés.</p>
|
2011-03-06 21:34:26 +00:00
|
|
|
|
|
|
|
<h2 id="app.i2pmessenger">I2P-messenger</h2>
|
|
|
|
<p>
|
2011-03-21 11:22:48 +00:00
|
|
|
I2P-messenger est une application de communication sans serveur cryptée de bout en bout. Pour communiquer, deux
|
|
|
|
utilisateurs doivent se donner l'un à l'autre leur destination pour se mettre en relation.
|
2011-03-06 21:34:26 +00:00
|
|
|
</p>
|
|
|
|
{% endblock %}
|