diff --git a/www.i2p2/pages/how_cryptography.html b/www.i2p2/pages/how_cryptography.html index 7af928f0..09a29da9 100644 --- a/www.i2p2/pages/how_cryptography.html +++ b/www.i2p2/pages/how_cryptography.html @@ -18,11 +18,15 @@ technique used in ElGamal/AES+SessionTag (but we're

ElGamal is used for asymmetric encryption. -ElGamal is used in two places in I2P: +ElGamal is used in several places in I2P:

@@ -84,9 +88,10 @@ The encrypted ElGamal contains: Each encrypted part is prepended with zeros to a size of exactly 257 bytes. Total length: 514 bytes. -In typical usage, higher layers pad the cleartext to 222 bytes, -resulting in 257-byte encrypted parts, -and there is no zero padding at this layer. +In typical usage, higher layers pad the cleartext data to 222 bytes, +resulting in an unencrypted block of 255 bytes. +This is encoded as two 256-byte encrypted parts, +and there is a single byte of zero padding before each part at this layer.

See the ElGamal code. @@ -146,8 +151,19 @@ It may be quite difficult to make any change backward-compatible.

AES

-AES is used for symmetric encryption. -

+AES is used for symmetric encryption, in several cases: +

+

We use 256 bit AES in CBC mode. The padding used is specified in IETF RFC-2313 (PKCS#5 1.5, section 8.1 (for block type 02)). In this case, padding exists of pseudorandomly generated octets to match 16 byte blocks. diff --git a/www.i2p2/pages/how_elgamalaes.html b/www.i2p2/pages/how_elgamalaes.html index 3fdaff70..b6ff47df 100644 --- a/www.i2p2/pages/how_elgamalaes.html +++ b/www.i2p2/pages/how_elgamalaes.html @@ -64,11 +64,11 @@ Each message received has one of two the two possible conditions:

    -
  1. It is part of an existing session and is AES encrypted
    2. +
  2. It is part of an existing session and contains a Session Tag and an AES encrypted block
  3. It is for a new session and contains both ElGamal and AES encrypted blocks
When a router receives a message, it will first assume it is from -an existing session and attempt to decrypt it using AES. +an existing session and attempt to look up the Session Tag and decrypt the following data using AES. If that fails, it will assume it is for a new session and attempt to decrypt it using ElGamal.

@@ -104,8 +104,8 @@ The encrypted message contains:

ElGamal Block

-The ElGamal Block is always 514 bytes long. -The AES Block is variable length but is always a multiple of 16 bytes. +The encrypted ElGamal Block is always 514 bytes long. +The encrypted AES Block length is variable but is always a multiple of 16 bytes.

The unencrypted ElGamal data is 222 bytes long, containing: 

@@ -136,7 +136,9 @@ The unencrypted ElGamal data is 222 bytes long, containing:
    |                             |
    +----+----+----+----+----+----+
-The 32-byte Session Key is the identifier for the session. +The 32-byte +Session Key +is the identifier for the session. The 32-byte Pre-IV will be used to generate the IV for the AES block that follows; the IV is the first 16 bytes of the SHA-256 Hash of the Pre-IV.

@@ -203,7 +205,10 @@ New Session Key: A 32-byte Sess Payload: the data -Padding: Random data to a multiple of 16 bytes for the total length +Padding: Random data to a multiple of 16 bytes for the total length. + May contain more than the minimum required padding. + +Minimum length: 48 bytes @@ -211,6 +216,16 @@ Padding: Random data to a multiple of 16 bytes for the total length The data is then AES Encrypted, using the session key and IV (calculated from the pre-IV) from the ElGamal section.

+

Notes

+ + + +

Existing Session Message Specification

The session tags delivered successfully are remembered for a @@ -266,9 +281,14 @@ impact on overal performance.

diff --git a/www.i2p2/pages/how_garlicrouting.html b/www.i2p2/pages/how_garlicrouting.html index 2984b2b6..6fba2314 100644 --- a/www.i2p2/pages/how_garlicrouting.html +++ b/www.i2p2/pages/how_garlicrouting.html @@ -75,7 +75,7 @@ perhaps it is not, by itself, enough to justify a change in terminology.

Another difference -from the method described by Freedman with I2P's bundling +from the method described by Freedman is that the path is unidirectional - there is no "turning point" as seen in onion routing or mixmaster reply blocks, which greatly simplifies the algorithm and allows for more flexible and reliable delivery. @@ -147,6 +147,9 @@ Delivery Instructions may specify a Destination, Router, or Tunnel. Generally, a Garlic Message will contain only one clove. However, the router will periodically bundle two additional cloves in the Garlic Message: +

+Garlic Message Cloves +
  1. A diff --git a/www.i2p2/pages/how_tunnelrouting.html b/www.i2p2/pages/how_tunnelrouting.html index fd720203..46dedeaf 100644 --- a/www.i2p2/pages/how_tunnelrouting.html +++ b/www.i2p2/pages/how_tunnelrouting.html @@ -183,7 +183,7 @@ Most applications use 2 or 3 hops as their default. -

    Tunnel testing

    +

    Tunnel testing

    All tunnels are periodically tested by their creator by sending a DeliveryStatusMessage out an outbound tunnel and bound for another inbound tunnel (testing both tunnels at once). If either fails a number of consecutive tests, it is marked as no longer diff --git a/www.i2p2/pages/i2np_spec.html b/www.i2p2/pages/i2np_spec.html index 05ec6695..273849fa 100644 --- a/www.i2p2/pages/i2np_spec.html +++ b/www.i2p2/pages/i2np_spec.html @@ -200,7 +200,7 @@ encrypted: toPeer :: First 16 bytes of the SHA-256 Hash of the peer's router identity length -> 16 bytes -encrypted_data :: ElGamal-2048 encrypted data +encrypted_data :: ElGamal-2048 encrypted data (see notes) length -> 512 total length: 528 @@ -209,8 +209,14 @@ total length: 528

    Notes

    -

    +

    diff --git a/www.i2p2/pages/tunnel-alt-creation.html b/www.i2p2/pages/tunnel-alt-creation.html index 2e955f4b..b029d0ae 100644 --- a/www.i2p2/pages/tunnel-alt-creation.html +++ b/www.i2p2/pages/tunnel-alt-creation.html @@ -60,7 +60,7 @@ Also specified in the byte 184: flags bytes 185-188: request time (in hours since the epoch) bytes 189-192: next message ID - bytes 193-222: uninterpreted / random padding + bytes 193-221: uninterpreted / random padding

    The next tunnel ID and next router identity hash fields are used to specify the next hop in the tunnel, though for an outbound tunnel @@ -87,6 +87,11 @@ public encryption key and formatted into a 528 byte record:

       bytes   0-15: First 16 bytes of the SHA-256 of the current hop's router identity
   bytes 16-527: ElGamal-2048 encrypted request record
    +In the 512-byte encrypted record, +the ElGamal data contains bytes 1-256 and 258-513 of the +514-byte ElGamal encrypted block. +The two padding bytes from the block (the zero bytes at locations 0 and 257) are removed. +

    Since the cleartext uses the full field, there is no need for additional padding beyond SHA256(cleartext) + cleartext.

    diff --git a/www.i2p2/static/images/garliccloves.png b/www.i2p2/static/images/garliccloves.png new file mode 100644 index 00000000..2a00a9d1 Binary files /dev/null and b/www.i2p2/static/images/garliccloves.png differ