i2p.www/www.i2p2/pages/how_intro_fr.html

{% extends "_layout_fr.html" %}
{% block title %}Introduction en douceur{% endblock %}
{% block content %}

<h2>Une présentation allégée du fonctionnement d'I2P</h2>
Traduction (en cours) de mars 2011. <a href="how_intro.html">Version anglaise actuelle</a>
<p>I2P est un projet dont le but est de construire, déployer, et maintenir un réseau fournissant 
des communications sécurisées et anonymes. 
Les gens utilisant I2P ont le contrôle de l'arbitrage entre l'anonymat, la fiabilité, 
l'utilisation de la bande passante, et la latence. Il n'y a dans ce réseau, pas de centre sur lequel pourrait 
être exercée une pression en vue de compromettre l'intégrité, la sécurité, ou l'anonymat du système. 
Le réseau intègre sa propre reconfiguration dynamique en réponse aux diverses attaques, 
et a été conçu to pour utiliser de nouvelles ressources au fur et à mesure de leur disponibilité. 
Bien entendu, tous les aspects du réseau sont publics et disponibles gratuitement.</p>

<p>Contrairement à de nombreux autres réseaux anonymisants, I2P ne tente pas de procurer l'anonymat en masquant 
l'initiateur et pas le destinataire, ou le contraire. I2P est conçu pour permettre  
aux pairs l'utilisant de communiquer anonymement &mdash; l'émetteur et le récepteur sont non-identifiables  
l'un par l'autre comme par un tiers. Par exemple, il y a aujourd'hui des sites web intra-I2P 
(permettant la publication/hébergement anonymes) tout comme des serveurs mandataires HTTP vers le web normal 
(permettant la navigation anonyme). La possibilité d'avoir des serveurs dans I2P est essentielle, 
car il est plus que certain que n'importe quel proxy sortant vers l'Internet sera surveillé, désactivé, 
ou même piraté pour tenter des attaques encore plus pernicieuses.</p>

