diff --git a/router/doc/tunnel.html b/router/doc/tunnel.html index a7dc68629..fd1264805 100644 --- a/router/doc/tunnel.html +++ b/router/doc/tunnel.html @@ -1,4 +1,4 @@ -$Id: tunnel.html,v 1.8 2005/01/15 01:43:35 jrandom Exp $ +$Id: tunnel.html,v 1.9 2005/01/15 19:08:14 jrandom Exp $ 
 1) Tunnel overview
 2) Tunnel operation
@@ -146,8 +146,8 @@ verify the integrity of the checksum block.  The specific details follow.

 
 
The encryption used is such that decryption
 merely requires running over the data with AES in CBC mode, calculating the
-SHA256 of a certain fixed portion of the message (bytes 16 through $size-288),
-and searching for that hash in the checksum block.  There is a fixed number 
+SHA256 of a certain fixed portion of the message (bytes 16 through $size-144),
+and searching for the first 16 bytes of that hash in the checksum block.  There is a fixed number 
 of hops defined (8 peers) so that we can verify the message
 without either leaking the position in the tunnel or having the message 
 continually "shrink" as layers are peeled off.  For tunnels shorter than 8
@@ -239,7 +239,7 @@ To visualize this a bit:

 
 
 
In the above, P[7] is the same as the original data being passed through the
-tunnel (the preprocessed messages), and V[7] is the SHA256 of eH[0-7] as seen on
+tunnel (the preprocessed messages), and V[7] is the first 16 bytes of the SHA256 of eH[0-7] as seen on
 peer7 after decryption.  For
 cells in the matrix "higher up" than the hash, their value is derived by encrypting
 the cell below it with the key for the peer below it, using the end of the column 
@@ -268,8 +268,8 @@ peer who is the first hop (usually the peer1.recv row) and forward that entirely
 
 
When a participant in a tunnel receives a message, they decrypt a layer with their
 tunnel key using AES256 in CBC mode with the first 16 bytes as the IV.  They then
-calculate the hash of what they see as the payload (bytes 16 through $size-288) and
-search for that hash within the decrypted checksum block.  If no match is found, the
+calculate the hash of what they see as the payload (bytes 16 through $size-144) and
+search for that first 16 bytes of that hash within the decrypted checksum block.  If no match is found, the
 message is discarded.  Otherwise, the IV is updated by decrypting it, XORing that value
 with the IV_WHITENER, and replacing it with the first 16 bytes of its hash.  The 
 resulting message is then forwarded on to the next peer for processing.

@@ -287,7 +287,7 @@ contained in the tunnel.

 
When a message reaches the tunnel endpoint, they decrypts and verifies it like
 a normal participant.  If the checksum block has a valid match, the endpoint then
 computes the hash of the checksum block itself (as seen after decryption) and compares
-that to the decrypted verification hash (the last 32 bytes).  If that verification
+that to the decrypted verification hash (the last 16 bytes).  If that verification
 hash does not match, the endpoint takes note of the tagging attempt by one of the
 tunnel participants and perhaps discards the message.

 
@@ -328,7 +328,7 @@ and handling fragmentation will not immediately be implemented.

 
 
One alternative to the above process is to remove the checksum block
 completely and replace the verification hash with a plain hash of the payload.
-This would simplify processing at the tunnel gateway and save 256 bytes of
+This would simplify processing at the tunnel gateway and save 144 bytes of
 bandwidth at each hop.  On the other hand, attackers within the tunnel could
 trivially adjust the message size to one which is easily traceable by 
 colluding external observers in addition to later tunnel participants.  The
@@ -344,7 +344,7 @@ there are three alternatives that can be explored: