updates
This commit is contained in:
@@ -36,6 +36,14 @@ layers of encryption, and the network is both distributed and dynamic, with no t
|
||||
<p>
|
||||
Many applications are available that interface with I2P, including
|
||||
mail, peer-peer, IRC chat, and others.
|
||||
</p><p>
|
||||
I2P is growing fast! There were nine releases in 2009, and traffic grew by a factor of 5:
|
||||
</p><p>
|
||||
<center>
|
||||
<div class="box">
|
||||
<img src="/_static/images/bandwidth2009.png" alt="2009 bandwidth" />
|
||||
</div>
|
||||
</center>
|
||||
</p>
|
||||
|
||||
<p>
|
||||
|
@@ -22,6 +22,7 @@
|
||||
<li><a href="http://www.gulli.com/news/i2p-an-anonymous-network-2009-03-09/">zzz interviewed by gulli.com</a> (March '09)</li>
|
||||
<li><a href="http://www.netzwelt.de/news/75371-i2p-das-anonyme-netz-im.html">Netzwelt.de article about being anonymous in the internet</a></li>
|
||||
<h4>Boards, newssite, others</h4>
|
||||
<li><a href="http://twitter.com/i2p">i2p (zzz) on twitter</a></li>
|
||||
<li><a href="http://board.planetpeer.de/index.php?board=80.0">Planet Peer Board (English)</a></li>
|
||||
<li><a href="http://board.planetpeer.de/index.php?board=18.0">Planet Peer Board (Deutsch)</a></li>
|
||||
<h4>Very Old Stuff</h4>
|
||||
|
@@ -22,6 +22,7 @@
|
||||
<li><a href="http://www.gulli.com/news/i2p-anonymes-netzwerk-im-2009-03-09/">zzz interviewed by gulli.com</a> (März '09)</li>
|
||||
<li><a href="http://www.netzwelt.de/news/75371-i2p-das-anonyme-netz-im.html">Netzwelt.de Artikel über anoym im Internet</a></li>
|
||||
<h4>Boards, Newsseiten, anderes</h4>
|
||||
<li><a href="http://twitter.com/i2p">i2p (zzz) on twitter</a></li>
|
||||
<li><a href="http://board.planetpeer.de/index.php?board=18.0">Planet Peer Board (Deutsch)</a></li>
|
||||
<li><a href="http://board.planetpeer.de/index.php?board=80.0">Planet Peer Board (English)</a></li>
|
||||
<h4>Very Old Stuff</h4>
|
||||
|
@@ -6,7 +6,6 @@
|
||||
<b class="title">
|
||||
<h1>I2P: <font size="3">A scalable framework for anonymous communication</font></h1>
|
||||
</b>
|
||||
<!-- <i style="font-size: 8">$Id: techintro.html,v 1.8.2.1 2006/02/13 07:13:35 jrandom Exp $</i> -->
|
||||
<br/>
|
||||
<div class="toc">
|
||||
<table border="0">
|
||||
|
@@ -2,7 +2,8 @@
|
||||
{% block title %}Tunnel Creation{% endblock %}
|
||||
{% block content %}
|
||||
|
||||
<code>$Id: tunnel-alt-creation.html,v 1.1.2.1 2006/02/01 20:28:34 jrandom Exp $</code>
|
||||
<b>Note: This documents the current tunnel build implementation as of release 0.6.1.10.</b>
|
||||
<br>
|
||||
<pre>
|
||||
1) <a href="#tunnelCreate.overview">Tunnel creation</a>
|
||||
1.1) <a href="#tunnelCreate.requestRecord">Tunnel creation request record</a>
|
||||
@@ -161,8 +162,8 @@ inject a random delay before forwarding on the request?</li>
|
||||
<li>This strategy came about during a discussion on the I2P mailing list
|
||||
between Michael Rogers, Matthew Toseland (toad), and jrandom regarding
|
||||
the predecessor attack. See: <ul>
|
||||
<li><a href="http://dev.i2p.net/pipermail/i2p/2005-October/001073.html">Summary</a></li>
|
||||
<li><a href="http://dev.i2p.net/pipermail/i2p/2005-October/001064.html">Reasoning</a></li>
|
||||
<li><a href="http://osdir.com/ml/network.i2p/2005-10/msg00138.html">Summary</a></li>
|
||||
<li><a href="http://osdir.com/ml/network.i2p/2005-10/msg00129.html">Reasoning</a></li>
|
||||
</ul></li>
|
||||
</ul>
|
||||
|
||||
|
@@ -2,7 +2,8 @@
|
||||
{% block title %}Tunnel Implementation{% endblock %}
|
||||
{% block content %}
|
||||
|
||||
<code>$Id: tunnel-alt.html,v 1.9 2005/07/27 14:04:07 jrandom Exp $</code>
|
||||
<b>Note: This documents the current tunnel build implementation as of release 0.6.1.10.</b>
|
||||
<br>
|
||||
<pre>
|
||||
1) <a href="#tunnel.overview">Tunnel overview</a>
|
||||
2) <a href="#tunnel.operation">Tunnel operation</a>
|
||||
@@ -28,6 +29,7 @@
|
||||
3.4.2) <a href="#tunnel.building.nonexploratory">Non-exploratory tunnels for management</a>
|
||||
4) <a href="#tunnel.throttling">Tunnel throttling</a>
|
||||
5) <a href="#tunnel.mixing">Mixing/batching</a>
|
||||
See <a href="tunnel-alt-creation.html">tunnel creation</a> for additional details.
|
||||
</pre>
|
||||
|
||||
<h2>1) <a name="tunnel.overview">Tunnel overview</a></h2>
|
||||
@@ -106,6 +108,8 @@ fragments it across the necessary number of 1KB tunnel messages, and decides how
|
||||
each I2NP message should be handled by the tunnel endpoint, encoding that
|
||||
data into the raw tunnel payload:</p>
|
||||
<ul>
|
||||
<li>The 4 byte Tunnel ID</li>
|
||||
<li>The 16 byte IV</li>
|
||||
<li>the first 4 bytes of the SHA256 of (the remaining preprocessed data concatenated
|
||||
with the IV), using the IV as will be seen on the tunnel endpoint (for
|
||||
outbound tunnels), or the IV as was seen on the tunnel gateway (for inbound
|
||||
@@ -124,7 +128,7 @@ how the remainder of the header is interpreted - if it is not set, the message
|
||||
is either not fragmented or this is the first fragment in the message. If it is
|
||||
set, this is a follow on fragment.</p>
|
||||
|
||||
<p>With the first (leftmost or MSB) bit being 0, the instructions are:</p>
|
||||
<p>With the first (leftmost or MSB) bit being 0, this is the first or only fragment, and the instructions are:</p>
|
||||
<ul>
|
||||
<li>1 byte control byte:<pre>
|
||||
bit 0: is follow on fragment? (1 = true, 0 = false, must be 0)
|
||||
@@ -146,7 +150,7 @@ set, this is a follow on fragment.</p>
|
||||
<li>2 byte size of the I2NP message or this fragment</li>
|
||||
</ul>
|
||||
|
||||
<p>If the first bit being 1, the instructions are:</p>
|
||||
<p>If the first bit being 1, this is a follow-on fragment, and the instructions are:</p>
|
||||
<ul>
|
||||
<li>1 byte control byte:<pre>
|
||||
bit 0: is follow on fragment? (1 = true, 0 = false, must be 1)
|
||||
@@ -157,7 +161,9 @@ set, this is a follow on fragment.</p>
|
||||
</ul>
|
||||
|
||||
<p>The I2NP message is encoded in its standard form, and the
|
||||
preprocessed payload must be padded to a multiple of 16 bytes.</p>
|
||||
preprocessed payload must be padded to a multiple of 16 bytes.
|
||||
The total size, including the tunnel ID and IV, is 1028 bytes.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
While the maximum payload size is nominally 64KB, the size is further constrained by the
|
||||
@@ -450,7 +456,7 @@ leakage of information about what peers are in the router's partition.</p>
|
||||
|
||||
<h4>3.4.3) <a name="tunnel.building.exploratory">Exploratory request delivery</a></h4>
|
||||
|
||||
<p>A third alternative, used until I2P 0.6.2, garlic encrypts individual tunnel
|
||||
<p>A third alternative, used until I2P 0.6.1.10, garlic encrypts individual tunnel
|
||||
request messages and delivers them to the hops individually, transmitting them
|
||||
through exploratory tunnels with their reply coming back in a separate
|
||||
exploratory tunnel. This strategy has been dropped in favor of the one outlined
|
||||
|
@@ -2,9 +2,8 @@
|
||||
{% block title %}Old Tunnel Implementation{% endblock %}
|
||||
{% block content %}
|
||||
|
||||
<b>Note: Obsolete - NOT used! Replaced in 0.6.1.10 - see <a href="tunnel-alt.html">tunnel-alt.html</a> for the new implementation</b>
|
||||
<b>Note: Obsolete - NOT used! Replaced in 0.6.1.10 - see <a href="tunnel-alt.html">tunnel-alt.html</a> for the current implementation</b>
|
||||
<br>
|
||||
<code>$Id: tunnel.html,v 1.10 2005/01/16 01:07:07 jrandom Exp $</code>
|
||||
<pre>
|
||||
1) <a href="#tunnel.overview">Tunnel overview</a>
|
||||
2) <a href="#tunnel.operation">Tunnel operation</a>
|
||||
|
@@ -2,8 +2,6 @@
|
||||
{% block title %}SSU{% endblock %}
|
||||
{% block content %}
|
||||
|
||||
<code>$Id: udp.html,v 1.19 2006/02/15 00:33:32 jrandom Exp $</code>
|
||||
|
||||
<h1>Secure Semireliable UDP (SSU)</h1>
|
||||
<p>
|
||||
SSU (also called "UDP" in much of the I2P documentation and user interfaces)
|
||||
@@ -619,7 +617,7 @@ contacts him, though Alice's DSA key may not already be known by
|
||||
Bob.</p>
|
||||
|
||||
<p>Upon receiving a message, the receiver checks the "from" IP address and port
|
||||
with all established sessions - if is a matches,
|
||||
with all established sessions - if there are matches,
|
||||
that session's MAC keys are tested in the HMAC. If none
|
||||
of those verify or if there are no matching IP addresses, the
|
||||
receiver tries their introKey in the MAC. If that does not verify,
|
||||
|
BIN
www.i2p2/static/images/bandwidth2009.png
Normal file
BIN
www.i2p2/static/images/bandwidth2009.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 12 KiB |
Reference in New Issue
Block a user