Summary

The current size of the encrypted tunnel Build Request and Reply records is 528. For typical Variable Tunnel Build and Variable Tunnel Build Reply messages, the total size is 2113 bytes. This message is fragmented into three 1KB tunnel messages for the reverse path.

Changes to the 528-byte record format for ECIES-X25519 routers are specified in [Prop152] and [Tunnel-Creation-ECIES]. For a mix of ElGamal and ECIES-X25519 routers in a tunnel, the record size must remain 528 bytes. However, if all routers in a tunnel are ECIES-X25519, a new, smaller build record is possible, because ECIES-X25519 encryption has much less overhead than ElGamal.

Smaller messages would save bandwidth. Also, if the messages could fit in a single tunnel message, the reverse path would be three times more efficient.

This proposal defines new request and reply records and new Build Request and Build Reply messages.

The tunnel creator and all hops in the created tunnel must ECIES-X25519, and at least version 0.9.51. This proposal will not be useful until a majority of the routers in the network are ECIES-X25519. This is expected to happen by year-end 2021.

Goals

See [Prop152] and [Prop156] for additional goals.

• Smaller records and messages
• Maintain sufficient space for future options, as in [Prop152] and [Tunnel-Creation-ECIES]
• Fit in one tunnel message for the reverse path
• Support ECIES hops only
• Maintain improvements implemented in [Prop152] and [Tunnel-Creation-ECIES]
• Maximize compatibility with current network
• Hide inbound build messages from the OBEP
• Hide outbound build reply messages from the IBGW
• Do not require "flag day" upgrade to entire network
• Gradual rollout to minimize risk
• Reuse existing cryptographic primitives

Non-Goals

See [Prop156] for additional non-goals.

• No requirement for mixed ElGamal/ECIES tunnels
• Layer encryption changes, for that see [Prop153]
• No speedups of crypto operations. It's assumed that ChaCha20 and AES are similar, even with AESNI, at least for the small data sizes in question.

Records

See appendix for calculations.

Encrypted request and reply records will be 218 bytes, compared to 528 bytes now.

The plaintext request records will be 154 bytes, compared to 222 bytes for ElGamal records, and 464 bytes for ECIES records as defined in [Prop152] and [Tunnel-Creation-ECIES].

The plaintext response records will be 202 bytes, compared to 496 bytes for ElGamal records, and 512 bytes for ECIES records as defined in [Prop152] and [Tunnel-Creation-ECIES].

The reply encryption will be ChaCha20 (NOT ChaCha20/Poly1305), so the plaintext records do not need to be a multiple of 16 bytes.

Request records will be made smaller by using HKDF to create the layer and reply keys, so they do not need to be explicitly included in the request.

Tunnel Build Messages

Both will be "variable" with a one-byte number of records field, as with the existing Variable messages.

Message Flow

STBM: Short tunnel build message (type 25)
OTBRM: Outbound tunnel build reply message (type 26)

Outbound Build A-B-C
Reply through existing inbound D-E-F


                New Tunnel
         STBM      STBM      STBM
Creator ------> A ------> B ------> C ---\
                                   OBEP   \
                                          | Garlic wrapped
                                          | OTBRM
                                          | (TUNNEL delivery)
                                          | from OBEP to
                                          | creator
              Existing Tunnel             /
Creator <-------F---------E-------- D <--/
                                   IBGW



Inbound Build D-E-F
Sent through existing outbound A-B-C


              Existing Tunnel
Creator ------> A ------> B ------> C ---\
                                  OBEP    \
                                          | Garlic wrapped (optional)
                                          | STBM
                                          | (ROUTER delivery)
                                          | from creator
                New Tunnel                | to IBGW
          STBM      STBM      STBM        /
Creator <------ F <------ E <------ D <--/
                                   IBGW

Record Encryption

Request and reply record encryption: as defined in [Prop152] and [Tunnel-Creation-ECIES].

Reply record encryption for other slots: ChaCha20.

Layer Encryption

Currently there is no plan to change layer encryption for tunnels built with this specification; it would remain AES, as currently used for all tunnels.

Changing layer encryption to ChaCha20 is a topic for additional research.

New Tunnel Data Message

Currently there is no plan to change the 1KB Tunnel Data Message used for tunnels built with this specification.

It may be useful to introduce a new I2NP message that is larger or variable-sized, concurrent with this proposal, for use over these tunnels. This would reduce overhead for large messages. This is a topic for additional research.

Short Request Record

bytes     0-3: tunnel ID to receive messages as, nonzero
bytes     4-7: next tunnel ID, nonzero
bytes    8-39: next router identity hash
byte       40: flags
bytes   41-42: more flags, unused, set to 0 for compatibility
byte       43: layer encryption type
bytes   44-47: request time (in minutes since the epoch, rounded down)
bytes   48-51: request expiration (in seconds since creation)
bytes   52-55: next message ID
bytes    56-x: tunnel build options (Mapping)
bytes     x-x: other data as implied by flags or options
bytes   x-153: random padding (see below)

Bit order: 76543210 (bit 7 is MSB)
bit 7: if set, allow messages from anyone
bit 6: if set, allow messages to anyone, and send the reply to the
       specified next hop in a Tunnel Build Reply Message
bits 5-0: Undefined, must set to 0 for compatibility with future options

bytes    0-15: Hop's truncated identity hash
bytes   16-47: Sender's ephemeral X25519 public key
bytes  48-201: ChaCha20 encrypted ShortBuildRequestRecord
bytes 202-217: Poly1305 MAC

Short Reply Record

bytes    0-x: Tunnel Build Reply Options (Mapping)
bytes    x-x: other data as implied by options
bytes  x-200: Random padding (see below)
byte     201: Reply byte

bytes   0-201: ChaCha20 encrypted ShortBuildReplyRecord
bytes 202-217: Poly1305 MAC

KDF

See KDF section below.

ShortTunnelBuild

I2NP Type 25

This message is sent to middle hops, OBEP, and IBEP (creator). It may not be sent to the IBGW (use garlic wrapped InboundTunnelBuild instead). When received by the OBEP, it is transformed to an OutboundTunnelBuildReply, garlic wrapped, and sent to the originator.

+----+----+----+----+----+----+----+----+
| num| ShortBuildRequestRecords...
+----+----+----+----+----+----+----+----+

num ::
       1 byte Integer
       Valid values: 1-8

record size: 218 bytes
total size: 1+$num*218

OutboundTunnelBuildReply

I2NP Type 26

This message is only sent by the OBEP to the IBEP (creator) via an existing inbound tunnel. It may not be sent to any other hop. It is always garlic encrypted.

+----+----+----+----+----+----+----+----+
| num|                                  |
+----+                                  +
|      ShortBuildReplyRecords...        |
+----+----+----+----+----+----+----+----+

num ::
       Total number of records,
       1 byte Integer
       Valid values: 1-8

ShortBuildReplyRecords ::
       Encrypted records
       length: num * 218

encrypted record size: 218 bytes
total size: 1+$num*218

KDF

We use ck from Noise state after tunnel build record encryption/decrytion to derive following keys: reply key, AES layer key, AES IV key and garlic reply key/tag for OBEP.

Reply key: Unlike long records we can't use left part of ck for reply key, because it's not last and will be used later. Reply key is used to encypt reply that record using AEAD/Chaha20/Poly1305 and Chacha20 to reply other records. Both use the same key, nonce is record's position in the message starting from 0.

keydata = HKDF(ck, ZEROLEN, "SMTunnelReplyKey", 64)
replyKey = keydata[32:63]
ck = keydata[0:31]

Layer key:
Layer key is always AES for now, but same KDF can be used from Chacha20

keydata = HKDF(ck, ZEROLEN, "SMTunnelLayerKey", 64)
layerKey = keydata[32:63]

IV key for non-OBEP record:
ivKey = keydata[0:31]
because it's last

IV key for OBEP record:
ck = keydata[0:31]
keydata = HKDF(ck, ZEROLEN, "TunnelLayerIVKey", 64)
ivKey = keydata[32:63]
ck = keydata[0:31]

OBEP garlic reply key/tag:
keydata = HKDF(ck, ZEROLEN, "RGarlicKeyAndTag", 64)
replyKey = keydata[32:63]
replyTag = keydata[0:7]