- tor-commits - lists.torproject.org

[tor/master] Merge remote-tracking branch 'origin/maint-0.2.1' into maint-0.2.2
by nickm＠torproject.org 12 May '11

12 May '11

commit 8057b7363ecb3fdc6dcd41d8f975bb50ef1bf6ea Merge: 7206d78 d1c7f65 Author: Nick Mathewson <nickm(a)torproject.org> Date: Wed May 11 22:52:26 2011 -0400 Merge remote-tracking branch 'origin/maint-0.2.1' into maint-0.2.2 changes/bug3135 | 6 ++++++ src/or/config.c | 2 +- 2 files changed, 7 insertions(+), 1 deletions(-)

1 0

[tor/master] Merge remote-tracking branch 'origin/maint-0.2.2'
by nickm＠torproject.org 12 May '11

12 May '11

commit 7649adbce60c7ab615e233f9e9ce41c22df8134c Merge: 6d5478a 8057b73 Author: Nick Mathewson <nickm(a)torproject.org> Date: Wed May 11 22:55:29 2011 -0400 Merge remote-tracking branch 'origin/maint-0.2.2' changes/bug3135 | 6 ++++++ src/or/config.c | 2 +- 2 files changed, 7 insertions(+), 1 deletions(-)

1 0

[tor/maint-0.2.2] Merge branch 'bug3135' into maint-0.2.1
by nickm＠torproject.org 12 May '11

12 May '11

commit d1c7f65a8e76b594c63bf23baf7fb6c19ba44c00 Merge: e7b10e5 13847b8 Author: Nick Mathewson <nickm(a)torproject.org> Date: Wed May 11 22:49:44 2011 -0400 Merge branch 'bug3135' into maint-0.2.1 changes/bug3135 | 6 ++++++ src/or/config.c | 2 +- 2 files changed, 7 insertions(+), 1 deletions(-)

1 0

[tor/maint-0.2.2] Merge remote-tracking branch 'origin/maint-0.2.1' into maint-0.2.2
by nickm＠torproject.org 12 May '11

12 May '11

commit 8057b7363ecb3fdc6dcd41d8f975bb50ef1bf6ea Merge: 7206d78 d1c7f65 Author: Nick Mathewson <nickm(a)torproject.org> Date: Wed May 11 22:52:26 2011 -0400 Merge remote-tracking branch 'origin/maint-0.2.1' into maint-0.2.2 changes/bug3135 | 6 ++++++ src/or/config.c | 2 +- 2 files changed, 7 insertions(+), 1 deletions(-)

1 0

[tor/maint-0.2.2] Fix crash when read_file_to_string() fails in SAVECONF
by nickm＠torproject.org 12 May '11

12 May '11

commit 13847b8db6b676c4f2951a4195758f395b7551a8 Author: Nick Mathewson <nickm(a)torproject.org> Date: Wed May 11 22:05:41 2011 -0400 Fix crash when read_file_to_string() fails in SAVECONF The new behavior is to try to rename the old file if there is one there that we can't read. In all likelihood, that will fail too, but at least we tried, and at least it won't crash. --- changes/bug3135 | 6 ++++++ src/or/config.c | 2 +- 2 files changed, 7 insertions(+), … [View More]

1 0

[tor/maint-0.2.1] Fix crash when read_file_to_string() fails in SAVECONF
by nickm＠torproject.org 12 May '11

12 May '11

commit 13847b8db6b676c4f2951a4195758f395b7551a8 Author: Nick Mathewson <nickm(a)torproject.org> Date: Wed May 11 22:05:41 2011 -0400 Fix crash when read_file_to_string() fails in SAVECONF The new behavior is to try to rename the old file if there is one there that we can't read. In all likelihood, that will fail too, but at least we tried, and at least it won't crash. --- changes/bug3135 | 6 ++++++ src/or/config.c | 2 +- 2 files changed, 7 insertions(+), … [View More]

1 0

[tor/maint-0.2.1] Merge branch 'bug3135' into maint-0.2.1
by nickm＠torproject.org 12 May '11

12 May '11

commit d1c7f65a8e76b594c63bf23baf7fb6c19ba44c00 Merge: e7b10e5 13847b8 Author: Nick Mathewson <nickm(a)torproject.org> Date: Wed May 11 22:49:44 2011 -0400 Merge branch 'bug3135' into maint-0.2.1 changes/bug3135 | 6 ++++++ src/or/config.c | 2 +- 2 files changed, 7 insertions(+), 1 deletions(-)

1 0

[torspec/master] incoporate stuff based on comments from Ian Goldberg
by nickm＠torproject.org 11 May '11

11 May '11

