[tor-commits] [torspec/master] prop224: Fix undefined variables in the ntor section.

asn at torproject.org asn at torproject.org
Sat Apr 9 11:15:20 UTC 2016


commit 191e93cc6e0a126006c61b3eb3f46f4491c6a6af
Author: George Kadianakis <desnacked at riseup.net>
Date:   Fri Apr 8 19:15:14 2016 +0300

    prop224: Fix undefined variables in the ntor section.
---
 proposals/224-rend-spec-ng.txt | 32 ++++++++++++++++----------------
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/proposals/224-rend-spec-ng.txt b/proposals/224-rend-spec-ng.txt
index d80b2d5..8e14e2a 100644
--- a/proposals/224-rend-spec-ng.txt
+++ b/proposals/224-rend-spec-ng.txt
@@ -1445,6 +1445,8 @@ Status: Draft
    We also use the following tweak values:
 
       t_hsenc    = PROTOID | ":hs_key_extract"
+      t_hsverify = PROTOID | ":hs_verify"
+      t_hsmac    = PROTOID | ":hs_mac"
       m_hsexpand = PROTOID | ":hs_key_expand"
 
    To make an INTRODUCE1 cell, the client must know a public encryption
@@ -1454,8 +1456,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 = HKDF(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]
 
@@ -1510,31 +1511,28 @@ Status: Draft
    service host generates a keypair of y,Y = KEYGEN(), and uses its
    introduction point encryption key 'b' to computes:
 
-      xb = EXP(X,b)
-
-      secret_hs_input = xb | AUTH_KEYID | X | B | PROTOID
+      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 = HKDF(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]
 
       (The above are used to check the MAC and then decrypt the
       encrypted data.)
 
-      ntor_secret_input = EXP(X,y) | xb | ID | B | X | Y | PROTOID
-      NTOR_KEY_SEED = H(secret_input, t_key)
-      verify = H(secret_input, t_verify)
-      auth_input = verify | ID | B | Y | X | PROTOID | "Server"
+      ntor_secret_input = EXP(X,y) | EXP(X,b) | AUTH_KEYID | B | X | Y | PROTOID
+      NTOR_KEY_SEED = MAC(ntor_secret_input, t_hsenc)
+      verify = MAC(ntor_secret_input, t_hsverify)
+      auth_input = verify | AUTH_KEYID | B | Y | X | PROTOID | "Server"
 
       (The above are used to finish the ntor handshake.)
 
    The server's handshake reply is:
-       SERVER_PK   Y                       [G_LEN bytes]
-       AUTH        H(auth_input, t_mac)    [H_LEN bytes]
+       SERVER_PK   Y                         [G_LEN bytes]
+       AUTH        MAC(auth_input, t_hsmac)  [H_LEN bytes]
 
-   These faileds can be send to the client in a RENDEZVOUS1 cell.
-   (See [JOIN_REND] below.)
+   These fields will be sent to the client in a RENDEZVOUS1 cell using the
+   HANDSHAKE_INFO element (see [JOIN_REND]).
 
    The hidden service host now also knows the keys generated by the
    handshake, which it will use to encrypt and authenticate data
@@ -1578,7 +1576,7 @@ Status: Draft
    to authenticate. [TODO: should this be an identifier for the public
    key instead?]  Signature is the signature, using Ed25519, of:
 
-        "Hidserv-userauth-ed25519"
+        "hidserv-userauth-ed25519"
         Nonce       (same as above)
         Pubkey      (same as above)
         AUTH_KEYID  (As in the INTRODUCE1 cell)
@@ -1653,6 +1651,8 @@ Status: Draft
    HANDSHAKE_INFO correctly completes a handshake, and uses the
    handshake output to derive shared keys for use on the circuit.
 
+   [TODO: How do we derive shared keys exactly? How do we use NTOR_KEY_SEED?]
+
    [TODO: Should we encrypt HANDSHAKE_INFO as we did INTRODUCE2
    contents? It's not necessary, but it could be wise. Similarly, we
    should make it extensible.]





More information about the tor-commits mailing list