[i2p] Tunnel cryptography for I2P 0.5 (corrected typo)

barnesc at engr.orst.edu barnesc at engr.orst.edu
Mon Jan 17 22:15:33 PST 2005

Citizens of I2P,

The following is a discussion of tunnel cryptography plans for
I2P 0.5.  There are two options; one will be chosen.

[1] and [2] offer more complete discussion of these plans.  Note that
the cryptographic methods discussed in [2] are incomplete.  They are
complete in this message.

 - Connelly

Tunnel cryptography for I2P 0.5

Currently when I2P 0.4.x passes an (end-to-end encrypted) message M
down a tunnel, it is easy for two attackers in different locations of
the tunnel to observe the same message M.  This makes I2P highly
vulnerable to the predecessor attack.

Can this situation be improved?

The best implementations we currently know of fit in two categories,
and use symmetric cryptography.  The categories are:

1. The inbound tunnel gateway knows all symmetric private keys used by
   other hops in the tunnel.  The outbound tunnel endpoint knows only
   its own symmetric private key.  Messages are checksummed to prevent

   Pros: Tagging attacks are defeated.
   Cons: Attacking an N-length inbound tunnel won't be much harder
         than attacking a 2-length inbound tunnel.  If the gateway is
         malicious, then the gateway can collude with a malicious hop
         at any other position in the tunnel; thus the two can
         identify that they are in the same tunnel.
         => Predecessor attack.

   This was one plan by jrandom.  A proposed implementation is given
   [1].  This implementation could be subject to tagging attacks in
   certain cases.  I have a revised scheme in mind that may be safe
   from these attacks.

2. The inbound tunnel gateway has only its own symmetric private key.
   Likewise for the outbound tunnel endpoint.  No messages are
   checksummed in the tunnel.  All messages have the same size in
   the tunnel to prevent tagging.  Synchronized PRNGs may be used as
   described at [2] to help prevent tunnel loops (where an attacker
   DoSes several peers by placing them a "looped" tunnel).

   Pros: Attacking an N-length inbound tunnel is not easy (one must do
         timing or message counting analysis).
   Cons: Tagging (this can be done, but not detected), tunnel loops
         can be created, extra packets can be generated within the

   This plan was originally drafted in [2] based on a discussion by
   jrandom and ???.  However, this document has pending modifications
   because it is not a complete cryptosystem.  A full implementation
   plan is appended to the end of this document, based on a discussion
   by jrandom and Connelly.

One of these options will (presumably) be used in I2P 0.5.  If you
discover a flaw or improvement for either implementation, let us
know.  If you have other useful input, drop by IRC or post a message
to this maillist.

We have not found a complete cryptographic analysis for either option.
We are using standard cryptographic primitives and methods when

Option 2 is known as a "non-checksummed tunnel."

Proposed Implementation (non-checksummed tunnels)

Leaving out the PRNGs.

As part of a tunnel, we receive and send messages which contain
{preIV, payload}.  Here preIV is a single block from which the
initialization vector (IV) is derived, and payload is a sequence of
blocks containing the message which is being delivered down the
tunnel.  Here 'block' is any string which the symmetric block cipher
can operate on.  The preIV and the payload are successively wrapped
in layers of encryption as a message travels down an inbound tunnel,
and messages are successively unwrapped for outbound tunnels.

Encryption at hop i:
1. Drop packet (with warning) if we've seen preIV before
   for a previous message in this tunnel [3].
2. IV             := hash(preIV + hop i's secret key 1)
3. preIV          := ecb_encrypt(preIV, hop i's secret key2)
4. payload        := cbc_encrypt(payload, hop i's secret key3, IV)
5. Return {preIV, payload}.

Decryption at hop i:
1. preIV          := ecb_decrypt(preIV, hop i's secret key2)
2. IV             := hash(preIV + hop i's secret key1)
3. payload        := cbc_decrypt(payload, hop i's secret key3, IV)
4. Return {preIV, payload}.

Inbound tunnel:
 * Message M arrives at the inbound gateway, aka hop 1.
 * Hops 1, 2, ..., N successively encrypt.
 * We are the tunnel endpoint, and we have everyone's secret keys,
   so we can use decrypt(N), decrypt(N-1), ...decrypt(1) to unwrap
   the encryption made by others.  We recover message M.

Outbound tunnel:
 * We have a message M we want to send.
 * We are the tunnel creator, so we have everyone's secret keys.
   We build M* by doing encrypt(N), encrypt(N-1), ..., encrypt(1).
 * We send M* to hop 1.  Hops 1, 2, ..., N successively decrypt.
 * The outbound tunnel endpoint recovers M.

[1]. http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/
[2]. http://dev.i2p.net/~jrandom/tunnel-alt.html
[3]. A hash table or alternatively a bloom filter can be used to
     detect whether we have previously seen a preIV.

This document has been placed in the public domain by Connelly
Barnes, 2005-01-17.

i2p mailing list
i2p at i2p.net

----- End forwarded message -----
Eugen* Leitl <a href="http://leitl.org">leitl</a>
ICBM: 48.07078, 11.61144            http://www.leitl.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE
http://moleculardevices.org         http://nanomachines.net

[demime 1.01d removed an attachment of type application/pgp-signature]

More information about the cypherpunks-legacy mailing list