crypto, i2np, plugin, attr tweaks

This commit is contained in:
zzz
2010-08-07 14:07:11 +00:00
parent a8d49d32ea
commit a9e423d17d
9 changed files with 23 additions and 36 deletions

0
www.i2p2/pages/_layout_it.html Executable file → Normal file
View File

0
www.i2p2/pages/announcements_it.html Executable file → Normal file
View File

0
www.i2p2/pages/api_it.html Executable file → Normal file
View File

0
www.i2p2/pages/bounties_it.html Executable file → Normal file
View File

View File

@ -37,7 +37,7 @@ block is formatted (in network byte order):
<p>
The H(data) is the SHA256 of the data that is encrypted in the ElGamal block,
and is preceded by a random nonzero byte. The data encrypted in the block
can be up to 223 bytes long. See
can be up to 222 bytes long. See
<a href="http://docs.i2p2.de/core/net/i2p/crypto/ElGamalEngine.html">the ElGamal Javadoc</a>.
<p>
ElGamal is never used on its own in I2P, but instead always as part of
@ -142,6 +142,12 @@ The vulnerability of the network to an AES attack and the impact of transitionin
It may be quite difficult to make any change backward-compatible.
</p>
<H4>References</H4>
<ul>
<li>
<a href="status-2006-02-07.html">Feb. 7, 2006 Status Notes</a>
</ul>
<H2><a name="DSA">DSA</a></H2>

View File

@ -42,7 +42,7 @@ This is a topic for further research, analysis and testing.
<tr><td>Expiration<td>8
<tr><td>Payload Length<td>2
<tr><td>Checksum<td>1
<tr><td>Payload<td>0 - 60.6KB
<tr><td>Payload<td>0 - 61.2KB
</table>
<p>
@ -50,8 +50,12 @@ While the maximum payload size is nominally 64KB, the size is further constraine
method of fragmenting I2NP messages into multiple 1KB tunnel messages as described in
<a href="tunnel-alt.html">tunnel-alt.html</a>.
The maximum number of fragments is 64, and the message may not be perfectly aligned,
so the message must nominally fit in 63 fragments, and be padded to a 16 byte boundary.
Therefore the maximum size is 960 + (62 * 986) - 12 = 62080 bytes, or approximately 60.6KB.
So the message must nominally fit in 63 fragments.
<p>
The maximum size of an initial fragment is 956 bytes (assuming TUNNEL delivery mode);
the maximum size of a follow-on fragment is 996 bytes.
Therefore the maximum size is approximately 956 + (62 * 996) = 62708 bytes, or 61.2 KB.
</p>
<p>
In addition, the transports may have additional restrictions.
NTCP currently limits to 16KB - 6 = 16378 bytes but this will be increased in a future release.
@ -172,6 +176,8 @@ Others listed in
</table>
<h3>Full Protocol Specification</h3>
<a href="i2np_spec.html">On the I2NP Specification page</a>
<a href="i2np_spec.html">On the I2NP Specification page</a>.
See also the
<a href="common_structures_spec.html">Common Data Structure Specification page</a>.
{% endblock %}

View File

@ -18,7 +18,7 @@ common transports supported.
<h3 id="struct_header">I2NP message header</h3>
<h4>Description</h4>
<p>
Common header to all I2NP messages, which contains important information like an checksum, expiration date, etc.
Common header to all I2NP messages, which contains important information like a checksum, expiration date, etc.
</p>
<h4>Contents</h4>
<p>
@ -193,7 +193,7 @@ padding :: Data
source -> random
total length: 223
total length: 222
encrypted:
@ -431,7 +431,8 @@ key:
from:
32 bytes
SHA256 hash of the routerInfo entry this request came from(and to which the reply should be sent)
If flag == 0, the SHA256 hash of the routerInfo entry this request came from (and to which the reply should be sent)
If flag == 1, the SHA256 hash of the reply tunnel gateway (to which the reply should be sent)
flag:
1 byte
@ -440,7 +441,7 @@ flag:
1 TRUE => send reply to some tunnel
reply tunnelId:
2 bytes
4 bytes
only included if flag==TRUE
tunnelId of the tunnel to send the reply to

View File