commit e41c19325bdcf967841a81dfef7083a089429853 Author: Nick Mathewson <nickm(a)torproject.org> Date: Wed May 11 15:43:29 2011 -0400 incoporate stuff based on comments from Ian Goldberg --- proposals/ideas/xxx-ntor-handshake.txt | 33 ++++++++++++++++++++++++------- 1 files changed, 25 insertions(+), 8 deletions(-) diff --git a/proposals/ideas/xxx-ntor-handshake.txt b/proposals/ideas/xxx-ntor-handshake.txt index 54c81b0..41af5c7 100644 --- a/proposals/ideas/xxx-ntor-handshake.… [View More]txt +++ b/proposals/ideas/xxx-ntor-handshake.txt @@ -27,6 +27,10 @@ Notation: byte strings, are all G_LENGTH bytes long. Let's say we are using a generator g for this group. + Let a,A=KEYGEN() yield a new private-public keypair in G, where a is the + secret key and A = EXP(g,a). If additional checks are needed to insure + a valid keypair, they should be performed. + Let PROTOID be a string designating this variant of the protocol. Let KEYID be a collision-resistant (but not necessarily preimage-resistant) @@ -34,13 +38,17 @@ Notation: Instantiation: - Let's call this PROTOID "ntor-curve25519-sha256-1" + Let's call this PROTOID "ntor-curve25519-sha256-1" (We might want to make + this shorter if it turns out to save us a block of hashing somewhere.) 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) == curve25519(a,b), and g == 9 . + + Set EXP(a,b) == curve25519(.,b,a), and g == 9 . Let KEYGEN() do the + appropriate manipulations when generating the secret key (clearing the + low bits, twiddling the high bits). 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 @@ -51,16 +59,16 @@ 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. + B with b, B = KEYGEN(). The router publishes B in its server descriptor. - To send a create cell, the client generates a keypair of x, X=EXP(g,x) and + To send a create cell, the client generates a keypair x,X = KEYGEN(), and sends a CREATE cell with contents: NODEID: ID -- H_LENGTH bytes KEYID: KEYID(B) -- H_LENGTH bytes CLIENT_PK: X -- G_LENGTH bytes - The server checks X, generates a keypair of y, Y=EXP(g,y) and computes + The server generates a keypair of y,Y = KEYGEN(), and computes secret_input = EXP(X,y) | EXP(X,b) | ID | B | X | Y | PROTOID KEY_SEED = H(secret_input, t_key) @@ -72,7 +80,7 @@ Protocol: SERVER_PK: Y -- G_LENGTH bytes AUTH: H(auth_input, t_mac) -- H_LENGTH byets - The client then checks Y, and computes + The client then checks Y is in G^* [see below], and computes secret_input = EXP(Y,x) | EXP(B,x) | ID | B | X | Y | PROTOID KEY_SEED = H(secret_input, t_key) @@ -81,6 +89,9 @@ Protocol: The client verifies that AUTH == H(auth_input, t_mac). + [NOTE: It may be adequate to check that EXP(Y,x) is not the point at + infinity. See tor-dev thread.] + Both parties now have a shared value for KEY_SEED. They expand this into the keys needed for the Tor relay protocol. @@ -94,9 +105,15 @@ Key expansion: Instead, let's have it be - K = H(KEY_SEED, t_expand1) | H(KEY_SEED, t_expand2) | ... + K = K_0 | K_1 | K_2 | K_3 | ... + + Where K_0 = H(m_expand | INT8(i) , KEY_SEED ) + and K_(i+1) = H(K_i | m_expand | INT8(i) , KEY_SEED ) + and m_expend is an arbitrarily chosen value, + and INT8(i) is a octet with the value "i". - where t_expand1..N are tweaks for the hash. + Ian says this is due to a construction from Krawczyk at + http://eprint.iacr.org/2010/264 . Performance notes: [View Less]

1 0

[torspec/master] Trivial fixes in proposals/ideas/xxx-ntor-handshake.txt
by nickm＠torproject.org 11 May '11

11 May '11

