diff --git a/i2p2www/pages/site/docs/spec/tunnel-creation.html b/i2p2www/pages/site/docs/spec/tunnel-creation.html
index a0e7247a..ad6e76f5 100644
--- a/i2p2www/pages/site/docs/spec/tunnel-creation.html
+++ b/i2p2www/pages/site/docs/spec/tunnel-creation.html
@@ -34,7 +34,7 @@ to hide the actual length of the tunnel from the participants.
 There are two build message types. The original
 <a href="{{ site_url('docs/spec/i2np') }}#msg_TunnelBuild">Tunnel Build Message</a> (TBM)
 contains 8 records, which is more than enough for any practical tunnel length.
-The recently-implemented
+The newer
 <a href="{{ site_url('docs/spec/i2np') }}#msg_VariableTunnelBuild">Variable Tunnel Build Message</a> (VTBM)
 contains 1 to 8 records. The originator may trade off the size of the message
 with the desired amount of tunnel length obfuscation.
@@ -73,6 +73,12 @@ endpoint, they specify where the rewritten tunnel creation reply
 message should be sent.  In addition, the next message ID specifies the
 message ID that the message (or reply) should use.</p>
 
+<p>
+The tunnel layer key, tunnel IV key, reply key, and reply IV
+are each random 32-byte values generated by the creator,
+for use in this build request record only.
+</p>
+
 <p>The flags field contains the following:
 <pre>
  Bit order: 76543210 (bit 7 is MSB)
@@ -81,18 +87,18 @@ message ID that the message (or reply) should use.</p>
         specified next hop in a Tunnel Build Reply Message
  bits 5-0: Undefined, must set to 0 for compatibility with future options
 </pre>
-
+<p>
 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.
 Both cannot be set at once.
+</p>
 
 <h4>Request Record Creation</h4>
 <p>
 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.
+Every record gets a random tunnel IV key, reply IV, layer key, and reply key.
 </p>
 
 
@@ -102,12 +108,12 @@ The layer and reply key pairs are generated.
 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>
-
+<p>
 In the 512-byte encrypted record,
 the ElGamal data contains bytes 1-256 and 258-513 of the
 <a href="{{ site_url('docs/how/cryptography') }}#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>
 <p>Since the cleartext uses the full field, there is no need for
 additional padding beyond <code>SHA256(cleartext) + cleartext</code>.</p>
 
@@ -132,7 +138,8 @@ are dropped.</p>
 or not, they replace the record that had contained the request with
 an encrypted reply block.  All other records are <a href="{{ site_url('docs/how/cryptography') }}#AES">AES-256
 encrypted</a> with the included reply key and IV. Each is
-encrypted separately, rather than chained across records.</p>
+AES/CBC encrypted separately with the same reply key and reply IV.
+The CBC mode is not continued (chained) across records.</p>
 
 <p>
 Each hop knows only its own response.
@@ -177,8 +184,10 @@ The padding is placed before the status byte:
   bytes 32-526 : Random padding
   byte 527     : Reply value
 </pre>
+<p>
 This is also described in the
 <a href="{{ site_url('docs/spec/i2np') }}#struct_BuildResponseRecord">I2NP spec</a>.
+</p>
 
 <h3 id="tunnelCreate.requestPreparation">Tunnel Build Message Preparation</h3>
 
diff --git a/i2p2www/pages/site/docs/spec/tunnel-message.html b/i2p2www/pages/site/docs/spec/tunnel-message.html
index adf45b94..34b4790f 100644
--- a/i2p2www/pages/site/docs/spec/tunnel-message.html
+++ b/i2p2www/pages/site/docs/spec/tunnel-message.html
@@ -123,7 +123,7 @@ IV ::
 
 Checksum ::
        4 bytes
-       the first 4 bytes of the SHA256 hash of the contents of the message after the zero byte concatenated with the IV
+       the first 4 bytes of the SHA256 hash of (the contents of the message (after the zero byte) + IV)
 
 Nonzero padding ::
        0 or more bytes
@@ -152,6 +152,8 @@ The padding, if any, must be before the instruction/message pairs.
 There is no provision for padding at the end.
 </li><li>
 The checksum does NOT cover the padding or the zero byte.
+Take the message starting at the first delivery instructions, concatenate the IV,
+and take the Hash of that.
 </li></ul>
 
 
diff --git a/i2p2www/pages/site/docs/tunnels/implementation.html b/i2p2www/pages/site/docs/tunnels/implementation.html
index 3c8989a3..9689b9ef 100644
--- a/i2p2www/pages/site/docs/tunnels/implementation.html
+++ b/i2p2www/pages/site/docs/tunnels/implementation.html
@@ -235,7 +235,10 @@ current IV with AES256/ECB using their IV key again, then forwards the tuple
 {nextTunnelId, nextIV, encryptedData} to the next hop.  This double encryption
 of the IV (both before and after use) help address a certain class of
 confirmation attacks.
-{%- endtrans %}</p>
+{%- endtrans %}
+See <a href="http://osdir.com/ml/network.i2p/2005-07/msg00031.html">this email</a>
+and the surrounding thread for more information.
+</p>
 
 <p>{% trans -%}
 Duplicate message detection is handled by a decaying Bloom filter on message