From 9d94e9bc0c4a89f40f73502d8ddc9e28adddfb54 Mon Sep 17 00:00:00 2001 From: zzz Date: Fri, 3 Sep 2010 02:15:31 +0000 Subject: [PATCH] tunnel edits --- www.i2p2/pages/i2np_spec.html | 44 +++++-- www.i2p2/pages/tunnel-alt-creation.html | 91 ++++++++++---- www.i2p2/pages/tunnel-alt.html | 158 +++++++++++++++++------- 3 files changed, 211 insertions(+), 82 deletions(-) diff --git a/www.i2p2/pages/i2np_spec.html b/www.i2p2/pages/i2np_spec.html index 273849fa..6aecc482 100644 --- a/www.i2p2/pages/i2np_spec.html +++ b/www.i2p2/pages/i2np_spec.html @@ -132,20 +132,36 @@ Cleartext: | reply_iv | + + | | -+----+----+----+----+----+----+----+----+----+ -|flag| request_time | send_message_id | -+----+----+----+----+----+----+----+----+----+ -| padding... -+----+----+----+--// ++----+----+----+----+----+----+----+----+ +|flag| request_time | send_msg_id ++----+----+----+----+----+----+----+----+ + | | ++----+ + +| 29 bytes padding | ++ + +| | ++ +----+----+ +| | ++----+----+----+----+----+----+ -encrypted: + +ElGamal encrypted: +----+----+----+----+----+----+----+----+ | toPeer | + + | | +----+----+----+----+----+----+----+----+ | encrypted data ... | +~ ~ +| | ++----+----+----+----+----+----+----+----+ + +ElGamal and AES encrypted: ++----+----+----+----+----+----+----+----+ +| encrypted data ... | +~ ~ +| | +----+----+----+----+----+----+----+----+ {% endfilter %} @@ -190,12 +206,12 @@ send_message_id :: Integer padding :: Data length -> 29 bytes - source -> random total length: 222 -encrypted: + +ElGamal encrypted: toPeer :: First 16 bytes of the SHA-256 Hash of the peer's router identity length -> 16 bytes @@ -205,6 +221,14 @@ encrypted_data :: ElGamal-2048 encrypted data (see notes) total length: 528 + +ElGamal and AES encrypted: + +encrypted_data :: ElGamal and AES encrypted data + length -> 528 + +total length: 528 + {% endfilter %} @@ -226,7 +250,7 @@ The two padding bytes from the block (the zero bytes at locations 0 and 257) are unencrypted: +----+----+----+----+----+----+----+----+ | random data... | - +~ ~ | | + +----+ | |ret | @@ -241,7 +265,7 @@ bytes 0-526: random data byte 527 : reply encrypted: -bytes 0-527: AES-encrypted record(note: same size as BuildRequestRecord!) +bytes 0-527: AES-encrypted record(note: same size as BuildRequestRecord) total length: 528 diff --git a/www.i2p2/pages/tunnel-alt-creation.html b/www.i2p2/pages/tunnel-alt-creation.html index b029d0ae..ed9a8154 100644 --- a/www.i2p2/pages/tunnel-alt-creation.html +++ b/www.i2p2/pages/tunnel-alt-creation.html @@ -17,9 +17,13 @@ for an overview of the process, including peer selection and ordering methods. the path of peers in the tunnel, rewritten in place, and transmitted back to the tunnel creator. This single tunnel message is made up of a variable number of records (up to 8) - one for each potential peer in -the tunnel. Individual records are asymmetrically encrypted to be +the tunnel. Individual records are asymmetrically +(ElGamal) +encrypted to be read only by a specific peer along the path, while an additional -symmetric layer of encryption is added at each hop so as to expose +symmetric layer of encryption +(AES) +is added at each hop so as to expose the asymmetrically encrypted record only at the appropriate time.

Number of Records

@@ -37,7 +41,7 @@ with the desired amount of tunnel length obfuscation. In the current network, most tunnels are 2 or 3 hops long. The current implementation uses a 5-record VTBM to build tunnels of 4 hops or less, and the 8-record TBM for longer tunnels. -The 5-record VTBM (which fits in 3 1KB tunnel messaages) reduces network traffic +The 5-record VTBM (which, when fragmented, fits in three 1KB tunnel messaages) reduces network traffic and increases build sucess rate, because smaller messages are less likely to be dropped.

The reply message must be the same type and length as the build message. @@ -56,7 +60,7 @@ Also specified in the bytes 72-103: AES-256 tunnel layer key bytes 104-135: AES-256 tunnel IV key bytes 136-167: AES-256 reply key - bytes 168-183: reply IV + bytes 168-183: AES-256 reply IV byte 184: flags bytes 185-188: request time (in hours since the epoch) bytes 189-192: next message ID @@ -73,14 +77,24 @@ message ID that the message (or reply) should use.

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 message + specified next hop in a Tunnel Build Reply Message bits 5-0: Undefined Bit 7 indicates that the hop will be an inbound gateway (IBGW). Bit 6 indicates that the hop will be an outbound endpoint (OBEP). +If neither bit is set, the hop will be an intermediate participant. -

Request Encryption

+

Request Record Creation

+

+Every hop gets a random Tunnel ID. +The current and next-hop Tunnel IDs are filled in. +Every record gets a random tunnel IV key, and reply IV. +The layer and reply key pairs are generated. +

+ + +

Request Record Encryption

That cleartext record is ElGamal 2048 encrypted with the hop's public encryption key and formatted into a 528 byte record:

@@ -95,6 +109,12 @@ The two padding bytes from the block (the zero bytes at locations 0 and 257) are
 
Since the cleartext uses the full field, there is no need for
 additional padding beyond SHA256(cleartext) + cleartext.

 
+

+Each 528-byte record is then iteratively encrypted
+(using AES decryption, with the reply key and reply IV for each hop) so that the router identity will only be in cleartext
+for the hop in question.
+

+
 
Hop Processing and Encryption

 
 
When a hop receives a TunnelBuildMessage, it looks through the
@@ -108,9 +128,17 @@ are dropped.

 
 
After deciding whether they will agree to participate in the tunnel
 or not, they replace the record that had contained the request with
-an encrypted reply block.  All other records are AES-256/CBC
-encrypted with the included reply key and IV (though each is
-encrypted separately, rather than chained across records).

+an encrypted reply block.  All other records are AES-256
+encrypted with the included reply key and IV. Each is
+encrypted separately, rather than chained across records.

+
+

+Each hop knows only its own response.
+If it agrees, it will maintain the tunnel until expiration,
+even if it will not be used,
+as it cannot know whether all other hops agreed.
+

+
 
 
Reply Record Specification

 
@@ -145,19 +173,23 @@ The padding is placed before the status byte:
 This is also described in the
 I2NP spec.
 
-
Request Preparation

+
Tunnel Build Message Preparation

 
-
When building a new request, all of the records must first be 
-built and asymmetrically encrypted.  Each record should then be
-decrypted with the reply keys and IVs of the hops earlier in the
-path.  That decryption should be run in reverse order so that the
+
When building a new Tunnel Build Messaage, all of the Build Request Records must first be 
+built and asymmetrically encrypted using
+ElGamal.
+Each record is then
+premptively decrypted with the reply keys and IVs of the hops earlier in the
+path, using
+AES.
+That decryption should be run in reverse order so that the
 asymmetrically encrypted data will show up in the clear at the
 right hop after their predecessor encrypts it.

 
 
The excess records not needed for individual requests are simply
 filled with random data by the creator.

 
-
Request Delivery

+
Tunnel Build Message Delivery

 
 
For outbound tunnels, the delivery is done directly from the tunnel
 creator to the first hop, packaging up the TunnelBuildMessage as if
@@ -168,7 +200,7 @@ If no outbound tunnel is available in that pool, an outbound exploratory tunnel
 At startup, when no outbound exploratory tunnel exists yet, a fake 0-hop
 outbound tunnel is used.

 
-
Endpoint Handling

+
Tunnel Build Message Endpoint Handling

 
 

 For creation of an outbound tunnel,
@@ -184,10 +216,12 @@ or
 (the type of message and number of records must match that of the request)
 and delivers it to the
 reply tunnel specified within the request record.  That reply tunnel
-forwards the reply records down to the tunnel creator for
-processing, as below.

+forwards the Tunnel Build Reply Message back to the tunnel creator,
+just as for any other message.
+The tunnel creator then
+processes it, as described below.

 
-
The reply tunnel was specified by the creator as follows:
+
The reply tunnel was selected by the creator as follows:
 Generally it is an inbound tunnel from the same pool as the new outbound tunnel being built.
 If no inbound tunnel is available in that pool, an inbound exploratory tunnel is used.
 At startup, when no inbound exploratory tunnel exists yet, a fake 0-hop
@@ -196,10 +230,10 @@ inbound tunnel is used.

 

 For creation of an inbound tunnel,
 when the request reaches the inbound endpoint (also known as the
-tunnel creator), there is no need to generate an explicit Reply Message, and
+tunnel creator), there is no need to generate an explicit Tunnel Build Reply Message, and
 the router processes each of the replies, as below.

 
-
Reply Processing by the Request Creator

+
Tunnel Build Reply Message Processing

 
 
To process the reply records, the creator simply has to AES decrypt
 each record individually, using the reply key and IV of each hop in
@@ -267,9 +301,12 @@ update
 
Future Work

 
+
  • 
+The Bloom filter rotation time should be evaluated.
+
  • 
+Use only VTBM; do not select old peers that don't support it.
+
    • 
 
 
 {% endblock %}
diff --git a/www.i2p2/pages/tunnel-alt.html b/www.i2p2/pages/tunnel-alt.html
index 80f99aba..ecc94917 100644
--- a/www.i2p2/pages/tunnel-alt.html
+++ b/www.i2p2/pages/tunnel-alt.html
@@ -3,18 +3,18 @@
 {% block content %}
 
 This page documents the current tunnel implementation.
-Updated July 2010 for release 0.8
+Updated September 2010 for release 0.8
 
 
-
    1) Tunnel overview
    
+
    Tunnel overview
    
 
 
    Within I2P, messages are passed in one direction through a virtual
 tunnel of peers, using whatever means are available to pass the 
 message on to the next hop.  Messages arrive at the tunnel's 
-gateway, get bundled up and/or fragmented into fixed sizes tunnel messages, 
+gateway, get bundled up and/or fragmented into fixed-size tunnel messages, 
 and are forwarded on to the next hop in the tunnel, which processes and verifies
 the validity of the message and sends it on to the next hop, and so on, until
-it reaches the tunnel endpoint.  That endpoint takes the messages
+it reaches the tunnel endpoint.  That endpoint takes the messages
 bundled up by the gateway and forwards them as instructed - either
 to another router, to another tunnel on another router, or locally.
    
 
@@ -27,8 +27,8 @@ out to the remote endpoint.
    
 
 
    The tunnel's creator selects exactly which peers will participate
 in the tunnel, and provides each with the necessary configuration
-data.  They may have any number of hops, but may be constrained with various
-proof-of-work requests to add on additional steps.  It is the intent to make
+data.  They may have any number of hops.
+It is the intent to make
 it hard for either participants or third parties to determine the length of 
 a tunnel, or even for colluding participants to determine whether they are a
 part of the same tunnel at all (barring the situation where colluding peers are
@@ -49,31 +49,88 @@ available for client applications, exposing TCP-esque operation,
 including message reordering, retransmission, congestion control, etc.
    
 
 
    
-An overview of I2P terminology is
+An overview of I2P tunnel terminology is
 on the tunnel overview page.
 
    
 
-
    2) Tunnel operation
    
+
    Tunnel Operation (Message Processing)
    
+
    Overview
    
 
-
    Tunnel operation has four distinct processes, taken on by various 