commit 1dfb05ca8798934522777fb39a7c2c22ca5761e4 Author: George Kadianakis <desnacked(a)gmail.com> Date: Wed May 11 20:40:03 2011 +0200 Trivial fixes in proposals/ideas/xxx-ntor-handshake.txt --- proposals/ideas/xxx-ntor-handshake.txt | 14 +++++++------- 1 files changed, 7 insertions(+), 7 deletions(-) diff --git a/proposals/ideas/xxx-ntor-handshake.txt b/proposals/ideas/xxx-ntor-handshake.txt index b39a39f..54c81b0 100644 --- a/proposals/ideas/xxx-ntor-handshake.txt +++ b/… [View More]proposals/ideas/xxx-ntor-handshake.txt @@ -19,7 +19,7 @@ Notation: Let H(x,t) be a tweakable hash function of output width H_LENGTH bytes. - Let t_keyid, t_mac, t_key, and t_verify be a set of arbitrarily-chosen tweaks + 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 @@ -38,13 +38,13 @@ Instantiation: Set H(x,t) == HMAC_SHA256 with message x and key t. So H_LENGTH == 32. Set t_mac == PROTOID | ":mac" - t_key1 == PROTOID | ":key1" - t_key2 == PROTOID | ":verify" + t_key == PROTOID | ":key" + t_verify == PROTOID | ":verify" Set EXP(a,b) == curve25519(a,b), 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.) + KEYID(A)==KEYID(B) iff A==B.) Protocol: @@ -53,7 +53,7 @@ Protocol: 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 a keypair of x, X=EXP(g,y) and + To send a create cell, the client generates a keypair of x, X=EXP(g,x) and sends a CREATE cell with contents: NODEID: ID -- H_LENGTH bytes @@ -75,7 +75,7 @@ Protocol: The client then checks Y, and computes secret_input = EXP(Y,x) | EXP(B,x) | ID | B | X | Y | PROTOID - KEY_SEED = H(secret_input, t_key1) + KEY_SEED = H(secret_input, t_key) verify = H(secret_input, t_verify) auth_input = verify | ID | B | Y | X | PROTOID | "Server" @@ -88,7 +88,7 @@ Key expansion: Currently, the key expansion formula used by Tor here is - K = SHA(K0 | [00]) | SHA(K0 | [01]) | SHH(K0 | [02]) | ... + K = SHA(K0 | [00]) | SHA(K0 | [01]) | SHA(K0 | [02]) | ... where K0==g^xy, and K is divvied up into Df, Db, Kf, and Kb portions. [View Less]

1 0

[torspec/master] Add proposal basd on key-exchange paper by Goldberg, Stebila, Ustaoglu
by nickm＠torproject.org 11 May '11

11 May '11

commit 9fabb940723ca01c56aeb763c59ebcea8f8bd775 Author: Nick Mathewson <nickm(a)torproject.org> Date: Wed May 11 13:34:05 2011 -0400 Add proposal basd on key-exchange paper by Goldberg, Stebila, Ustaoglu --- proposals/ideas/xxx-ntor-handshake.txt | 124 ++++++++++++++++++++++++++++++++ 1 files changed, 124 insertions(+), 0 deletions(-) diff --git a/proposals/ideas/xxx-ntor-handshake.txt b/proposals/ideas/xxx-ntor-handshake.txt new file mode 100644 index 0000000..b39a39f --- /dev/… [View More]null +++ b/proposals/ideas/xxx-ntor-handshake.txt @@ -0,0 +1,124 @@ +Filename: xxx-ntor-handshake.txt +Title: Improved circuit-creation key exchange +Author: Nick Mathewson +Created: 11-May-2011 +Status: Draft + + +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. + +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_keyid, 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 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 "ntor-curve25519-sha256-1" + + Set H(x,t) == HMAC_SHA256 with message x and key t. So H_LENGTH == 32. + Set t_mac == PROTOID | ":mac" + t_key1 == PROTOID | ":key1" + t_key2 == PROTOID | ":verify" + Set EXP(a,b) == curve25519(a,b), 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 a keypair of x, X=EXP(g,y) and + sends a CREATE cell with contents: + + NODEID: ID -- H_LENGTH bytes + KEYID: KEYID(B) -- H_LENGTH bytes + CLIENT_PK: X -- G_LENGTH bytes + + The server checks X, generates a keypair of y, Y=EXP(g,y) and computes + + 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 | 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, and computes + + secret_input = EXP(Y,x) | EXP(B,x) | ID | B | X | Y | PROTOID + KEY_SEED = H(secret_input, t_key1) + verify = H(secret_input, t_verify) + auth_input = verify | ID | B | Y | X | PROTOID | "Server" + + The client verifies that AUTH == H(auth_input, t_mac). + + Both parties now have a shared value for KEY_SEED. They expand this into + the keys needed for the Tor relay protocol. + +Key expansion: + + Currently, the key expansion formula used by Tor here is + + K = SHA(K0 | [00]) | SHA(K0 | [01]) | SHH(K0 | [02]) | ... + + where K0==g^xy, and K is divvied up into Df, Db, Kf, and Kb portions. + + Instead, let's have it be + + K = H(KEY_SEED, t_expand1) | H(KEY_SEED, t_expand2) | ... + + where t_expand1..N are tweaks for the hash. + +Performance notes: + + In Tor's current circuit creation handshake, the client does: + One RSA public-key encryption + A full DH handshake in Z_p + A short AES encryption + Five SHA1s for key expansion + And the server does: + One RSA private-key decryption + A full DH handshake in Z_p + A short AES decryption + Five SHA1s for key expansion + + While in the revised handshake, the client does: + A full DH handshake + A public-half of a DH handshake + 3 H operations for the handshake + 3 H operations for the key expansion + and the server does: + A full DH handshake + A private-half of a DH handshake + 3 H operations for the handshake + 3 H operations for the key expansion + [View Less]

1 0