kytv/I2P_Website
1
0
Fork 0
forked from I2P_Developers/i2p.www
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

updates

Browse Source
This commit is contained in:
zzz
2014-03-23 14:16:19 +00:00
parent 0bb9aad087
commit 1b10f04b67
4 changed files with 60 additions and 33 deletions
Download Patch File Download Diff File Expand all files Collapse all files

27
i2p2www/pages/site/docs/how/cryptography.html
View File

@@ -1,7 +1,7 @@
{% extends "global/layout.html" %}
{% block title %}{% trans %}Low-level Cryptography Details{% endtrans %}{% endblock %}
{% block lastupdated %}{% trans %}December 2013{% endtrans %}{% endblock %}
{% block accuratefor %}0.9.9{% endblock %}
{% block lastupdated %}{% trans %}March 2014{% endtrans %}{% endblock %}
{% block accuratefor %}0.9.12{% endblock %}
{% block content %}
<p>{% trans -%}
This page specifies the low-level details of the cryptography in I2P.
@@ -363,10 +363,6 @@ As such, we do not know if the prime chosen is a 'strong prime'.
If a larger prime is chosen for future purposes, this should be a strong prime, and we will document the construction process.
{%- endtrans %}</p>
<p>{% trans -%}
The vulnerability of the network to a DSA attack and the impact of transitioning to longer keys is to be studied.
It may be quite difficult to make any change backward-compatible.
{%- endtrans %}</p>
<h4>{% trans %}References{% endtrans %}</h4>
<ul>
@@ -381,6 +377,25 @@ It may be quite difficult to make any change backward-compatible.
</ul>
<h2>{% trans %}New Signature Algorithms{% endtrans %}</h2>
<p>{% trans -%}
As of release 0.9.12, the router supports additional signature algorithms that are more secure than 1024-bit DSA.
The first usage is for Destinations; support for Router Identities will be added in a future release.
Support for migrating existing Destinations from old to new signatures will be added in a future release.
The supported signature types are as follows. Additional signature types will be added in future releases.
{%- endtrans %}</p>
<ul>
<li>ECDSA-SHA256-P256</li>
<li>ECDSA-SHA384-P384</li>
<li>ECDSA-SHA512-P521</li>
<li>RSA-SHA256-2048</li>
<li>RSA-SHA384-3072</li>
<li>RSA-SHA512-4096</li>
</ul>
<H2><a name="SHA256">SHA256</a></H2>
<p>{% trans code='https://github.com/i2p/i2p.i2p/tree/master/core/java/src/net/i2p/crypto/SHA256Generator.java' -%}

31
i2p2www/pages/site/docs/how/elgamal-aes.html
View File

@@ -1,7 +1,7 @@
{% extends "global/layout.html" %}
{% block title %}{% trans %}ElGamal/AES + SessionTag Encryption{% endtrans %}{% endblock %}
{% block lastupdated %}{% trans %}February 2011{% endtrans %}{% endblock %}
{% block accuratefor %}0.8.3{% endblock %}
{% block lastupdated %}{% trans %}March 2014{% endtrans %}{% endblock %}
{% block accuratefor %}0.9.12{% endblock %}
{% block content %}
<h2>{% trans %}Overview{% endtrans %}</h2>
<p>{% trans -%}
@@ -328,6 +328,18 @@ If the tag is not found, the message is assumed to be a <a href="#new">New Sessi
<h2 id="config">{% trans %}Session Tag Configuration Options{% endtrans %}</h2>
<p>{% trans i2cp=site_url('docs/protocol/i2cp#options') i2cpp=site_url('docs/spec/i2cp#msg_SendMessageExpires') -%}
As of release 0.9.2, the client may configure the default number of Session Tags to send
and the low tag threshold for the current session.
For brief streaming connections or datagrams, these options may be used to significantly reduce bandwidth.
See the <a href="{{ i2cp }}">I2CP options specification</a> for details.
The session settings may also be overridden on a per-message basis.
See the <a href="{{ i2cpp }}">I2CP Send Message Expires specification</a> for details.
{%- endtrans %}</p>
<h2 id="future">{% trans %}Future Work{% endtrans %}</h2>
<p>{% trans -%}
There are many possible areas to tune the Session Key Manager's algorithms;
@@ -335,21 +347,6 @@ some may interact with the streaming library behavior, or have significant
impact on overall performance.
{%- endtrans %}</p>
<ul>
<li>{% trans -%}
Delivery of too many tags at one time may impose substantial overhead for brief streaming connections
or datagrams, and increase the chance of message loss.
We currently deliver 40 tags at a time (1280 bytes).
32 (1024 bytes) may be better for tunnel fragmentation.
{%- endtrans %}</li>
<li>{% trans -%}
A few tags could be delivered in each of several messages, or lots of tags all at once.
{%- endtrans %}</li>
<li>{% trans -%}
It is also important to study and tune
the low-tag thresholds at which more tags are sent.
{%- endtrans %}</li>
<li>{% trans -%}
The number of tags delivered could depend on message size, keeping in mind

