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. Some example uses of the network include "eepsites" (webservers hosting normal web
applications within I2P), a BitTorrent client ("I2PSnark"), 
or a distributed data store.  With the help of the <a href="i2ptunnel">I2PTunnel</a> application, 
we are able to stream traditional TCP/IP applications over I2P, such as SSH, IRC, a squid proxy, and 
even streaming audio. Most people will not use I2P directly, or even need to know they're using it. 
Instead their view will be of one of the I2P enabled applications, or perhaps as a little controller 
app to turn on and off various proxies to enable the anonymizing functionality.</p>

<p>An essential part of designing, developing, and testing an anonymizing network is to define the 
<a href="how_threatmodel">threat model</a>, since there is no such thing as "true" anonymity, just 
increasingly expensive costs to identify someone. Briefly, I2P's intent is to allow people to communicate 
in arbitrarily hostile environments by providing good anonymity, mixed in with sufficient cover 
traffic provided by the activity of people who require less anonymity. This way, some users can avoid
detection by a very powerful adversary, while others will try to evade a weaker entity,
<i>all on the same network</i>, where each one's messages are essentially indistinguishable from the 
others.</p>

<h2>Why?</h2>
<p>There are a multitude of reasons why we need a system to support 
anonymous communication, and everyone has their own personal rationale. There are many 
<a href="how_networkcomparisons">other efforts</a> working on finding ways to provide varying degrees of 
anonymity to people through the Internet, but we could not find any that met our needs or threat 
model.</p>

<h2>How?</h2>

<p>The network at a glance is made up of a set of nodes ("routers") with a number of unidirectional 
inbound and outbound virtual paths ("tunnels", as outlined on the <a href="how_tunnelrouting">tunnel routing</a> page). 
Each router is identified by a cryptographic RouterIdentity which is typically long lived. These routers 
communicate with each other through existing transport mechanisms (TCP, UDP, etc), passing various 
messages.  Client applications have their own cryptographic identifier ("Destination") which enables it 
to send and receive messages. These clients can connect to any router and authorize the temporary 
allocation ("lease") of some tunnels that will be used for sending and receiving messages through the 
network.  I2P has its own internal <a href="how_networkdatabase">network database</a> (using a modification of 
the Kademlia algorithm) for distributing routing and contact information securely.</p>

<center><div class="box"><img src="_static/images/net.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.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 %}