elgamal edits

www.i2p2/pages/how_cryptography.html

@@ -18,11 +18,15 @@ technique used in <a href="how_elgamalaes">ElGamal/AES+SessionTag</a> (but we're
 
 <p>
 ElGamal is used for asymmetric encryption.
-ElGamal is used in two places in I2P:
+ElGamal is used in several places in I2P:
 <ul><li>
-To encrypt <a href="tunnel-alt-creation.html">Tunnel Build Messages</a>
+To encrypt router-to-router <a href="tunnel-alt-creation.html">Tunnel Build Messages</a>
 </li><li>
-For end-to-end encryption as a part of <a href="how_elgamalaes">ElGamal/AES+SessionTag</a>
+For end-to-end (destination-to-destination) encryption as a part of <a href="how_elgamalaes">ElGamal/AES+SessionTag</a>
+</li><li>
+For encryption of some <a href="how_networkdatabase.html#delivery">netDb stores and queries sent to floodfill routers</a>
+as a part of <a href="how_elgamalaes">ElGamal/AES+SessionTag</a>
+(destination-to-router or router-to-router).
 </li></ul>
 </p>
 
@@ -84,9 +88,10 @@ The encrypted ElGamal contains:
 </PRE>
 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.
 </p><p>
 See 
 <a href="http://trac.i2p2.de/browser/core/java/src/net/i2p/crypto/ElGamalEngine.java?rev=85a542c53d910dffbf34cdcefb8a2faeee96adc4">the ElGamal code</a>.
@@ -146,8 +151,19 @@ It may be quite difficult to make any change backward-compatible.
 <H2><a name="AES">AES</a></H2>
 
 <p>
-AES is used for symmetric encryption.
-<p>
+AES is used for symmetric encryption, in several cases:
+<ul><li>
+For <a href="#transports">transport encryption</a> after DH key exchange
+</li><li>
+For end-to-end (destination-to-destination) encryption as a part of <a href="how_elgamalaes">ElGamal/AES+SessionTag</a>
+</li><li>
+For encryption of some <a href="how_networkdatabase.html#delivery">netDb stores and queries sent to floodfill routers</a>
+as a part of <a href="how_elgamalaes">ElGamal/AES+SessionTag</a>
+(destination-to-router or router-to-router).
+</li><li>
+For encryption of <a href="how_tunnelrouting.html#testing">periodic tunnel test messages</a> sent from the router to itself, through its own tunnels.
+</li></ul>
+</p><p>
 We use 256 bit AES in CBC mode.
 The padding used is specified in <a href="http://tools.ietf.org/html/rfc2313">IETF RFC-2313 (PKCS#5 1.5, section 8.1 (for block type 02))</a>.
 In this case, padding exists of pseudorandomly generated octets to match 16 byte blocks.

www.i2p2/pages/how_elgamalaes.html

@@ -64,11 +64,11 @@ Each message received has one of two
 the two possible conditions:</p>
 
 <OL>
-<li> It is part of an existing session and is AES encrypted</li>
+<li> It is part of an existing session and contains a Session Tag and an AES encrypted block</li>
 <li> It is for a new session and contains both ElGamal and AES encrypted blocks</li>
 </OL>
 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.
 </p>
@@ -104,8 +104,8 @@ The encrypted message contains:
 </p>
 <h3>ElGamal Block</h3>
 <p>
-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.
 </p><p>
 The unencrypted ElGamal data is 222 bytes long, containing:
 <PRE>
@@ -136,7 +136,9 @@ The unencrypted ElGamal data is 222 bytes long, containing:
    |                             |
    +----+----+----+----+----+----+
 </PRE>
-The 32-byte Session Key is the identifier for the session.
+The 32-byte
+<a href="common_structures_spec#type_SessionKey">Session Key</a>
+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.
 </p><p>
@@ -203,7 +205,10 @@ New Session Key: A 32-byte <a href="common_structures_spec#type_SessionKey">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
 
 </PRE>
 
@@ -211,6 +216,16 @@ Padding: Random data to a multiple of 16 bytes for the total length
 The data is then <a href="how_cryptography">AES Encrypted</a>,
 using the session key and IV (calculated from the pre-IV) from the ElGamal section.</p>
 
+<h4>Notes</h4>
+<ul>
+<li>
+  Actual max payload length, and max block length, is less than 64 KB; see the<a href="i2np.html">I2NP Overview</a>.
+</li><li>
+New Session Key is currently unused and is never present.
+</li></ul>
+
+
+
 <h2 id="existing">Existing Session Message Specification</h2>
 
 <p>The session tags delivered successfully are remembered for a 
@@ -266,9 +281,14 @@ impact on overal performance.
 <ul><li>
 Delivery of too many tags at one time may impose substantial overhead for brief streaming connections
 or datagrams, and increase the chance of message loss.
+We currently deliver 40 tags at a time (1280 bytes).
+32 (1024 bytes) may be better for tunnel fragmentation.
 </li><li>
 A few tags could be delivered in each of several messages, or lots of tags all at once.
 </li><li>
+It is also important to study and tune
+the low-tag thresholds at which more tags are sent.
+</li><li>
 The number of tags delivered could depend on message size, keeping in mind
 the eventual padding to 1KB at the tunnel message layer.
 </li><li>
@@ -283,8 +303,23 @@ there are tradeoffs for each strategy.
 For very brief messages, almost the full 222 bytes of the pre-IV and padding fields in the ElGamal block
 could be used for the entire message, instead of establishing a session.
 </li><li>
+Evaluate padding strategy; currently we pad to a minimum of 128 bytes.
+Would be better to add a few tags to small messages than pad.
+</li><li>
+Perhaps things could be more efficient if the Session Tag system was bidirectional,
+so tags delivered in the 'forward' path could be used in the 'reverse' path,
+thus avoiding ElGamal in the initial response.
+The router currently plays some tricks like this when sending
+tunnel test messages to itself.
+</li><li>
 Change from Session Tags to
 <a href="performance.html#prng">a synchronized PRNG</a>.
+</li><li>
+Several of these ideas may require a new I2NP message type, or
+set a flag in the
+<a href="tunnel_message_spec.html#delivery">Delivery Instructions</a>,
+or set a magic number in the first few bytes of the Session Key field
+and accept a small risk of the random Session Key matching the magic number.
 </li></ul>
 
 </p>

www.i2p2/pages/how_garlicrouting.html

@@ -75,7 +75,7 @@ perhaps it is not, by itself, enough to justify a change in terminology.
 
 </p><p>
 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:
+<center>
+<img src="/_static/images/garliccloves.png" alt="Garlic Message Cloves" />
+</center>
 
 <ol><li>
 A

www.i2p2/pages/how_tunnelrouting.html

@@ -183,7 +183,7 @@ Most applications use 2 or 3 hops as their default.
 
 
 
-<h2>Tunnel testing</h2>
+<h2 id="testing">Tunnel testing</h2>
 <p>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

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
 </pre>
 
 <h4>Notes</h4>
-<p>
+<ul><li>
+In the 512-byte encrypted record,
+the ElGamal data contains bytes 1-256 and 258-513 of the
+<a href="how_cryptography.html#elgamal">514-byte ElGamal encrypted block</a>.
+The two padding bytes from the block (the zero bytes at locations 0 and 257) are removed.
+</li><li>
   See also the <a href="tunnel-alt-creation.html">tunnel creation specification</a>.
+</li></ul>
 </p>
 
 

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</pre>
+  bytes 193-221: uninterpreted / random padding</pre>
 
 <p>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:</p><pre>
   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</pre>
 
+In the 512-byte encrypted record,
+the ElGamal data contains bytes 1-256 and 258-513 of the
+<a href="how_cryptography.html#elgamal">514-byte ElGamal encrypted block</a>.
+The two padding bytes from the block (the zero bytes at locations 0 and 257) are removed.
+
 <p>Since the cleartext uses the full field, there is no need for
 additional padding beyond <code>SHA256(cleartext) + cleartext</code>.</p>