* 2005-07-27 0.6 released

2005-07-27  jrandom
    * Enabled SSU as the default top priority transport, adjusting the
      config.jsp page accordingly.
    * Add verification fields to the SSU and TCP connection negotiation (not
      compatible with previous builds)
    * Enable the backwards incompatible tunnel crypto change as documented in
      tunnel-alt.html (have each hop encrypt the received IV before using it,
      then encrypt it again before sending it on)
    * Disable the I2CP encryption, leaving in place the end to end garlic
      encryption (another backwards incompatible change)
    * Adjust the protocol versions on the TCP and SSU transports so that they
      won't talk to older routers.
    * Fix up the config stats handling again
    * Fix a rare off-by-one in the SSU fragmentation
    * Reduce some unnecessary netDb resending by inluding the peers queried
      successfully in the store redundancy count.

router/doc/tunnel-alt.html

@@ -1,4 +1,4 @@
-<code>$Id: tunnel-alt.html,v 1.7 2005/02/16 19:48:18 jrandom Exp $</code>
+<code>$Id: tunnel-alt.html,v 1.8 2005/07/07 16:16:57 jrandom Exp $</code>
 <pre>
 1) <a href="#tunnel.overview">Tunnel overview</a>
 2) <a href="#tunnel.operation">Tunnel operation</a>
@@ -173,9 +173,12 @@ the initial preprocessed data.</p>
 the same previous hop as before (initialized when the first message comes through
 the tunnel).  If the previous peer is a different router, or if the message has
 already been seen, the message is dropped.  The participant then encrypts the 
-data with AES256/CBC using the participant's layer key and the received IV, 
-updates the IV by encrypting it with AES256/ECB using the participant's IV key,
-then forwards the tuple {nextTunnelId, nextIV, encryptedData} to the next hop.</p>
+received IV with AES256/ECB using their IV key to determine the current IV, uses 
+that IV with the participant's layer key to encrypt the data, encrypts the 
+current IV with AES256/ECB using their IV key again, then forwards the tuple 
+{nextTunnelId, nextIV, encryptedData} to the next hop.  This double encryption
+of the IV (both before and after use) help address a certain class of
+confirmation attacks.</p>
 
 <p>Duplicate message detection is handled by a decaying Bloom filter on message
 IVs.  Each router maintains a single Bloom filter to contain the XOR of the IV and

router/doc/udp.html

@@ -1,4 +1,4 @@
-<code>$Id: udp.html,v 1.12 2005/04/09 18:15:53 jrandom Exp $</code>
+<code>$Id: udp.html,v 1.13 2005/05/01 15:08:08 jrandom Exp $</code>
 
 <h1>Secure Semireliable UDP (SSU)</h1>
 <b>DRAFT</b>
@@ -141,7 +141,7 @@ around briefly, to address packet loss and reordering.</p>
         <li>4 byte timestamp (seconds from the epoch) for use in the DSA 
             signature</li>
         <li>40 byte DSA signature of the critical exchanged data 
-            (Alice's IP + Alice's port + Bob's IP + Bob's port + Alice's
+            (X + Y + Alice's IP + Alice's port + Bob's IP + Bob's port + Alice's
             new relay tag + Bob's signed on time), encrypted with another 
             layer of encryption using the negotiated sessionKey.  The IV 
             is reused here.</li>
@@ -197,7 +197,7 @@ bits 4-7: total identity fragments</pre></li>
         <li>on the last identity fragment, the signed on time is
             included after the identity fragment, and the last 40 
             bytes contain the DSA signature of the critical exchanged 
-            data (Alice's IP + Alice's port + Bob's IP + Bob's port
+            data (X + Y + Alice's IP + Alice's port + Bob's IP + Bob's port
             + Alice's new relay key + Alice's signed on time)</li>
         </ul></td></tr>
 <tr><td align="right" valign="top"><b>Key used:</b></td>