propagate from branch 'i2p.www' (head 1be3724265f45ffd0eb0af6d9dc869318b94be2f)

to branch 'i2p.www.revamp' (head 0e7878efa22d01668a4644e60c37108c87eb25f8)
This commit is contained in:
str4d
2013-06-11 12:43:33 +00:00
4 changed files with 47 additions and 11 deletions

View File

@ -88,7 +88,7 @@ network.
</tr>
<tr>
<td valign="top"><b>{% trans website=i2pconv('www.i2p2.i2p') %}<a href="http://{{ website }}/">Website</a> admin{% endtrans %}</b></td>
<td valign="top" style="color:blue">[{{ _('vacant') }}]</td>
<td valign="top">str4d</td>
<td valign="top"><i>{{ _('manage the public project website content') }}</i></td>
</tr>
<tr>
@ -103,7 +103,7 @@ network.
</tr>
<tr><td colspan="4"><hr /></td></tr>
<tr>
<td valign="top" rowspan="25"><b>{{ _('Dev') }}</b></td>
<td valign="top" rowspan="27"><b>{{ _('Dev') }}</b></td>
<td valign="top"><b>{{ _('Core Lead') }}</b></td>
<td valign="top">zzz</td>
<td valign="top"><i>{{ _('lead dev for the SDK and router') }}</i></td>
@ -168,6 +168,11 @@ network.
<td valign="top" style="color:blue">[{{ _('vacant') }}]</td>
<td valign="top"><i>{{ _('SAM maintainer') }}</i></td>
</tr>
<tr>
<td valign="top"><b>{{ _('I2PCPP lead') }}</b></td>
<td valign="top">orion</td>
<td valign="top"><i>{{ _('C++ Router') }}</i></td>
</tr>
<tr>
<td valign="top" rowspan="8"><b>{{ _('Console Translations') }}</b></td>
<td valign="top">walking</td>
@ -202,7 +207,7 @@ network.
<td valign="top"><i>{{ _('Other languages') }}</i></td>
</tr>
<tr>
<td valign="top" rowspan="4"><b>{{ _('Contributors') }}</b></td>
<td valign="top" rowspan="5"><b>{{ _('Contributors') }}</b></td>
<td valign="top">cervantes</td>
<td valign="top"><i>{{ _('fire2pe dev, console enhancements') }}</i></td>
</tr>
@ -214,6 +219,10 @@ network.
<td valign="top">KillYourTV</td>
<td valign="top"><i>{{ _('Debian/Ubuntu Packager and PPA maintainer') }}</i></td>
</tr>
<tr>
<td valign="top">str4d</td>
<td valign="top"><i>{{ _('Routerconsole backend and UI work, website revamp, unit tests work') }}</i></td>
</tr>
<tr style="color:blue">
<td valign="top">[{{ _('vacant') }}]</td>

View File

@ -1,7 +1,7 @@
{% extends "global/layout.html" %}
{% block title %}{% trans %}Common structure Specification{% endtrans %}{% endblock %}
{% block lastupdated %}{% trans %}March 2012{% endtrans %}{% endblock %}
{% block accuratefor %}0.8.13{% endblock %}
{% block lastupdated %}{% trans %}June 2013{% endtrans %}{% endblock %}
{% block accuratefor %}0.9.6{% endblock %}
{% block content %}
<h1>{% trans %}Data types Specification{% endtrans %}</h1>
<p>{% trans i2np=site_url('docs/protocol/i2np'),
@ -546,6 +546,19 @@ The signature may be verified using the signing public key of the destination.
The signing_key is currently unused. It was intended for LeaseSet revocation, which is unimplemented.
It is currently generated anew at every router startup, it is not persistent.
{%- endtrans %}</li>
<li>{% trans -%}
The earliest expiration of all the Leases is treated as the timestamp or version of the LeaseSet.
Routers will generally not accept a store of a LeaseSet unless it is "newer" than the current one.
Take care when publishing a new LeaseSet where the oldest Lease is the same as the oldest Lease
in the previous LeaseSet. The publishing router should generally increment the expiration
of the oldest Lease by at least 1 ms in that case.
{%- endtrans %}</li>
<li>{% trans -%}
Prior to release 0.9.7, when included in a DatabaseStore Message sent by the originating router,
the router set all the published leases' expirations to the same value, that of the
earliest lease. As of release 0.9.7, the router publishes the actual lease expiration for each lease.
This is an implementation detail and not part of the structures specification.
{%- endtrans %}</li>
</ul>
<h4><a href="http://docs.i2p-projekt.de/javadoc/net/i2p/data/LeaseSet.html">Javadoc</a></h4>

View File

@ -275,6 +275,14 @@ The two padding bytes from the block (the zero bytes at locations 0 and 257) are
{% highlight %}
unencrypted:
+----+----+----+----+----+----+----+----+
| |
+ +
| |
+ SHA-256 Hash of following bytes +
| |
+ +
| |
+----+----+----+----+----+----+----+----+
| random data... |
~ ~
| |
@ -285,8 +293,9 @@ unencrypted:
<h4>Definition</h4>
{% highlight %}
unencrypted:
bytes 0-526: random data
byte 527 : reply
bytes 0-31 : SHA-256 Hash of bytes 32-527
bytes 32-526 : random data
byte 527 : reply
encrypted:
bytes 0-527: AES-encrypted record(note: same size as BuildRequestRecord)
@ -297,7 +306,7 @@ total length: 528
<h4>Notes</h4>
<ul><li>
The first 527 bytes could, in the future, be used to return congestion or peer connectivity information
The random data field could, in the future, be used to return congestion or peer connectivity information
back to the requestor.
</li><li>
See the <a href="{{ site_url('docs/spec/tunnel-creation') }}">tunnel creation specification</a> for details on the reply field.

View File

@ -166,13 +166,18 @@ uses TUNNEL_REJECT_BANDWIDTH for almost all rejections.
<p>
The reply is encrypted with the AES session
key delivered to it in the encrypted block, padded with 527 bytes of random data
key delivered to it in the encrypted block, padded with 495 bytes of random data
to reach the full record size.
The padding is placed before the status byte:
</p><pre>
AES-256-CBC(SHA-256(padding+status) + padding + status, key, IV)</pre>
AES-256-CBC(SHA-256(padding+status) + padding + status, key, IV)
bytes 0-31 : SHA-256 of bytes 32-527
bytes 32-526 : Random padding
byte 527 : Reply value
</pre>
This is also described in the
<a href="{{ site_url('docs/spec/i2np') }}#msg_TunnelBuildReply">I2NP spec</a>.
<a href="{{ site_url('docs/spec/i2np') }}#struct_BuildResponseRecord">I2NP spec</a>.
<h3 id="tunnelCreate.requestPreparation">Tunnel Build Message Preparation</h3>