-peers in the tunnel.  First, the tunnel gateway accumulates a number
-of tunnel messages and preprocesses them into something for tunnel
-delivery.  Next, that gateway encrypts that preprocessed data, then
-forwards it to the first hop.  That peer, and subsequent tunnel 
+
    After a tunnel is built, I2NP messages are processed and passed through it.
+Tunnel operation has four distinct processes, taken on by various 
+peers in the tunnel.  
    1. First, the tunnel gateway accumulates a number
+of I2NP messages and preprocesses them into tunnel messages for
+delivery.  
    2. Next, that gateway encrypts that preprocessed data, then
+forwards it to the first hop.  
    3. That peer, and subsequent tunnel 
 participants, unwrap a layer of the encryption, verifying that it isn't
 a duplicate, then forward it on to the next peer.  
-Eventually, the message arrives at the endpoint where the messages
-bundled by the gateway are split out again and forwarded on as 
-requested.
      
+
    4. Eventually, the tunnel messages arrive at the endpoint where the I2NP messages
+originally bundled by the gateway are reassembled and forwarded on as 
+requested.
    
 
-
    Tunnel IDs are 4 byte numbers used at each hop - participants know what
-tunnel ID to listen for messages with and what tunnel ID they should be forwarded
-on as to the next hop, and each hop chooses the tunnel ID which they receive messages
-on.  Tunnels themselves are short-lived (10 minutes).
-Even if subsequent tunnels are built using the same sequence of 
-peers, each hop's tunnel ID will change.
    
+
    
+Intermediate tunnel participants do not know whether they are in an
+inbound or an outbound tunnel; they always "encrypt" for the next hop.
+Therefore, we take advantage of symmetric AES encryption
+to "decrypt" at the outbound tunnel gateway,
+so that the plaintext is revealed at the outbound endpoint.
+
    
+
    
+
    
+      Inbound and outbound tunnel schematic
+
    
+
    
 
-
    2.1) Message preprocessing
    
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
    RolePreprocessingEncryption OperationPostprocessing
    Outbound Gateway (Creator)Fragment, Batch, and PadIteratively encrypt (using decryption operations)Forward to next hop
    Participant Decrypt (using an encryption operation)Forward to next hop
    Outbound Endpoint Decrypt (using an encryption operation) to reveal plaintext tunnel messageReassemble Fragments, Forward as instructed to Inbound Gateway or Router
    Inbound GatewayFragment, Batch, and PadEncryptForward to next hop
    Participant EncryptForward to next hop
    Inbound Endpoint (Creator) Iteratively decrypt to reveal plaintext tunnel messageReassemble Fragments, Receive data
    
+
+
+
+
    Gateway Processing
    
+
    Message Preprocessing
    
 
 
    A tunnel gateway's function is to fragment and pack
 I2NP messages into fixed-size
@@ -86,9 +143,23 @@ Tunnel messages contain the following:
 
  • A 16 byte IV (initialization vector)
    • 
 
  • A checksum
 
  • Padding, if necessary
    • 
-
  • One or more { delivery instruction, I2NP message fragment} pairs
    • 
+
  • One or more { delivery instruction, I2NP message fragment } pairs
    • 
 
 
+
    Tunnel IDs are 4 byte numbers used at each hop - participants know what
+tunnel ID to listen for messages with and what tunnel ID they should be forwarded
+on as to the next hop, and each hop chooses the tunnel ID which they receive messages
+on.  Tunnels themselves are short-lived (10 minutes).
+Even if subsequent tunnels are built using the same sequence of 
+peers, each hop's tunnel ID will change.
    
+
+
    To prevent adversaries from tagging the messages along the path by adjusting
+the message size, all tunnel messages are a fixed 1024 bytes in size.  To accommodate 
+larger I2NP messages as well as to support smaller ones more efficiently, the
+gateway splits up the larger I2NP messages into fragments contained within each
+tunnel message.  The endpoint will attempt to rebuild the I2NP message from the
+fragments for a short period of time, but will discard them as necessary.
    
+
 
    
 
 Details are in the