<p>Le réseau lui-même est "orienté messages": il est principalement constitué d'une couche IP sécurisée et anonyme, 
dans laquelle les messages sont adressés à des clés cryptographiques (Destinations) et peuvent être sensiblement
plus gros que des paquets IP. À titre d'exemples d'utilisation du réseau citons les "eepsites" (serveurs web hébergeant
des applications Internet normales au sein d'I2P), un client BitTorrent ("I2PSnark"), 
ou un système de stckage distribué.  Grâce à l'application <a href="i2ptunnel">I2PTunnel</a>, 
nous pouvons utiliser des applications TCP/IP traditionnelles sur I2P, telles que SSH, IRC, un proxy squid, et même 
du flux audio. La plupart des gens n'utilisent pas I2P directement, ou ne ressentent même pas le besoin de savoir
qu'ils l'utilisent. 
Au lieu de ça ils verront une des application compatibles avec I2P, ou peut-être une petite application  
de contrôle qui va activer ou désactiver divers proxies pour piloter la fonctionnalité d'anonymisation.</p>

<p>Un des points clés de la conception, dus développement, et du test d'un réseau anonyme est la définition de son
<a href="how_threatmodel">modèle de sécurité</a>, car il n'existe nulle part un "vrai" anonymat, mais uniquement 
des moyens d'augmenter les coûts d'identification de quelqu'un. Succintement, le but d'I2P est de permettre de 
communiquer dans des environnements hostiles en procurant un bon anonymat, mélangé à un trafic de camouflage  
suffisant fourni par l'activité de ceux qui ont besoin de moins d'anonymat, de sorte que certains utilisateurs puissent
se soustraire à la détection par un adversaire très puissant, quand d'autres pourront esquiver une entité plus faible,
<i>tout ceci sur le même réseau</i> dans lequel les messages des uns sont fondamentalement indistingables de ceux des 
autres.</p>

<h2>Pourquoi?</h2>
<p>Il y a une multitude de raisons qui justifient que nous ayons besoin d'un système de communication anonyme,  
et chacun a les siennes propres. Il y a de nombreux  
<a href="how_networkcomparisons">autres efforts</a> pour trouver les moyens de fournir divers niveaux  
d'anonymat sur Internet, mais nous n'en avons trouvé aucun qui réponde à nos besoins ou à notre modèle de sécurité.</p>

<h2>Comment?</h2>

<p>Au premier coup d'œil le réseau est constitué d'un tas de nœuds ("routeurs") dotés d'un certain nombre
de chemins virtuels entrants et sortants unidirectionels
(appelés "tunnels", expliqués sur la page <a href="how_tunnelrouting">routage en tunnel</a>). 
Chaque routeur est identifié par l'identifiant cryptographique "RouterIdentity", 
typiquement de longue durée de vie. Ces routeurs communiquent par des mécanismes existants 
(TCP, UDP, etc). Les applications clientes ont leur propre identifiant cryptographique ("Destination") qui leur 
permet d'envoyer et de recevoir des messages. Ces clients peuvent se connecter à n'importe quel routeur et 
autoriser l'allocation temporaire ("lease") de quelques tunnels qui seront utilisés pour l'envoi et la réception
à travers le réseau. I2P dispose de sa propre <a href="how_networkdatabase">base de donnée réseau</a> interne 
(avec une modification de l'algorithme Kademlia) pour une distribution sécurisée 
des informations de routage et de contacts.</p>

<center><div class="box">
<img src="_static/images/net_fr.png" alt="Network topology example" title="Network topology example" /></div></center><br/>


<p>In the above, Alice, Bob, Charlie, and Dave are all running routers with a single Destination on their 
local router.  They each have a pair of 2-hop inbound tunnels per destination (labeled 1,2,3,4,5 and 6),
and a small subset of each of those router's outbound tunnel pool is shown with 2-hop outbound tunnels.
For simplicity, Charlie's inbound tunnels and Dave's outbound tunnels are not shown, nor are the rest of
each router's outbound tunnel pool (typically stocked with a few tunnels at a time).  When Alice and Bob
talk to each other, Alice sends a message out one of her (pink) outbound tunnels targeting one of Bob's
(green) inbound tunnels (tunnel 3 or 4).  She knows to send to those tunnels on the correct router by querying the
network database, which is constantly updated as new leases are authorized and old ones expire.</p>
  
<p>If Bob wants to reply to Alice, he simply goes through the same process - send a message out one of his
outbound tunnels targeting one of Alice's inbound tunnels (tunnel 1 or 2).  To make things easier, most 
messages sent between Alice and Bob are <a href="how_garlicrouting">garlic</a> wrapped, bundling the 
sender's own current lease information so that the recipient can reply immediately without having to look 
in the network database for the current data.</p>

<p>To deal with a wide range of attacks, I2P is fully distributed with no centralized resources - and 
hence there are no directory servers keeping statistics regarding the performance and reliability of 
routers within the network. As such, each router must keep and maintain profiles of various routers 
and is responsible for selecting appropriate peers to meet the anonymity, performance, and reliability 
needs of the users, as described in the <a href="how_peerselection">peer selection</a> page.</p>

<p>The network itself makes use of a significant number of 
<a href="how_cryptography">cryptographic techniques and algorithms</a> - 
a full laundry list includes 2048bit ElGamal encryption, 256bit AES in CBC mode with PKCS#5 padding, 
1024bit DSA signatures, SHA256 hashes, 2048bit Diffie-Hellman negotiated connections with station to 
station authentication, and <a href="how_elgamalaes">ElGamal / AES+SessionTag</a>.</p>

<p>Content sent over I2P is encrypted through three layers garlic encryption 
(used to verify the delivery of the message to 
the recipient), tunnel encryption (all messages passing through a tunnel is encrypted by the tunnel 
gateway to the tunnel endpoint), and inter router transport layer encryption (e.g. the TCP transport 
uses AES256 with ephemeral keys):</p>
<p>End-to-end (I2CP) encryption (client application to server application) was disabled in I2P release 0.6; 
end-to-end (garlic) encryption (I2P client router to I2P server router) from Alice's router "a" to 
Bob's router "h" remains.
Notice the different use of terms! All data from a to h is end-to-end encrypted, but the I2CP connection
between the I2P router and the applications is not end-to-end encrypted!
A and h are the routers of Alice and Bob, 
while Alice and Bob in following chart are the applications running atop of I2P.</p>

<center><div class="box"><img src="_static/images/endToEndEncryption_fr.png" 
alt="End to end layered encryption" title="End to end layered encryption." /></div></center><br/>

<p>The specific use of these algorithms are outlined <a href="how_cryptography">elsewhere</a>.</p>

<p>The two main mechanisms for allowing people who need strong anonymity to use the network are 
explicitly delayed garlic routed messages and more comprehensive tunnels to include support for pooling 
and mixing messages. These are currently planned for release 3.0, but garlic routed messages with no 
delays and FIFO tunnels are currently in place. Additionally, the 2.0 release will allow people to set 
up and operate behind restricted routes (perhaps with trusted peers), as well as the deployment of more 
flexible and anonymous transports.</p>

<p>Some questions have been raised with regards to the scalability of I2P, and reasonably so. There 
will certainly be more analysis over time, but peer lookup and integration should be bounded by 
<code>O(log(N))</code> due to the <a href="how_networkdatabase">network database</a>'s algorithm, while end to end 
messages should be <code>O(1)</code> (scale free), since messages go out K hops through the outbound 
tunnel and another K hops through the inbound tunnel, with K no longer than 3.
The size of the network (N) bears no impact.</p>

<h2>When?</h2>
<p>I2P initially began in Feb 2003 as a proposed modification to 
<a href="http://freenetproject.org">Freenet</a> to allow it to use alternate transports, such as 
<a href="http://java.sun.com/products/jms/index.jsp">JMS</a>, then grew into its own as an 
'anonCommFramework' in April 2003, turning into I2P in July, with code being written in earnest starting in August '03.
I2P is currently under development, following
the <a href="roadmap">roadmap</a>.</p>

<h2>Who?</h2>
<p>We have a small <a href="team">team</a> spread around several continents, working to advance different 
aspects of the project.  We are very open to other developers who want to get involved and anyone else 
who would like to contribute in other ways, such as critiques, peer review, testing, writing I2P enabled 
applications, or documentation. The entire system is open source - the router and most of the SDK are 
outright public domain with some BSD and Cryptix licensed code, while some applications like I2PTunnel 
and I2PSnark are GPL. Almost everything is written in Java (1.5+), though some third party applications 
are being written in Python and other languages. The code works on 
<a href="http://java.com/en/">Sun Java SE</a> and other Java Virtual Machines.
</p>

<h2>Where?</h2>
<p>Anyone interested should
join us on the IRC channel #i2p (hosted concurrently on irc.freenode.net, irc.postman.i2p, 
irc.freshcoffee.i2p, irc.welterde.i2p and irc.einirc.de).
There are currently no scheduled development meetings, however
<a href="meetings">archives are available</a>.</p>

<p>The current source is available in <a href="monotone.html">monotone</a>.</p>

<h2>Additional Information</h2>
<p>
See <a href="how_fr.html">the Index to Technical Documentation</a>
</p>

{% endblock %}