commit 08b4c89058e7704f9cdb1e11407c7d1c8186c0cd Author: Nick Mathewson <nickm@torproject.org> Date: Tue Nov 27 15:42:00 2012 -0500 Clean up and finish 216-ntor-handshake.txt Remove the PARAMS/PARAMSLEN business I had added: nobody really vetted it. Refer to proposal 200 by number. Add a section at the end to explain where to put keys and everything. --- proposals/000-index.txt | 2 + proposals/216-ntor-handshake.txt | 59 +++++++++++++++++++++++--------------- 2 files changed, 38 insertions(+), 23 deletions(-) diff --git a/proposals/000-index.txt b/proposals/000-index.txt index 4a641a2..72bec71 100644 --- a/proposals/000-index.txt +++ b/proposals/000-index.txt @@ -136,6 +136,7 @@ Proposals by number: 213 Remove stream-level sendmes from the design [OPEN] 214 Allow 4-byte circuit IDs in a new link protocol [OPEN] 215 Let the minimum consensus method change with time [OPEN] +216 Improved circuit-creation key exchange [OPEN] Proposals by status: @@ -187,6 +188,7 @@ Proposals by status: 213 Remove stream-level sendmes from the design 214 Allow 4-byte circuit IDs in a new link protocol 215 Let the minimum consensus method change with time + 216 Improved circuit-creation key exchange ACCEPTED: 140 Provide diffs between consensuses 147 Eliminate the need for v2 directories in generating v3 directories [for 0.2.4.x] diff --git a/proposals/216-ntor-handshake.txt b/proposals/216-ntor-handshake.txt index 081d6af..c6c6579 100644 --- a/proposals/216-ntor-handshake.txt +++ b/proposals/216-ntor-handshake.txt @@ -1,17 +1,17 @@ -Filename: xxx-ntor-handshake.txt +Filename: 216-ntor-handshake.txt Title: Improved circuit-creation key exchange Author: Nick Mathewson Created: 11-May-2011 -Status: Draft +Status: Open +Summary: -This is an attempt to translate the proposed circuit handshake from -"Anonymity and one-way authentication in key-exchange protocols" by -Goldberg, Stebila, and Ustaoglu, into a Tor proposal format. + This is an attempt to translate the proposed circuit handshake from + "Anonymity and one-way authentication in key-exchange protocols" by + Goldberg, Stebila, and Ustaoglu, into a Tor proposal format. -It assumes something like Robert Ransom's proposal draft is in place to -provide an extended CREATE cell format that can indicate what type of -handshake is in use. + It assumes that proposal 200 is implemented, to provide an extended CREATE + cell format that can indicate what type of handshake is in use. Notation: @@ -67,35 +67,25 @@ Protocol: NODEID: ID -- H_LENGTH bytes KEYID: KEYID(B) -- H_LENGTH bytes CLIENT_PK: X -- G_LENGTH bytes - PARAMSLEN: -- 2 bytes - PARMS: -- PARAMSLEN byets - - (The "PARAMS" component is used to encode any additional authenticated - information that's needed for establishing the right kind of circuit. - XXXXX nickm added it; we need to ask if it's safe!!!!) The server generates a keypair of y,Y = KEYGEN(), and computes - secret_input = EXP(X,y) | EXP(X,b) | ID | B | X | Y | PARAMSLEN | PARAMS - | PROTOID + secret_input = EXP(X,y) | EXP(X,b) | ID | B | X | Y | PROTOID KEY_SEED = H(secret_input, t_key) verify = H(secret_input, t_verify) - auth_input = verify | ID | B | Y | X | PARAMSLEN | PARAMS | PROTOID - | "Server" + auth_input = verify | ID | B | Y | X | PROTOID | "Server" The server sends a CREATED cell containing: SERVER_PK: Y -- G_LENGTH bytes AUTH: H(auth_input, t_mac) -- H_LENGTH byets - The client then checks Y is in G^* [see below], and computes + The client then checks Y is in G^* [see NOTE below], and computes - secret_input = EXP(Y,x) | EXP(B,x) | ID | B | X | Y | PARAMSLEN | PARAMS - | PROTOID + secret_input = EXP(Y,x) | EXP(B,x) | ID | B | X | Y | PROTOID KEY_SEED = H(secret_input, t_key) verify = H(secret_input, t_verify) - auth_input = verify | ID | B | Y | X | PARAMLENS | PARAMS | PROTOID - | "Server" + auth_input = verify | ID | B | Y | X | PROTOID | "Server" The client verifies that AUTH == H(auth_input, t_mac). @@ -125,6 +115,8 @@ Key expansion: Ian says this is due to a construction from Krawczyk at http://eprint.iacr.org/2010/264 . + Let m_expand be PROTOID | ":key_expand" + Performance notes: In Tor's current circuit creation handshake, the client does: @@ -149,3 +141,24 @@ Performance notes: 3 H operations for the handshake 3 H operations for the key expansion +Integrating with the rest of Tor: + + Add a new optional entry to router descriptors and microdescriptors: + + "onion-key-ntor" SP Base64Key NL + + where Base64Key is a base-64 encoded 32-byte value, with padding + omitted. + + Add a new consensus method to tell servers to copy "onion-key-ntor" + entries to from router descriptors to microdescriptors. + + Add a "UseNTorHandshake" configuration option and a corresponding + consensus parameter to control whether clients use the ntor + handshake. If the configuration option is "auto", clients should + obey the consensus parameter. Have the configuration default be + "auto" and the consensus value initially be "0". + + Reserve the handshake type [00 01] for this handshake in CREATE2 and + EXTEND2 cells. +