This commit is contained in:
zzz
2010-01-02 02:47:28 +00:00
parent 80f243d2fc
commit 148053441e
9 changed files with 27 additions and 14 deletions

View File

@@ -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>

View File

@@ -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>

View File

@@ -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 &uuml;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>

View File

@@ -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">

View File

@@ -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>

View File

@@ -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

View File

@@ -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>

View File

@@ -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,

Binary file not shown.

After

Width:  |  Height:  |  Size: 12 KiB