commit ebc735e69071bc5cf7d71ce47a1d269fa280077b Author: Nick Mathewson nickm@torproject.org Date: Wed Nov 20 10:59:33 2013 -0500

Add 223-ace-handshake.txt --- proposals/000-index.txt | 2 + proposals/223-ace-handshake.txt | 115 +++++++++++++++++++++++++++++++++++++++ 2 files changed, 117 insertions(+)

diff --git a/proposals/000-index.txt b/proposals/000-index.txt index 75ea52b..99845a4 100644 --- a/proposals/000-index.txt +++ b/proposals/000-index.txt @@ -143,6 +143,7 @@ Proposals by number: 220 Migrate server identity keys to Ed25519 [DRAFT] 221 Stop using CREATE_FAST [CLOSED] 222 Stop sending client timestamps [CLOSED] +223 Ace: Improved circuit-creation key exchange [OPEN]

Proposals by status: @@ -188,6 +189,7 @@ Proposals by status: 211 Internal Mapaddress for Tor Configuration Testing [for 0.2.4.x+] 212 Increase Acceptable Consensus Age [for 0.2.4.x+] 215 Let the minimum consensus method change with time + 223 Ace: 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/223-ace-handshake.txt b/proposals/223-ace-handshake.txt new file mode 100644 index 0000000..78592a3 --- /dev/null +++ b/proposals/223-ace-handshake.txt @@ -0,0 +1,115 @@ +Filename: 223-ace-handshake.txt +Title: Ace: Improved circuit-creation key exchange +Author: Esfandiar Mohammadi +Created: 22-July-2013 +Status: Open + +History: + + 22-July-2013 -- Submitted + 20-Nov-2013 -- Reformatted slightly, wrapped lines, added + references, adjusted the KDF [nickm] + +Summary: + +This is an attempt to translate the proposed circuit handshake from +"Ace: An Efficient Key-Exchange Protocol for Onion Routing" by +Backes, Kate, and Mohammadi into a Tor proposal format. + +The specification assumes an implementation of scalar multiplication +and addition of two curve elements, as in Robert Ransom's celator +library. + +Notation: + + Let a|b be the concatenation of a with b. + + Let H(x,t) be a tweakable hash function of output width H_LENGTH + bytes. + + Let t_mac, t_key, and t_verify be a set of arbitrarily-chosen + tweaks for the hash function. + + Let EXP(a,b) be a^b in some appropriate group G where the + appropriate DH parameters hold. Let's say elements of this group, + when represented as byte strings, are all G_LENGTH bytes long. + Let's say we are using a generator g for this group. + + Let MUTLIEXPONEN (a,b,c,d) be (a^b)*(c^d) in some appropriate + group G where the appropriate DH parameters hold. Let's say + elements of this group, when represented as byte strings, are all + G_LENGTH bytes long. Let's say we are using a generator g for + this group. + + Let PROTOID be a string designating this variant of the protocol. + + Let KEYID be a collision-resistant (but not necessarily preimage-resistant) + hash function on members of G, of output length H_LENGTH bytes. + +Instantiation: + + Let's call this PROTOID "ace-curve25519-ed-uncompressed-sha256-1" + + Set H(x,t) == HMAC_SHA256 with message x and key t. So H_LENGTH == 32. + Set t_mac == PROTOID | ":mac" + t_key == PROTOID | ":key" + t_verify == PROTOID | ":verify" + Set EXP(a,b) == scalar_mult_curve25519(a,b), + MUTLIEXPONEN(a,b) == dblscalarmult_curve25519(a,b,c,d), and g == 9 . + + Set KEYID(B) == B. (We don't need to use a hash function here, since our + keys are already very short. It is trivially collision-resistant, since + KEYID(A)==KEYID(B) iff A==B.) + +Protocol: + + Take a router with identity key digest ID. + + As setup, the router generates a secret key b, and a public onion key + B = EXP(g,b). The router publishes B in its server descriptor. + + To send a create cell, the client generates two keypairs of x_1, + X_1=EXP(g,x_1) and x_2, X_2=EXP(g,x_2) and sends a CREATE cell + with contents: + + NODEID: ID -- H_LENGTH bytes + KEYID: KEYID(B) -- H_LENGTH bytes + CLIENT_PK: X_1, X_2 -- 2 x G_LENGTH bytes + + The server checks X_1, X_2, generates a keypair of y, Y=EXP(g,y) + and computes + + point = MUTLIEXPONEN(X_1,y,X_2,b) + secret_input = point | ID | B | X_1 | X_2 | Y | PROTOID + KEY_SEED = H(secret_input | "Key Seed", t_key) + KEY_VERIFY = H(secret_input | "HMac Seed", t_verify) + auth_input = ID | Y | X_1 | X_2 | PROTOID | "Server" + + The server sends a CREATED cell containing: + + SERVER_PK: Y -- G_LENGTH bytes + AUTH: H(auth_input, KEY_VERIFY) -- H_LENGTH bytes + + The client then checks Y, and computes + + point = MUTLIEXPONEN(Y,x_1,B,x_2) + secret_input = | ID | B | X_1 | X_2 | Y | PROTOID + KEY_SEED = H(secret_input | "Key Seed", t_key) + KEY_VERIFY = H(secret_input | "HMac Seed", t_verify) + auth_input = ID | B | Y | X_1 | X_2 | PROTOID | "Server" + + The client verifies that AUTH == H(auth_input, KEY_VERIFY). + + Both parties now have a shared value for KEY_SEED. They expand + this into the keys needed for the Tor relay protocol. + +Key expansion: + + When using this handshake, clients and servers should expand keys + using HKDF as with the ntor handshake today. + +See also: + + http://www.infsec.cs.uni-saarland.de/~mohammadi/ace/ace.html + for implementations, academic paper, and benchmarking code. +