diff options
author | George Kadianakis <desnacked@riseup.net> | 2016-03-18 12:10:35 +0200 |
---|---|---|
committer | George Kadianakis <desnacked@riseup.net> | 2016-04-08 19:25:57 +0300 |
commit | 65f186e80c6ee425c2e9cf479cdf6ca66c51a337 (patch) | |
tree | acc9f40e8854f207f2b1679c78af9eccf5cd76ba /proposals/224-rend-spec-ng.txt | |
parent | 2b8a0103b9f36a0b834ce1bde6608557fe10f866 (diff) | |
download | torspec-65f186e80c6ee425c2e9cf479cdf6ca66c51a337.tar.gz torspec-65f186e80c6ee425c2e9cf479cdf6ca66c51a337.zip |
prop224: Add missing key expansion section for rendezvous crypto.
Diffstat (limited to 'proposals/224-rend-spec-ng.txt')
-rw-r--r-- | proposals/224-rend-spec-ng.txt | 37 |
1 files changed, 33 insertions, 4 deletions
diff --git a/proposals/224-rend-spec-ng.txt b/proposals/224-rend-spec-ng.txt index aee91bf..51d6ea4 100644 --- a/proposals/224-rend-spec-ng.txt +++ b/proposals/224-rend-spec-ng.txt @@ -1144,7 +1144,7 @@ Status: Draft In this older protocol, an ESTABLISH_INTRO cell contains: - KEY_LEN [2 bytes] + KEY_LEN [2 bytes] KEY [KEY_LEN bytes] HANDSHAKE_AUTH [20 bytes] SIG [variable, up to end of relay payload] @@ -1649,10 +1649,39 @@ Status: Draft client containing the contents of the RENDEZVOUS1 cell. Upon receiving the RENDEZVOUS2 cell, the client verifies that the - HANDSHAKE_INFO correctly completes a handshake, and uses the - handshake output to derive shared keys for use on the circuit. + HANDSHAKE_INFO correctly completes a handshake. Now both parties use the + handshake output to derive shared keys for use on the circuit as specified + in the section below: - [TODO: How do we derive shared keys exactly? How do we use NTOR_KEY_SEED?] +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: + + 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: + + 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. + + 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 + the circuit, it authenticates with Df, and encrypts them with the Kf, then + with all of the keys for the ORs in Alice's side of the circuit; and when + Alice's OP receives RELAY cells from the circuit, it decrypts them with the + keys for the ORs in Alice's side of the circuit, then decrypts them with Kb, + and checks integrity with Db. Bob's OP does the same, with Kf and Kb + interchanged. [TODO: Should we encrypt HANDSHAKE_INFO as we did INTRODUCE2 contents? It's not necessary, but it could be wise. Similarly, we |