18
i2p2www/pages/site/docs/how/garlic-routing.html
View File

@@ -1,7 +1,7 @@
{% extends "global/layout.html" %}
{% block title %}{% trans %}Garlic Routing{% endtrans %}{% endblock %}
{% block lastupdated %}{% trans %}August 2010{% endtrans %}{% endblock %}
{% block accuratefor %}0.8{% endblock %}
{% block lastupdated %}{% trans %}March 2014{% endtrans %}{% endblock %}
{% block accuratefor %}0.9.12{% endblock %}
{% block content %}
<h2>{% trans %}Garlic Routing and "Garlic" Terminology{% endtrans %}</h2>
<p>{% trans -%}
@@ -210,11 +210,16 @@ and all LeaseSets would have to be published to the network database, as explain
{%- endtrans %}</li>
</ol>
<p>{% trans commonstructures=site_url('docs/spec/common-structures') -%}
In the current implementation, the Delivery Status and Database Store Messages
<p>{% trans commonstructures=site_url('docs/spec/common-structures') i2cp=site_url('docs/protocol/i2cp#options') i2cpp=site_url('docs/spec/i2cp#msg_SendMessageExpires') -%}
By default, the Delivery Status and Database Store Messages
are bundled when the local LeaseSet changes, when additional
<a href="{{ commonstructures }}#type_SessionTag">Session Tags</a>
are delivered, or if the messages have not been bundled in the previous minute.
As of release 0.9.2, the client may configure the default number of Session Tags to send
and the low tag threshold for the current session.
See the <a href="{{ i2cp }}">I2CP options specification</a> for details.
The session settings may also be overridden on a per-message basis.
See the <a href="{{ i2cpp }}">I2CP Send Message Expires specification</a> for details.
{%- endtrans %}</p>
<p>{% trans -%}
@@ -222,6 +227,11 @@ Obviously, the additional messages are currently bundled for specific purposes,
and not part of a general-purpose routing scheme.
{%- endtrans %}</p>
<p>{% trans -%}
As of release 0.9.12, the Delivery Status Message is wrapped in another Garlic Message
by the originator so that the contents are encrypted and not visible to routers on the return path.
{%- endtrans %}</p>
<h3>{% trans %}Storage to the Floodfill Network Database{% endtrans %}</h3>
<p>{% trans netdb=site_url('docs/how/network-database'),

17
i2p2www/pages/site/docs/spec/i2cp.html
View File

@@ -1,7 +1,7 @@
{% extends "global/layout.html" %}
{% block title %}I2CP Specification{% endblock %}
{% block lastupdated %}January 2014{% endblock %}
{% block accuratefor %}0.9.9{% endblock %}
{% block lastupdated %}March 2014{% endblock %}
{% block accuratefor %}0.9.12{% endblock %}
{% block content %}
<h2>Overview</h2>
<p>
@@ -23,7 +23,7 @@ More information is on the <a href="{{ site_url('docs/protocol/i2cp') }}">I2CP O
<p>
The protocol was designed to handle multiple "sessions", each with a 2-byte session ID,
over a single TCP connection.
This does not appear to be fully implemented.
This is not fully implemented.
Do not attempt to use multiple sessions on a single I2CP connection.
</p>
@@ -44,11 +44,18 @@ I2CP connection.
<h2>Example Message Sequences</h2>
<p>
Note: The examples below do not show the Protocol Byte (0x2a) that must be
sent from the client to the router when first connecting.
More information about connection initialization is
on the <a href="{{ site_url('docs/protocol/i2cp') }}">I2CP Overview page</a>.
</p>
<h3>Standard Session Establish</h3>
{% highlight %}
Client Router
---------------------> Protocol Byte (0x2a)
---------------------> Get Date Message
Set Date Message <---------------------
---------------------> Create Session Message
@@ -62,7 +69,6 @@ Request LeaseSet Message <---------------------
{% highlight %}
Client Router
---------------------> Protocol Byte (0x2a)
---------------------> Get Bandwidth Limits Message
Bandwidth Limits Message <---------------------
{% endhighlight %}
@@ -73,7 +79,6 @@ Bandwidth Limits Message <---------------------
{% highlight %}
Client Router
---------------------> Protocol Byte (0x2a)
---------------------> Dest Lookup Message
Dest Reply Message <---------------------
{% endhighlight %}