[tor-commits] [torspec/master] prop224: Fix crypto issues pointed out by Nick.

[asn at torproject.org]

commit f2cfab04187e593b9ec28a7ebd95e674510ccbab
Author: George Kadianakis <desnacked at riseup.net>
Date:   Wed Apr 13 17:20:54 2016 +0300

    prop224: Fix crypto issues pointed out by Nick.
    
    - No point in using SHAKE *with* HKDF. Just use SHAKE.
    - Use our KDF to do key expansion for rendezvous crypto.
---
 proposals/224-rend-spec-ng.txt | 31 +++++++++++--------------------
 1 file changed, 11 insertions(+), 20 deletions(-)

diff --git a/proposals/224-rend-spec-ng.txt b/proposals/224-rend-spec-ng.txt
index 833224b..1edbc08 100644
--- a/proposals/224-rend-spec-ng.txt
+++ b/proposals/224-rend-spec-ng.txt
@@ -125,8 +125,7 @@ Status: Draft
       * A cryptographic message authentication code MAC(key,msg) that
         produces outputs of length MAC_LEN bytes.
 
-      * A key derivation function KDF(key data, salt, personalization,
-        n) that outputs n bytes.
+      * A key derivation function KDF(message, n) that outputs n bytes.
 
    As a first pass, I suggest:
 
@@ -141,7 +140,7 @@ Status: Draft
 
       * Instantiate MAC(key=k, message=m) with H(k || m).
 
-      * Instantiate KDF with HKDF using SHAKE-256.
+      * Instantiate KDF with SHAKE-256.
 
    For legacy purposes, we specify compatibility with older versions of
    the Tor introduction point and rendezvous point protocols. These used
@@ -952,7 +951,7 @@ Status: Draft
 
        secret_input = blinded_public_key(replica-keynum) |
              subcredential | INT_4(revision_counter)
-       keys = KDF(secret_input, salt, "hsdir-encrypted-data",
+       keys = KDF(secret_input | salt | "hsdir-encrypted-data",
                   S_KEY_LEN + S_IV_LEN + MAC_KEY_LEN)
 
        SECRET_KEY = first S_KEY_LEN bytes of keys
@@ -1381,7 +1380,7 @@ Status: Draft
    and computes:
              secret_hs_input = EXP(B,x) | AUTH_KEYID | X | B | PROTOID
              info = m_hsexpand | subcredential
-             hs_keys = HKDF(secret_hs_input, t_hsenc, info, S_KEY_LEN+MAC_LEN)
+             hs_keys = KDF(secret_hs_input | t_hsenc | info, S_KEY_LEN+MAC_LEN)
              ENC_KEY = hs_keys[0:S_KEY_LEN]
              MAC_KEY = hs_keys[S_KEY_LEN:S_KEY_LEN+MAC_KEY_LEN]
 
@@ -1438,7 +1437,7 @@ Status: Draft
 
       secret_hs_input = EXP(X,b) | AUTH_KEYID | X | B | PROTOID
       info = m_hsexpand | subcredential
-      hs_keys = HKDF(secret_hs_input, t_hsenc, info, S_KEY_LEN+MAC_LEN)
+      hs_keys = KDF(secret_hs_input | t_hsenc | info, S_KEY_LEN+MAC_LEN)
       HS_DEC_KEY = hs_keys[0:S_KEY_LEN]
       HS_MAC_KEY = hs_keys[S_KEY_LEN:S_KEY_LEN+MAC_KEY_LEN]
 
@@ -1580,23 +1579,15 @@ Status: Draft
 4.2.1. Key expansion
 
    The hidden service and its client need to derive crypto keys from the
-   NTOR_KEY_SEED part of the handshake output. To do so, they use the key
-   expansion construction specified in prop216:
+   NTOR_KEY_SEED part of the handshake output. To do so, they use the KDF
+   construction as follows:
 
-       K = K_1 | K_2 | K_3 | ...
-
-       Where K_1     = MAC(NTOR_KEY_SEED, m_hsexpand | INT8(1))
-         and K_(i+1) = MAC(NTOR_KEY_SEED, K_i | m_hsexpand | INT8(i))
-         and INT8(i) is a octet with the value "i".
-
-
-   The key material is then used to generate KH, Df, Db, Kf, and Kb as in the
-   KDF-TOR key derivation approach documented in tor-spec.txt:
+       K = KDF(NTOR_KEY_SEED | m_hsexpand,    HASH_LEN * 3 + S_KEY_LEN * 2)
 
    The first HASH_LEN bytes of K form KH; the next HASH_LEN form the forward
-   digest Df; the next HASH_LEN 41-60 form the backward digest Db; the next
-   KEY_LEN 61-76 form Kf, and the final KEY_LEN form Kb.  Excess bytes from K
-   are discarded.
+   digest Df; the next HASH_LEN bytes form the backward digest Db; the next
+   S_KEY_LEN bytes form Kf, and the final S_KEY_LEN bytes form Kb.  Excess
+   bytes from K are discarded.
 
    Subsequently, the rendezvous point passes relay cells, unchanged, from each
    of the two circuits to the other.  When Alice's OP sends RELAY cells along