@ -1,26 +0,0 @@
<i2p.news date="$Date: 2007-10-07 23:03:40 $">
<i2p.release version="0.6.1.30" date="2007/02/15" minVersion="0.6"
anonurl="http://i2p/NF2RLVUxVulR3IqK0sGJR0dHQcGXAzwa6rEO4WAWYXOHw-DoZhKnlbf1nzHXwMEJoex5nFTyiNMqxJMWlY54cvU~UenZdkyQQeUSBZXyuSweflUXFqKN-y8xIoK2w9Ylq1k8IcrAFDsITyOzjUKoOPfVq34rKNDo7fYyis4kT5bAHy~2N1EVMs34pi2RFabATIOBk38Qhab57Umpa6yEoE~rbyR~suDRvD7gjBvBiIKFqhFueXsR2uSrPB-yzwAGofTXuklofK3DdKspciclTVzqbDjsk5UXfu2nTrC1agkhLyqlOfjhyqC~t1IXm-Vs2o7911k7KKLGjB4lmH508YJ7G9fLAUyjuB-wwwhejoWqvg7oWvqo4oIok8LG6ECR71C3dzCvIjY2QcrhoaazA9G4zcGMm6NKND-H4XY6tUWhpB~5GefB3YczOqMbHq4wi0O9MzBFrOJEOs3X4hwboKWANf7DT5PZKJZ5KorQPsYRSq0E3wSOsFCSsdVCKUGsAAAA/i2p/i2pupdate.sud"
publicurl="http://mirror.i2p2.de/i2pupdate.sud"
anonannouncement="http://i2p/NF2RLVUxVulR3IqK0sGJR0dHQcGXAzwa6rEO4WAWYXOHw-DoZhKnlbf1nzHXwMEJoex5nFTyiNMqxJMWlY54cvU~UenZdkyQQeUSBZXyuSweflUXFqKN-y8xIoK2w9Ylq1k8IcrAFDsITyOzjUKoOPfVq34rKNDo7fYyis4kT5bAHy~2N1EVMs34pi2RFabATIOBk38Qhab57Umpa6yEoE~rbyR~suDRvD7gjBvBiIKFqhFueXsR2uSrPB-yzwAGofTXuklofK3DdKspciclTVzqbDjsk5UXfu2nTrC1agkhLyqlOfjhyqC~t1IXm-Vs2o7911k7KKLGjB4lmH508YJ7G9fLAUyjuB-wwwhejoWqvg7oWvqo4oIok8LG6ECR71C3dzCvIjY2QcrhoaazA9G4zcGMm6NKND-H4XY6tUWhpB~5GefB3YczOqMbHq4wi0O9MzBFrOJEOs3X4hwboKWANf7DT5PZKJZ5KorQPsYRSq0E3wSOsFCSsdVCKUGsAAAA/pipermail/i2p/2005-September/000878.html"
publicannouncement="http://dev.i2p.net/pipermail/i2p/2005-September/000878.html" />
<i2p.notes date="2005/08/08"
anonurl="http://i2p/NF2RLVUxVulR3IqK0sGJR0dHQcGXAzwa6rEO4WAWYXOHw-DoZhKnlbf1nzHXwMEJoex5nFTyiNMqxJMWlY54cvU~UenZdkyQQeUSBZXyuSweflUXFqKN-y8xIoK2w9Ylq1k8IcrAFDsITyOzjUKoOPfVq34rKNDo7fYyis4kT5bAHy~2N1EVMs34pi2RFabATIOBk38Qhab57Umpa6yEoE~rbyR~suDRvD7gjBvBiIKFqhFueXsR2uSrPB-yzwAGofTXuklofK3DdKspciclTVzqbDjsk5UXfu2nTrC1agkhLyqlOfjhyqC~t1IXm-Vs2o7911k7KKLGjB4lmH508YJ7G9fLAUyjuB-wwwhejoWqvg7oWvqo4oIok8LG6ECR71C3dzCvIjY2QcrhoaazA9G4zcGMm6NKND-H4XY6tUWhpB~5GefB3YczOqMbHq4wi0O9MzBFrOJEOs3X4hwboKWANf7DT5PZKJZ5KorQPsYRSq0E3wSOsFCSsdVCKUGsAAAA/pipermail/i2p/2005-July/000826.html"
publicurl="http://dev.i2p.net/pipermail/i2p/2005-July/000826.html"
anonlogs="http://i2p/Nf3ab-ZFkmI-LyMt7GjgT-jfvZ3zKDl0L96pmGQXF1B82W2Bfjf0n7~288vafocjFLnQnVcmZd~-p0-Oolfo9aW2Rm-AhyqxnxyLlPBqGxsJBXjPhm1JBT4Ia8FB-VXt0BuY0fMKdAfWwN61-tj4zIcQWRxv3DFquwEf035K~Ra4SWOqiuJgTRJu7~o~DzHVljVgWIzwf8Z84cz0X33pv-mdG~~y0Bsc2qJVnYwjjR178YMcRSmNE0FVMcs6f17c6zqhMw-11qjKpY~EJfHYCx4lBWF37CD0obbWqTNUIbL~78vxqZRT3dgAgnLixog9nqTO-0Rh~NpVUZnoUi7fNR~awW5U3Cf7rU7nNEKKobLue78hjvRcWn7upHUF45QqTDuaM3yZa7OsjbcH-I909DOub2Q0Dno6vIwuA7yrysccN1sbnkwZbKlf4T6~iDdhaSLJd97QCyPOlbyUfYy9QLNExlRqKgNVJcMJRrIual~Lb1CLbnzt0uvobM57UpqSAAAA/meeting141"
publiclogs="http://www.i2p.net/meeting141" />
&#149;
2007-10-07: 0.6.1.30
<a href="http://dev.i2p/pipermail/i2p/2007-October/001356.html">released</a>
with
streaming lib, eepget, and i2psnark improvements, and a memory leak fix.
<br />
<!--
&#149;
2007-04-10:
<a href="http://dev.i2p/pipermail/i2p/2007-April/001343.html">status notes</a>
and
<a href="http://www.i2p/meeting206">meeting log</a>
<br />
-->
</i2p.news>

View File

@ -74,7 +74,7 @@ foo.xpi2p is a sud file containing the following:
*name (will be installed in this directory name)
For native plugins, you may want separate names in different packages -
foo-windows and foo-linux, for example
*key (172 B64 chars ending with '=')
*key (<a href="how_cryptography.html#DSA">DSA public key</a> as 172 B64 chars ending with '=')
*signer (yourname@mail.i2p recommended)
*version (must be in a format VersionComparator can parse, e.g. 1.2.3-4)