$Id: tunnel-alt.html,v 1.2 2005/01/18 11:01:55 jrandom Exp $
+$Id: tunnel-alt.html,v 1.3 2005/01/18 11:21:12 jrandom Exp $
1) Tunnel overview 2) Tunnel operation @@ -140,7 +140,7 @@ preprocessed payload must be padded to a multiple of 16 bytes.2.2) Gateway processing
After the preprocessing of messages into a padded payload, the gateway builds -a random 4 byte preIV value, iteratively encrypting it and the tunnel message as +a random 16 byte preIV value, iteratively encrypting it and the tunnel message as necessary, selects the next message ID from its outbound PRNG, and forwards the tuple {tunnelID, messageID, preIV, encrypted tunnel message} to the next hop.
@@ -155,13 +155,10 @@ the initial preprocessed data.The preIV postprocessing should be a secure transform of the received value with sufficient expansion to provide the full 16 byte IV necessary for AES256. -What transform should be used - HMAC-SHA256(preIV, layerKey), using bytes -0:15 as the IV, passing on bytes 16-19 as the next step's preIV? Should +What transform should be used - E(preIV, layerIVKey), where we deliver an additional postprocessing layer key to each peer during the tunnel creation to reduce the potential exposure -of the layerKey? Should we replace the 4 byte preIV with a full 16 byte preIV -(even though 4 bytes will likely provide a sufficient keyspace in which to -operate, as a single tunnel pumping 100KBps would only use 60,000 IVs)?
+of the layerKey?2.3) Participant processing