[tor-commits] [obfsproxy/master] Add missing markers to HMACs.

[asn at torproject.org]

commit d68eb5caa5a85bdef2652cdebb6d3a832c184393
Author: Philipp Winter <phw at torproject.org>
Date:   Sun Mar 9 01:41:28 2014 +0100

    Add missing markers to HMACs.
    
    Thanks to Yawning Angel for catching this.
---
 doc/scramblesuit/scramblesuit-spec.txt |   26 +++++++++++++-------------
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/doc/scramblesuit/scramblesuit-spec.txt b/doc/scramblesuit/scramblesuit-spec.txt
index ee925fa..d910258 100644
--- a/doc/scramblesuit/scramblesuit-spec.txt
+++ b/doc/scramblesuit/scramblesuit-spec.txt
@@ -65,7 +65,7 @@
     The mark is used to easily locate the MAC which is the last element of the
     client's handshake message.  The 16-byte MAC is defined as:
 
-      MAC = HMAC-SHA256-128(k_B, X | P_C | E)
+      MAC = HMAC-SHA256-128(k_B, X | P_C | M_C | E)
 
     The variable E is a string representation of the current Unix epoch divided
     by 3600.  It represents the amount of hours which have passed since the
@@ -121,7 +121,7 @@
     authenticate outgoing data.  It is derived from k_t (which is embedded in
     the ticket) as described in Section 2.3.  The MAC is defined as:
 
-      MAC = HMAC-SHA256-128(k_sh, T | P | E)
+      MAC = HMAC-SHA256-128(k_sh, T | P | M | E)
 
     The variable E is a string representation of the current Unix epoch divided
     by 3600.  It represents the amount of hours which have passed since the
@@ -130,13 +130,13 @@
     "382991".  While the client MUST determine E, the server can simply echo
     the client's E in its response.
 
-    Client                         Server  Legend:
-      |  T | P | M | MAC(T | P | E)  |     T: session ticket
-      | ---------------------------> |     P: random padding
-      |      AEnc(k_t+1 | T_t+1)     |     M: mark to locate the MAC
-      | <--------------------------- |     E: approximate timestamp
-      |       AEnc(Tor traffic)      |     k_t+1: future master key
-      | <--------------------------> |     T_t+1: future ticket
+    Client                            Server   Legend:
+      |  T | P | M | MAC(T | P | M | E)  |     T: session ticket
+      | -------------------------------> |     P: random padding
+      |        AEnc(k_t+1 | T_t+1)       |     M: mark to locate the MAC
+      | <------------------------------- |     E: approximate timestamp
+      |         AEnc(Tor traffic)        |     k_t+1: future master key
+      | <------------------------------> |     T_t+1: future ticket
 
     The server is initially unable to distinguish between a session ticket
     handshake and a UniformDH handshake as both handshakes are computationally
@@ -144,10 +144,10 @@
     opportunistically decrypt the session ticket T after verifying its MAC.  If
     the ticket's MAC (which should not be confused with the handshake message's
     MAC) is valid and the ticket can be decrypted and is not yet expired, the
-    server then verifies the MAC which is built over T | P | E.  If this MAC is
-    valid, the handshake succeeded.  The server, like the client, then proceeds
-    to derive session keys from the 256-bit master key as described in Section
-    2.3.
+    server then verifies the MAC which is built over T | P | M | E.  If this
+    MAC is valid, the handshake succeeded.  The server, like the client, then
+    proceeds to derive session keys from the 256-bit master key as described in
+    Section 2.3.
 
     After a ticket handshake succeeded, the server replies by issuing a new
     session ticket T_t+1 together with the according master key k_t+1.  The