@@ -96,7 +167,7 @@ Details are in the
 
 
 
-
    2.2) Gateway Processing
    
+
    Gateway Encryption
    
 
 
    After the preprocessing of messages into a padded payload, the gateway builds
 a random 16 byte IV value, iteratively encrypting it and the tunnel message as
@@ -111,7 +182,7 @@ data with the IV and layer keys for all hops in the tunnel.  The result of the o
 tunnel encryption is that when each peer encrypts it, the endpoint will recover 
 the initial preprocessed data.
    
 
-
    2.3) Participant Processing
    
+
    Participant Processing
    
 
 
    When a peer receives a tunnel message, it checks that the message came from
 the same previous hop as before (initialized when the first message comes through
@@ -134,7 +205,7 @@ false positive.  The unique value fed into the Bloom filter is the XOR of the IV
 and the first block so as to prevent nonsequential colluding peers in the tunnel 
 from tagging a message by resending it with the IV and first block switched.
    
 
-
    2.4) Endpoint Processing
    
+
    Endpoint Processing
    
 
 
    After receiving and validating a tunnel message at the last hop in the tunnel,
 how the endpoint recovers the data encoded by the gateway depends upon whether 
@@ -148,23 +219,6 @@ layer and IV keys of each step in reverse order.
    
 which it may then parse out into the included I2NP messages and forwards them as
 requested in their delivery instructions.
    
 
-
    These padding strategies can be used on a variety of levels, addressing the
-exposure of message size information to different adversaries.  After gathering
-and reviewing some statistics
-from the 0.4 network, as well as exploring the anonymity tradeoffs, we're starting
-with a fixed tunnel message size of 1024 bytes.  Within this however, the fragmented
-messages themselves are not padded by the tunnel at all (though for end to end 
-messages, they may be padded as part of the garlic wrapping).
    
-
-
    2.6) Tunnel Fragmentation
    
-
-
    To prevent adversaries from tagging the messages along the path by adjusting
-the message size, all tunnel messages are a fixed 1024 bytes in size.  To accommodate 
-larger I2NP messages as well as to support smaller ones more efficiently, the
-gateway splits up the larger I2NP messages into fragments contained within each
-tunnel message.  The endpoint will attempt to rebuild the I2NP message from the
-fragments for a short period of time, but will discard them as necessary.
    
-
 
 
    Tunnel Building
    
 
@@ -177,7 +231,7 @@ reply.  There are three important dimensions to keep in mind when producing
 the tunnels: what peers are used (and where), how the requests are sent (and 
 replies received), and how they are maintained.
    
 
-
    3.1) Peer Selection
    
+
    Peer Selection
    
 
 
    Beyond the two types of tunnels - inbound and outbound - there are two styles
 of peer selection used for different tunnels - exploratory and client.
@@ -240,7 +294,7 @@ within a single pool but not between different pools.
 New keys are generated at each router restart.
 
 
-
    3.2) Request delivery
    
+
    Request delivery
    
 
 
    
 A multi-hop tunnel is built using a single build message which is repeatedly
@@ -272,7 +326,7 @@ the router in question.
 For more information on peer profiling, see the
 Peer Profiling and Selection page.
 
-
    3.3) Tunnel Pools
    
+
    Tunnel Pools
    
 
 
    To allow efficient operation, the router maintains a series of tunnel pools,
 each managing a group of tunnels used for a specific purpose with their own
@@ -327,4 +381,14 @@ automatically, how much should be configured as a per tunnel or per hop setting,
 and how should the tunnel's creator (and in turn, user) control this operation?
 All of this is left as unknown, to be worked out for a distant future release. 
 
+
+
    Padding
    
+
    The padding strategies can be used on a variety of levels, addressing the
+exposure of message size information to different adversaries.
+The current fixed tunnel message size is 1024 bytes.  Within this however, the fragmented
+messages themselves are not padded by the tunnel at all, though for end to end 
+messages, they may be padded as part of the garlic wrapping.
    
+
+
+
 {% endblock %}