[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