I2P_Developers/i2p.itoopie
3
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity

we want to use E on the preIV, not HMAC - must be invertible (duh, thanks Connelly)

Browse Source 
adjusted preIV size accordingly, and definitely use a delivered layerIVKey
This commit is contained in:
jrandom
2005-01-19 06:24:25 +00:00
committed by zzz
parent a65e6c888c
commit f3b0e0cfc7
1 changed files with 4 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files

11
router/doc/tunnel-alt.html
View File

@ -1,4 +1,4 @@
<code>$Id: tunnel-alt.html,v 1.2 2005/01/18 11:01:55 jrandom Exp $</code> <code>$Id: tunnel-alt.html,v 1.3 2005/01/18 11:21:12 jrandom Exp $</code>
<pre> <pre>
1) <a href="#tunnel.overview">Tunnel overview</a> 1) <a href="#tunnel.overview">Tunnel overview</a>
2) <a href="#tunnel.operation">Tunnel operation</a> 2) <a href="#tunnel.operation">Tunnel operation</a>
@ -140,7 +140,7 @@ preprocessed payload must be padded to a multiple of 16 bytes.</p>
<h3>2.2) <a name="tunnel.gateway">Gateway processing</a></h3> <h3>2.2) <a name="tunnel.gateway">Gateway processing</a></h3>
<p>After the preprocessing of messages into a padded payload, the gateway builds <p>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 necessary, selects the next message ID from its outbound PRNG, and forwards the tuple
{tunnelID, messageID, preIV, encrypted tunnel message} to the next hop.</p> {tunnelID, messageID, preIV, encrypted tunnel message} to the next hop.</p>
@ -155,13 +155,10 @@ the initial preprocessed data.</p>
<p>The preIV postprocessing should be a secure transform of the received value <p>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. with sufficient expansion to provide the full 16 byte IV necessary for AES256.
<i>What transform should be used - HMAC-SHA256(preIV, layerKey), using bytes <i>What transform should be used - E(preIV, layerIVKey), where
0:15 as the IV, passing on bytes 16-19 as the next step's preIV? Should
we deliver an additional postprocessing layer key to each peer during the we deliver an additional postprocessing layer key to each peer during the
<a href="#tunnel.request">tunnel creation</a> to reduce the potential exposure <a href="#tunnel.request">tunnel creation</a> to reduce the potential exposure
of the layerKey? Should we replace the 4 byte preIV with a full 16 byte preIV of the layerKey?</i></p>
(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)?</i></p>
<h3>2.3) <a name="tunnel.participant">Participant processing</a></h3> <h3>2.3) <a name="tunnel.participant">Participant processing</a></h3>