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

propagate from branch 'i2p.www' (head b9cbaa4a678064867b82132ba2012d03afc6c5b3)

Browse Source 
to branch 'i2p.www.revamp' (head 87d1d76279c3d3b2e34974e145c8d20f1e0d4f90)
This commit is contained in:
str4d
2013-12-25 21:53:56 +00:00
parent 4feb881994 3213c3e94e
commit 02fc43e866
6 changed files with 181 additions and 48 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -1,6 +1,6 @@
{% extends "global/layout.html" %}
{% block title %}{% trans %}Low-level Cryptography Details{% endtrans %}{% endblock %}
{% block lastupdated %}{% trans %}November 2013{% endtrans %}{% endblock %}
{% block lastupdated %}{% trans %}December 2013{% endtrans %}{% endblock %}
{% block accuratefor %}0.9.9{% endblock %}
{% block content %}
<p>{% trans -%}
@@ -139,19 +139,21 @@ or as a hexadecimal value:
Using 2 as the generator.
{%- endtrans %}</p>
<h3>{% trans %}Short Exponent{% endtrans %}</h3>
<p>{% trans commonstructures=site_url('docs/spec/common-structures'),
pdf='http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.14.5952&amp;rep=rep1&amp;type=pdf',
benchmarks=site_url('misc/benchmarks'),
oldbenchmarks='http://www.eskimo.com/~weidai/benchmarks.html' -%}
<h3><a name="exponent">{% trans %}Short Exponent{% endtrans %}</a></h3>
<p>{% trans commonstructures=site_url('docs/spec/common-structures') -%}
While the standard exponent size is 2048 bits (256 bytes) and the I2P
<a href="{{ commonstructures }}#type_PrivateKey">PrivateKey</a>
is a full 256 bytes,
is a full 256 bytes, in some cases
we use the short exponent size of 226 bits (28.25 bytes).
{%- endtrans %}</p>
<p>{% trans pdf='http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.14.5952&amp;rep=rep1&amp;type=pdf',
benchmarks=site_url('misc/benchmarks'),
oldbenchmarks='http://www.eskimo.com/~weidai/benchmarks.html' -%}
This should be safe for use with the Oakley primes, per
<a href="{{ pdf }}">On Diffie-Hellman Key Agreement with Short Exponents - van Oorschot, Weiner</a>
at EuroCrypt 96, and <a href="{{ benchmarks }}">crypto++'s benchmarks</a>.
Benchmarks originally at <code>{{ oldbenchmarks }}</code> (now dead),
Benchmarks originally at <a rel="nofollow" href="{{ oldbenchmarks }}">this link, now dead</a>,
rescued from <a href="http://www.archive.org/">the wayback machine</a>, dated Apr 23, 2008.
{%- endtrans %}</p>
@@ -164,6 +166,13 @@ Also, <a href="{{ book }}">Koshiba &amp; Kurosawa: Short Exponent Diffie-Hellman
The remainder of the PrivateKey is padded with zeroes.
{%- endtrans %}</p>
<p>{% trans -%}
Prior to release 0.9.8, all routers used the short exponent.
As of release 0.9.8, 64-bit x86 routers use a full 2048-bit exponent.
Other routers continue to use the short exponent due to concerns about processor load.
The transition to a longer exponent for these platforms is a topic for further study.
{%- endtrans %}</p>
<h4>{% trans %}Obsolescence{% endtrans %}</h4>
<p>{% trans -%}
The vulnerability of the network to an ElGamal attack and the impact of transitioning to a longer bit length is to be studied.

47
i2p2www/pages/site/docs/protocol/i2cp.html
View File

