- Crypto, NTCP:

Short exponent updates for 0.9.8
- I2CP:
  Updates re: SSL, C library	
  Don't claim we never send private keys over I2CP
  Future work updates

www.i2p2/pages/how_cryptography.html

@@ -2,7 +2,7 @@
 {% block title %}Low-level Cryptography Details{% endblock %}
 {% block content %}
 <p>
-Updated November 2013, current as of router version 0.9.9
+Updated December 2013, current as of router version 0.9.9
 <p>
 This page specifies the low-level details of the cryptography in I2P.
 <p>
@@ -121,11 +121,12 @@ or as a hexadecimal value:
 </PRE>
 <p>
 Using 2 as the generator.
-<h3>Short Exponent</h3>
+<h3><a name="exponent">Short Exponent</a></h3>
 While the standard exponent size is 2048 bits (256 bytes) and the I2P
 <a href="common_structures_spec.html#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).
+<p>
 This should be safe for use with the Oakley primes,
 per
 <a href="http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.14.5952&amp;rep=rep1&amp;type=pdf">
@@ -143,6 +144,12 @@ Koshiba &amp; Kurosawa: Short Exponent Diffie-Hellman Problems</a> (PKC 2004, LN
 apparently supports this, according to
 <a href="http://groups.google.com/group/sci.crypt/browse_thread/thread/1855a5efa7416677/339fa2f945cc9ba0#339fa2f945cc9ba0">this sci.crypt thread</a>.
 The remainder of the PrivateKey is padded with zeroes.
+<p>
+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.
+
 
 <H4>Obsolescence</H4>
 <p>

www.i2p2/pages/i2cp.html

@@ -6,8 +6,8 @@ Updated December 2013, current as of router version 0.9.9
 <p>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
@@ -15,18 +15,15 @@ for some tunnels to be used.
 </p>
 
 <p>
-The protocol itself has only been implemented in Java, to provide the
+The protocol itself is implemented in Java, to provide the
 <a href="http://docs.i2p-projekt.de/javadoc/net/i2p/client/package-summary.html">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.
-</p>
-
-<p>
-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="http://git.repo.i2p/w/libi2cp.git">C library implementation</a>.
+A non-Java client would also have to implement the
 <a href="streaming.html">streaming library</a> for TCP-style connections.
-Together, implementing I2CP and the streaming library would be a sizable task.
 </p>
 
 <p>
@@ -55,6 +52,14 @@ By default, the router binds to address 127.0.0.1. To bind to 0.0.0.0, set the
 router advanced configuration option <tt>i2cp.tcp.bindAllInterfaces=true</tt> and restart.
 Clients in the same JVM as the router pass messages directly to the router
 through an internal JVM interface.
+</p><p>
+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="common_structures_spec#type_PrivateKey">Private Key</a> and
+<a href="common_structures_spec#type_SigningPrivateKey">Signing Private Key</a> for the
+<a href="common_structures_spec#struct_Destination">Destination</a>
+are all transmitted in-the-clear unless SSL is enabled.
 </p>
 
 <h2>I2CP Protocol Specification</h2>
@@ -231,14 +236,11 @@ specified by <a href="http://www.ietf.org/rfc/rfc1952.txt">RFC 1952</a>.
 
 <h2 id="future">Future Work</h2>
 <ul><li>
-Implement I2CP and the streaming library in another programming language.
-</li><li>
-Is the initial Get Date / Set Date handshake required?
-</li><li>
 The current authorization mechanism could be modified to use hashed passwords.
 </li><li>
-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.
 </li><li>
 Some improvements may be able to use messages previously defined but not implemented.
 For reference, here is the
@@ -249,5 +251,7 @@ That document also references the
 </li></ul>
 
 
+<h2 id="links">See Also</h2>
+<a href="http://git.repo.i2p/w/libi2cp.git">C library implementation</a>
 
 {% endblock %}

www.i2p2/pages/ntcp.html

@@ -114,11 +114,11 @@ The DH key exchange consists of a number of steps, displayed below.
 The mapping between these steps and the messages sent between I2P routers,
 is marked in bold.
   <ol>
-    <li>Alice generates a secret 226-bit integer x.
+    <li>Alice generates a secret integer x.
         She then calculates X = g^x mod p.
     </li>
     <li>Alice sends X to Bob <b>(Message 1)</b>.</li>
-    <li>Bob generates a secret 226-bit integer y.
+    <li>Bob generates a secret integer y.
         He then calculates Y = g^y mod p.</li>
     <li>Bob sends Y to Alice.<b>(Message 2)</b></li>
     <li>Alice can now compute sessionKey = Y^x mod p.</li>
@@ -126,6 +126,8 @@ is marked in bold.
     <li>Both Alice and Bob now have a shared key sessionKey = g^(x*y) mod p.</li>
   </ol>
 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="how_cryptography.html#exponent">cryptography page</a>.
 </p>
 
 <h4>Message 1 (Session Request)</h4>