commit 191e93cc6e0a126006c61b3eb3f46f4491c6a6af Author: George Kadianakis desnacked@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.]