@@ -7,27 +7,25 @@
The I2P Client Protocol (I2CP) exposes a strong separation of concerns between
the router and any client that wishes to communicate over the network. It enables
secure and asynchronous messaging by sending and receiving messages over a
single TCP socket, yet never exposing any private keys and authenticating itself
to the router only through signatures. With I2CP, a client application tells the
single TCP socket.
With I2CP, a client application tells the
router who they are (their "destination"), what anonymity, reliability, and
latency tradeoffs to make, and where to send messages. In turn the router uses
I2CP to tell the client when any messages have arrived, and to request authorization
for some tunnels to be used.
{%- endtrans %}</p>
<p>{% trans url='http://docs.i2p-projekt.de/javadoc/net/i2p/client/package-summary.html' -%}
The protocol itself has only been implemented in Java, to provide the
<p>{% trans url='http://docs.i2p-projekt.de/javadoc/net/i2p/client/package-summary.html',
libi2cp='http://git.repo.i2p/w/libi2cp.git',
streaming=site_url('docs/api/streaming') -%}
The protocol itself is implemented in Java, to provide the
<a href="{{ url }}">Client SDK</a>.
This SDK is exposed in the i2p.jar package, which implements the client-side of I2CP.
Clients should never need to access the router.jar package, which contains the
router itself and the router-side of I2CP.
{%- endtrans %}</p>
<p>{% trans streaming=site_url('docs/api/streaming') -%}
While implementing the client side of I2CP in a non-Java language is certainly feasible,
a non-Java client would also have to implement the
There is also a <a href="{{ libi2cp }}">C library implementation</a>.
A non-Java client would also have to implement the
<a href="{{ streaming }}">streaming library</a> for TCP-style connections.
Together, implementing I2CP and the streaming library would be a sizable task.
{%- endtrans %}</p>
<p>{% trans streaming=site_url('docs/api/streaming'), datagrams=site_url('docs/spec/datagrams'),
@@ -64,6 +62,16 @@ Clients in the same JVM as the router pass messages directly to the router
through an internal JVM interface.
{%- endtrans %}</p>
<p>{% trans commonstructures=site_url('docs/spec/common-structures') -%}
The router also supports external connections over SSL.
While SSL is not the default, it is strongly recommended for any traffic that may
be exposed to the open Internet. The authorization user/password (if any), the
<a href="{{ commonstructures }}#type_PrivateKey">Private Key</a> and
<a href="{{ commonstructures }}#type_SigningPrivateKey">Signing Private Key</a> for the
<a href="{{ commonstructures }}#struct_Destination">Destination</a>
are all transmitted in-the-clear unless SSL is enabled.
{%- endtrans %}</p>
<h2>{% trans %}I2CP Protocol Specification{% endtrans %}</h2>
<p>{% trans i2cp=site_url('docs/spec/i2cp') -%}
Now on the <a href="{{ i2cp }}">I2CP Specification page</a>.
@@ -414,10 +422,12 @@ in the "unknown options" properties of the outbound tunnel pool's settings.
Note: Large quantity, length, or variance settings may cause significant performance or reliability problems.
{%- endtrans %}</p>
<p>{% trans -%}
<p>{% trans commonstructures=site_url('docs/spec/common-structures') -%}
Note: As of release 0.7.7, option names and values must use UTF-8 encoding.
This is primarily useful for nicknames.
Prior to that release, options with multi-byte characters were corrupted.
Since options are encoded in a <a href="{{ commonstructures }}#type_Mapping">Mapping</a>,
all option names and values are limited to 255 bytes (not characters) maximum.
{%- endtrans %}</p>
<p>{% trans -%}
@@ -643,21 +653,14 @@ specified by <a href="http://www.ietf.org/rfc/rfc1952.txt">RFC 1952</a>.
<h2 id="future">{% trans %}Future Work{% endtrans %}</h2>
<ul>
<li>{% trans -%}
Implement I2CP and the streaming library in another programming language.
{%- endtrans %}</li>
<li>{% trans -%}
Is the initial Get Date / Set Date handshake required?
{%- endtrans %}</li>
<li>{% trans -%}
The current authorization mechanism could be modified to use hashed passwords.
{%- endtrans %}</li>
<li>{% trans -%}
Private Keys are included in the Create Lease Set message,
are they really required? Revocation is unimplemented.
The Signing Private Keys is included in the Create Lease Set message,
it is not required. Revocation is unimplemented.
It should be replaced with random data or removed.
{%- endtrans %}</li>
<li>{% trans pdf1=url_for('static', filename='pdf/I2CP_spec.pdf'), pdf2=url_for('static', filename='pdf/datastructures.pdf') -%}
@@ -671,5 +674,7 @@ That document also references the
</ul>
<h2 id="links">See Also</h2>
<a href="http://git.repo.i2p/w/libi2cp.git">C library implementation</a>
{% endblock %}

12
i2p2www/pages/site/docs/spec/geoip.html
View File

@@ -1,7 +1,7 @@
{% extends "global/layout.html" %}
{% block title %}{% trans %}GeoIP File Specification{% endtrans %}{% endblock %}
{% block lastupdated %}{% trans %}May 2013{% endtrans %}{% endblock %}
{% block accuratefor %}0.9.6{% endblock %}
{% block lastupdated %}{% trans %}December 2013{% endtrans %}{% endblock %}
{% block accuratefor %}0.9.9{% endblock %}
{% block content %}
<h2>{% trans %}Overview{% endtrans %}</h2>
@@ -60,8 +60,8 @@ The file is gzipped. Ungzipped format:
Bytes 0-9: Magic number "I2PGeoIPv6"
Bytes 10-11: Version (0x0001)
Bytes 12-15 Options (0x00000000) (future use)
Bytes 16-23: Creation date (Java long)
Bytes 24-xx: Optional comment (UTF-8)
Bytes 16-23: Creation date (ms since 1970-01-01)
Bytes 24-xx: Optional comment (UTF-8) terminated by zero byte
Bytes xx-255: null padding
Bytes 256-: 18 byte records:
8 byte from (/64)
@@ -71,11 +71,11 @@ The file is gzipped. Ungzipped format:
<p>{% trans %}NOTES:{% endtrans %}</p>
<ul>
<li>Data must be sorted (SIGNED long twos complement), no overlap.
So the order is 8000:: ... FFFF:: 0000:: ... 7FFF::
So the order is 80000000 ... FFFFFFFF 00000000 ... 7FFFFFFF.
<li>
The GeoIPv6.java class contains a program to generate this format from
public sources such as the Maxmind GeoLite data.
<li>
This specification is preliminary; I2P does not yet support IPv6 GeoIP lookup.
IPv6 GeoIP lookup is supported as of release 0.9.8.
</ul>
{% endblock %}

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

@@ -1,6 +1,6 @@
{% extends "global/layout.html" %}
{% block title %}I2CP Specification{% endblock %}
{% block lastupdated %}November 2013{% endblock %}
{% block lastupdated %}December 2013{% endblock %}
{% block accuratefor %}0.9.9{% endblock %}
{% block content %}
<h1>I2P Control Protocol (I2CP) Specification</h1>
@@ -323,6 +323,20 @@ GetDateMessage
<td align=right>32
<td>&nbsp;
<tr><td>
<a href="#msg_HostLookup">
HostLookupMessage
</a>
<td align="center">C-&gt;R
<td align=right>38
<td align="center">0.9.10
<tr><td>
<a href="#msg_HostReply">
HostReplyMessage
</a>
<td align="center">R-&gt;C
<td align=right>39
<td align="center">0.9.10
<tr><td>
<a href="#msg_MessagePayload">
MessagePayloadMessage
</a>
@@ -455,7 +469,11 @@ As of release 0.7.2.
<h3 id="msg_CreateLeaseSet">Create Lease Set</h3>
<h4>Description</h4>
<p>
This message is sent in response to a RequestLeaseSetMessage and contains all
This message is sent in response to a
<a href="#msg_CreateLeaseSet">Create Lease Set Message</a>
or
<a href="#msg_CreateLeaseSet">Create Variable Lease Set Message</a>
and contains all
of the Lease structures that should be published to the I2NP Network Database.
Sent from Client to Router.
</p>
@@ -473,9 +491,9 @@ Sent from Client to Router.
<h4>Notes</h4>
<p>
The SigningPrivateKey matches the SigningPublicKey from within the
LeaseSet, as does the PrivateKey with the PublicKey. The Signing keys are
LeaseSet, as does the PrivateKey with the PublicKey. The Signing key is
necessary to allow the router to revoke the LeaseSet if the client goes offline,
and the normal keys are necessary for decrypting garlic routed messages. The
and the encryption key is necessary for decrypting garlic routed messages. The
LeaseSet granted may include Lease structures for tunnels pointing at another
router if the client is actively connected to multiple routers with Leases granted
to each.
@@ -532,6 +550,7 @@ The router responds with a <a href="#msg_DestReply">Dest Reply Message</a>.
As of release 0.7.
As of release 0.8.3, multiple outstanding lookups are supported,
and lookups are supported in both I2PSimpleSession and in standard sessions.
<a href="#msg_HostLookup">Host Lookup Message</a> is preferred as of release 0.9.10.
</p>
@@ -628,18 +647,111 @@ The router responds with a <a href="#msg_SetDate">Set Date Message</a>.
<h4>Contents</h4>
<ol><li>
I2CP Version <a href="{{ site_url('docs/spec/common-structures') }}#struct_String">String</a>
</li><li>
Authentication <a href="{{ site_url('docs/spec/common-structures') }}#type_Mapping">Mapping</a>
(optional, as of release 0.9.10)
</li></ol>
<h4>Notes</h4>
<p>
<ul><li>
Generally the first message sent by the client after sending the protocol version byte.
</li><li>
The version string is included as of release 0.8.7.
This is only useful if the client and router are not in the same JVM.
If it is not present, the client is version 0.8.6 or earlier.
</li><li>
Preliminary: As of release 0.9.10, the authentication
<a href="common_structures_spec#type_Mapping">Mapping</a>
may be included, with the keys i2cp.username and i2cp.password.
The Mapping need not be sorted as this message is not signed.
Prior to and including 0.9.10, authentication is included in the
<a href="#struct_SessionConfig">Session Config</a> Mapping, and
no authentication is enforced for GetDate, GetBandwidthLimits, or DestLookup.
The Get Date authentication will be enforced in a future release.
This is only useful outside router context.
This will be an incompatible change, but will only affect sessions outside
router context with authentication, which should be rare.
</li></ul>
</p>
<h3 id="msg_HostLookup">Host Lookup</h3>
<h4>Description</h4>
<p>
Sent from Client to Router.
The router responds with a <a href="#msg_HostReply">Host Reply Message</a>.
This replaces the <a href="#msg_DestLookup">Dest Lookup Message</a>
and adds a request ID, a timeout, and host name lookup support.
As it also supports Hash lookups, it may be used for all lookups if the router supports it.
For host name lookups, the router will query its context's naming service.
This is only useful if the client is outside the router's context.
Inside router context, the client should query the naming service itself,
which is much more efficient.
</p>
<h4>Contents</h4>
<ol><li>
4 byte <a href="common_structures_spec#type_Integer">Integer</a> request ID
</li><li>
4 byte <a href="common_structures_spec#type_Integer">Integer</a> timeout (ms)
</li><li>
1 byte <a href="common_structures_spec#type_Integer">Integer</a> request type
</li><li>
<a href="common_structures_spec#struct_Hash">SHA-256 Hash</a>
or
host name <a href="common_structures_spec#struct_String">String</a>
</li></ol>
<h4>Notes</h4>
<ul><li>
Preliminary. As of release 0.9.10.
Use <a href="#msg_DestLookup">Dest Lookup Message</a> for older routers.
</li><li>
The request ID will be returned in the <a href="#msg_HostReply">Host Reply Message</a>.
</li><li>
Timeout is useful for Hash lookups. Recommended minimum 10,000 (10 sec.).
In the future it may also be useful for remote naming service lookups.
The value may be not be honored for local host name lookups, which should be fast.
</li><li>
The request type is 0 for Hash and 1 for host name.
</li><li>
Base 32 host name lookup is supported but it is preferred to convert
it to a Hash first.
</ul>
<h3 id="msg_HostReply">Host Reply</h3>
<h4>Description</h4>
<p>
Sent from Router to Client in response to a
<a href="#msg_HostLookup">Host Lookup Message</a>.
</p>
<h4>Contents</h4>
<ol><li>
4 byte <a href="common_structures_spec#type_Integer">Integer</a> request ID
</li><li>
1 byte <a href="common_structures_spec#type_Integer">Integer</a> result code
</li><li>
<a href="common_structures_spec#struct_Destination">Destination</a>,
only present if result code is zero.
</li></ol>
<h4>Notes</h4>
<ul><li>
Preliminary. As of release 0.9.10.
See Host Lookup notes.
</li><li>
The request ID is that from the Host Lookup.
</li><li>
The result code is 0 for success, 1-255 for failure.
Only 1 is used for failure now, more specific failure codes may be defined in the future.
</ul>
<h3 id="msg_MessagePayload">Message Payload</h3>
<h4>Description</h4>
<p>
@@ -984,7 +1096,7 @@ i2cp.messageReliability=none for this message only.
<h3 id="msg_SendMessageExpires">Send Message Expires</h3>
<h4>Description</h4>
<p>
Sent from Client to Router. Same as Send Message Message, except includes an expiration.
Sent from Client to Router. Same as Send Message Message, except includes an expiration and options.
</p>
<h4>Contents</h4>
<ol><li>

13
i2p2www/pages/site/docs/spec/tunnel-message.html
View File

@@ -1,6 +1,6 @@
{% extends "global/layout.html" %}
{% block title %}Tunnel Message Specification{% endblock %}
{% block lastupdated %}November 2013{% endblock %}
{% block lastupdated %}December 2013{% endblock %}
{% block accuratefor %}0.9.9{% endblock %}
{% block content %}
<h1>Tunnel Message Specification</h1>
@@ -122,7 +122,7 @@ IV ::
Checksum ::
4 bytes
the first 4 bytes of the SHA256 hash of the remaining contents of the message concatenated with the IV
the first 4 bytes of the SHA256 hash of the contents of the message after the zero byte concatenated with the IV
Nonzero_padding ::
0 or more bytes
@@ -145,9 +145,14 @@ total size: 1028 Bytes
</pre>
<h4>Notes</h4>
<ul><li>
The padding, if any, must be before the instruction/message pairs.
There is no provision for padding at the end.
</li><li>
The checksum does NOT cover the padding or the zero byte.
</li></ul>
<p>Note that the padding, if any, must be before the instruction/message pairs.
there is no provision for padding at the end.</p>
<h2 id="delivery">Delivery Instructions</h2>

8
i2p2www/pages/site/docs/transport/ntcp.html
View File

@@ -119,16 +119,18 @@ The mapping between these steps and the messages sent between I2P routers,
is marked in bold.
{%- endtrans %}</p>
<ol>
<li>{% trans %}Alice generates a secret 226-bit integer x. She then calculates <code>X = g^x mod p</code>.{% endtrans %}</li>
<li>{% trans %}Alice generates a secret integer x. She then calculates <code>X = g^x mod p</code>.{% endtrans %}</li>
<li>{% trans %}Alice sends X to Bob <b>(Message 1)</b>.{% endtrans %}</li>
<li>{% trans %}Bob generates a secret 226-bit integer y. He then calculates <code>Y = g^y mod p</code>.{% endtrans %}</li>
<li>{% trans %}Bob generates a secret integer y. He then calculates <code>Y = g^y mod p</code>.{% endtrans %}</li>
<li>{% trans %}Bob sends Y to Alice.<b>(Message 2)</b>{% endtrans %}</li>
<li>{% trans %}Alice can now compute <code>sessionKey = Y^x mod p</code>.{% endtrans %}</li>
<li>{% trans %}Bob can now compute <code>sessionKey = X^y mod p</code>.{% endtrans %}</li>
<li>{% trans %}Both Alice and Bob now have a shared key <code>sessionKey = g^(x*y) mod p</code>.{% endtrans %}</li>
</ol>
<p>{% trans -%}
<p>{% trans crypto=site_url('docs/how/cryptography') -%}
The sessionKey is then used to exchange identities in <b>Message 3</b> and <b>Message 4</b>.
The exponent (x and y) length for the DH exchange is documented on the
<a href="{{ crypto }}#exponent">cryptography page</a>.
{%- endtrans %}</p>
<h4>{% trans %}Message 1 (Session Request){% endtrans %}</h4>