- tor-commits - lists.torproject.org

[tor/master] Merge branch 'bug7013_take2_squashed'
by nickm＠torproject.org 28 Nov '12

28 Nov '12

commit 190c1d4981e5751aabd3d894095851c830f1d570 Merge: 267c0e5 6f21d2e Author: Nick Mathewson <nickm(a)torproject.org> Date: Tue Nov 27 22:18:16 2012 -0500 Merge branch 'bug7013_take2_squashed' changes/bug7013 | 4 ++ doc/tor.1.txt | 5 +++ src/common/address.c | 41 +++++++++++++++++++++- src/common/address.h | 3 ++ src/or/config.c | 94 ++++++++++++++++++++++++++++++++++++++++++++++++++ src/or/config.h | 2 + src/or/or.h | 3 ++ src/or/statefile.c | 11 +++++- src/test/test_addr.c | 53 ++++++++++++++++++++++++++++ 9 files changed, 214 insertions(+), 2 deletions(-) diff --cc src/or/config.c index 206ccc8,48e33b9..75f6193 --- a/src/or/config.c +++ b/src/or/config.c @@@ -276,8 -272,8 +276,9 @@@ static config_var_t option_vars_[] = V(HTTPProxyAuthenticator, STRING, NULL), V(HTTPSProxy, STRING, NULL), V(HTTPSProxyAuthenticator, STRING, NULL), + V(IPv6Exit, BOOL, "0"), VAR("ServerTransportPlugin", LINELIST, ServerTransportPlugin, NULL), + V(ServerTransportListenAddr, LINELIST, NULL), V(Socks4Proxy, STRING, NULL), V(Socks5Proxy, STRING, NULL), V(Socks5ProxyUsername, STRING, NULL),

1 0

[torspec/master] Add proposal 217: Tor Extended ORPort Authentication
by nickm＠torproject.org 28 Nov '12

28 Nov '12

commit 1d6ada880b389cb61a52ab120cb5a55a71292b6d Author: Nick Mathewson <nickm(a)torproject.org> Date: Tue Nov 27 19:59:34 2012 -0500 Add proposal 217: Tor Extended ORPort Authentication --- proposals/000-index.txt | 2 + proposals/217-ext-orport-auth.txt | 177 +++++++++++++++++++++++++++++++++++++ 2 files changed, 179 insertions(+), 0 deletions(-) diff --git a/proposals/000-index.txt b/proposals/000-index.txt index 72bec71..5865e78 100644 --- a/proposals/000-index.txt +++ b/proposals/000-index.txt @@ -137,6 +137,7 @@ Proposals by number: 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] +217 Tor Extended ORPort Authentication [OPEN] Proposals by status: @@ -189,6 +190,7 @@ Proposals by status: 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 + 217 Tor Extended ORPort Authentication [for 0.2.5.x] 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/217-ext-orport-auth.txt b/proposals/217-ext-orport-auth.txt new file mode 100644 index 0000000..1206234 --- /dev/null +++ b/proposals/217-ext-orport-auth.txt @@ -0,0 +1,177 @@ +Filename: 217-ext-orport-auth.txt +Title: Tor Extended ORPort Authentication +Author: George Kadianakis +Created: 28-11-2012 +Status: Open +Target: 0.2.5.x + +1. Overview + + This proposal defines a scheme for Tor components to authenticate to + each other using a shared-secret. + +2. Motivation + + Proposal 196 introduced new ways for pluggable transport proxies to + communicate with Tor. The communication happens using TCP in the same + fashion that controllers speak to the ControlPort. + + To defend against cross-protocol attacks [0] on the transport ports, + we need to define an authentication scheme that will restrict passage + to unknown clients. + + Tor's ControlPort uses an authentication scheme called safe-cookie + authentication [1]. Unfortunately, the design of the safe-cookie + authentication was influenced by the protocol structure of the + ControlPort and the need for backwards compatibility of the + cookie-file and can't be easily reused in other use cases. + +3. Goals + + The general goal of Extended ORPort authentication is to authenticate + the client based on a shared-secret that only authorized clients + should know. + + Furthermore, its implementation should be flexible and easy to reuse, + so that it can be used as the authentication mechanism in front of + future Tor helper ports (for example, in proposal 199). + + Finally, the protocol is able to support multiple authentication + schemes and each of them has different goals. + +4. Protocol Specification + +4.1. Initial handshake + + When a client connects to the Extended ORPort, the server sends: + + AuthTypes [variable] + EndAuthTypes [1 octet] + + Where, + + + AuthTypes are the authentication schemes that the server supports + for this session. They are multiple concatenated 1-octet values that + take values from 1 to 255. + + EndAuthTypes is the special value 0. + + The client reads the list of supported authentication schemes and + replies with the one he prefers to use: + + AuthType [1 octet] + + Where, + + + AuthType is the authentication scheme that the client wants to use + for this session. A valid authentication type takes values from 1 to + 255. A value of 0 means that the client did not like the + authentication types offered by the server. + + If the client sent an AuthType of value 0, or an AuthType that the + server does not support, the server MUST close the connection. + +4.2. Authentication types + +4.2.1 SAFE_COOKIE handshake + + Authentication type 1 is called SAFE_COOKIE. + +4.2.1.1. Motivation and goals + + The SAFE_COOKIE scheme is pretty-much identical to the authentication + scheme that was introduced for the ControlPort in proposal 193. + + An additional goal of the SAFE_COOKIE authentication scheme (apart + from the goals of section 2), is that it should not leak the contents + of the cookie-file to untrusted parties. + + Specifically, the SAFE_COOKIE protocol will never leak the actual + contents of the file. Instead, it uses a challenge-response protocol + (similar to the HTTP digest authentication of RFC2617) to ensure that + both parties know the cookie without leaking it. + +4.2.1.2. Cookie-file format + + The format of the cookie-file is: + + StaticHeader [32 octets] + Cookie [32 octets] + + Where, + + StaticHeader is the following string: + "! Extended ORPort Auth Cookie !\x0a" + + Cookie is the shared-secret. During the SAFE_COOKIE protocol, the + cookie is called CookieString. + + Extended ORPort clients MUST make sure that the StaticHeader is + present in the cookie file, before proceeding with the + authentication protocol. + + Details on how Tor locates the cookie file can be found in section 5 + of proposal 196. Details on how transport proxies locate the cookie + file can be found in pt-spec.txt. + +4.2.1.3. Protocol specification + + A client that performs the SAFE_COOKIE handshake begins by sending: + + ClientNonce [32 octets] + + Where, + + ClientNonce is 32 octets of random data. + + Then, the server replies with: + + ServerHash [32 octets] + ServerNonce [32 octets] + + Where, + + ServerHash is computed as: + HMAC-SHA256(CookieString, + "ExtORPort authentication server-to-client hash" | ClientNonce | ServerNonce) + + ServerNonce is 32 random octets. + + Upon receiving that data, the client computers ServerHash herself and + validates it against the ServerHash provided by the server. + + If the server-provided ServerHash is invalid, the client MUST + terminate the connection. + + Otherwise the client replies with: + + ClientHash [32 octets] + + Where, + + ClientHash is computed as: + HMAC-SHA256(CookieString, + "ExtORPort authentication client-to-server hash" | ClientNonce | ServerNonce) + + Upon receiving that data, the server computers ClientHash herself and + validates it against the ClientHash provided by the client. + + Finally, the server replies with: + + Status [1 octet] + + Where, + + Status is 1 if the authentication was successfull. If the + authentication failed, Status is 0. + +4.3. Post-authentication + + After completing the Extended ORPort authentication successfully, the + two parties should proceed with the Extended ORPort protocol on the + same TCP connection. + +5. Acknowledgments + + Thanks to Robert Ransom for helping with the proposal and designing + the original safe-cookie authentication scheme. Thanks to Nick + Mathewson for advices and reviews of the proposal. + +[0]: +http://archives.seul.org/or/announce/Sep-2007/msg00000.html + +[1]: +https://gitweb.torproject.org/torspec.git/blob/79f488c32c43562522e5592f2c19952dc7681a65:/control-spec.txt#l1069 +

1 0

[translation/torbirdy_completed] Update translations for torbirdy_completed
by translation＠torproject.org 28 Nov '12

28 Nov '12

commit 6668ca98d7aa80e02d3ccd71345dab2ebde9e7ad Author: Translation commit bot <translation(a)torproject.org> Date: Wed Nov 28 00:47:01 2012 +0000 Update translations for torbirdy_completed --- es/torbirdy.dtd | 2 ++ es/torbirdy.properties | 2 ++ 2 files changed, 4 insertions(+), 0 deletions(-) diff --git a/es/torbirdy.dtd b/es/torbirdy.dtd index b84849a..b174e71 100644 --- a/es/torbirdy.dtd +++ b/es/torbirdy.dtd @@ -33,6 +33,8 @@ <!ENTITY torbirdy.prefs.imap.key "i"> <!ENTITY torbirdy.prefs.startup_folder.label "Seleccionar al iniciar el último directorio de correo utilizado [por defecto: deshabilitado, se seleccionará Carpetas locales]"> <!ENTITY torbirdy.prefs.startup_folder.key "l"> +<!ENTITY torbirdy.prefs.timezone.label "No establecer la zona horaria de Thunderbird a UTC [por defecto: establecer a UTC]"> +<!ENTITY torbirdy.prefs.timezone.key "z"> <!ENTITY torbirdy.prefs.enigmail_throwkeyid.label "Deshabilitar GPG '--throw-keyids' [por defecto: habilitado]"> <!ENTITY torbirdy.prefs.enigmail_throwkeyid.key "g"> <!ENTITY torbirdy.prefs.account_specific "Configuración específica de la cuenta"> diff --git a/es/torbirdy.properties b/es/torbirdy.properties index 568015c..e4b3ff5 100644 --- a/es/torbirdy.properties +++ b/es/torbirdy.properties @@ -11,3 +11,5 @@ torbirdy.email.prompt=TorBirdy ha deshabilitado el asistente de auto-configuraci torbirdy.email.advanced=Por favor, ten en cuenta que recomendamos NO cambiar la configuración avanzada de TorBirdy.⏎ ⏎ Debes continuar sólo si estás seguro/a de lo que estás haciendo. torbirdy.email.advanced.nextwarning=Mostrar una advertencia la próxima vez torbirdy.email.advanced.title=Configuración avanzada de TorBirdy + +torbirdy.restart=Para que la preferencia de zona horaria cause efecto, cierre Thunderbird e inícielo de nuevo.

1 0

[translation/torbirdy] Update translations for torbirdy
by translation＠torproject.org 28 Nov '12

28 Nov '12

commit 58dd8692527f7dea44dc4393afc7a00647a803af Author: Translation commit bot <translation(a)torproject.org> Date: Wed Nov 28 00:46:55 2012 +0000 Update translations for torbirdy --- es/torbirdy.dtd | 4 ++-- es/torbirdy.properties | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/es/torbirdy.dtd b/es/torbirdy.dtd index 7f872e7..b174e71 100644 --- a/es/torbirdy.dtd +++ b/es/torbirdy.dtd @@ -33,8 +33,8 @@ <!ENTITY torbirdy.prefs.imap.key "i"> <!ENTITY torbirdy.prefs.startup_folder.label "Seleccionar al iniciar el último directorio de correo utilizado [por defecto: deshabilitado, se seleccionará Carpetas locales]"> <!ENTITY torbirdy.prefs.startup_folder.key "l"> -<!ENTITY torbirdy.prefs.timezone.label ""> -<!ENTITY torbirdy.prefs.timezone.key ""> +<!ENTITY torbirdy.prefs.timezone.label "No establecer la zona horaria de Thunderbird a UTC [por defecto: establecer a UTC]"> +<!ENTITY torbirdy.prefs.timezone.key "z"> <!ENTITY torbirdy.prefs.enigmail_throwkeyid.label "Deshabilitar GPG '--throw-keyids' [por defecto: habilitado]"> <!ENTITY torbirdy.prefs.enigmail_throwkeyid.key "g"> <!ENTITY torbirdy.prefs.account_specific "Configuración específica de la cuenta"> diff --git a/es/torbirdy.properties b/es/torbirdy.properties index 28619e1..e4b3ff5 100644 --- a/es/torbirdy.properties +++ b/es/torbirdy.properties @@ -12,4 +12,4 @@ torbirdy.email.advanced=Por favor, ten en cuenta que recomendamos NO cambiar la torbirdy.email.advanced.nextwarning=Mostrar una advertencia la próxima vez torbirdy.email.advanced.title=Configuración avanzada de TorBirdy -# torbirdy.restart=For the time zone preference to take effect, please close Thunderbird and start it again. +torbirdy.restart=Para que la preferencia de zona horaria cause efecto, cierre Thunderbird e inícielo de nuevo.

1 0

[torspec/master] Clean up and finish 216-ntor-handshake.txt
by nickm＠torproject.org 27 Nov '12

27 Nov '12

commit 08b4c89058e7704f9cdb1e11407c7d1c8186c0cd Author: Nick Mathewson <nickm(a)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. +

1 0

[torspec/master] Turn xxx-ntor-handshake into a real proposal
by nickm＠torproject.org 27 Nov '12

27 Nov '12

commit f8c392b65751908ecb7be7f10d41aa3bf0fbe86c Author: Nick Mathewson <nickm(a)torproject.org> Date: Tue Nov 27 15:39:54 2012 -0500 Turn xxx-ntor-handshake into a real proposal --- proposals/216-ntor-handshake.txt | 151 ++++++++++++++++++++++++++++++++ proposals/ideas/xxx-ntor-handshake.txt | 151 -------------------------------- 2 files changed, 151 insertions(+), 151 deletions(-) diff --git a/proposals/216-ntor-handshake.txt b/proposals/216-ntor-handshake.txt new file mode 100644 index 0000000..081d6af --- /dev/null +++ b/proposals/216-ntor-handshake.txt @@ -0,0 +1,151 @@ +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_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 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) + hash function on members of G, of output length H_LENGTH bytes. + +Instantiation: + + 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(.,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 + 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 with b, B = KEYGEN(). The router publishes B in its server descriptor. + + 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 + 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 + KEY_SEED = H(secret_input, t_key) + verify = H(secret_input, t_verify) + auth_input = verify | ID | B | Y | X | PARAMSLEN | PARAMS | 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 + + secret_input = EXP(Y,x) | EXP(B,x) | ID | B | X | Y | PARAMSLEN | PARAMS + | 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" + + 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. + +Key expansion: + + Currently, the key expansion formula used by Tor here is + + 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. + + Instead, let's have it be + + 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". + + Ian says this is due to a construction from Krawczyk at + http://eprint.iacr.org/2010/264 . + +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 + diff --git a/proposals/ideas/xxx-ntor-handshake.txt b/proposals/ideas/xxx-ntor-handshake.txt deleted file mode 100644 index 081d6af..0000000 --- a/proposals/ideas/xxx-ntor-handshake.txt +++ /dev/null @@ -1,151 +0,0 @@ -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_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 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) - hash function on members of G, of output length H_LENGTH bytes. - -Instantiation: - - 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(.,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 - 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 with b, B = KEYGEN(). The router publishes B in its server descriptor. - - 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 - 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 - KEY_SEED = H(secret_input, t_key) - verify = H(secret_input, t_verify) - auth_input = verify | ID | B | Y | X | PARAMSLEN | PARAMS | 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 - - secret_input = EXP(Y,x) | EXP(B,x) | ID | B | X | Y | PARAMSLEN | PARAMS - | 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" - - 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. - -Key expansion: - - Currently, the key expansion formula used by Tor here is - - 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. - - Instead, let's have it be - - 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". - - Ian says this is due to a construction from Krawczyk at - http://eprint.iacr.org/2010/264 . - -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 -

1 0

[torspec/master] Fix 6963 in proposal 198 too.
by nickm＠torproject.org 27 Nov '12

27 Nov '12

commit 58809be4a72d6b81b3a4d9b48c14dc8139ab26b4 Author: Nick Mathewson <nickm(a)torproject.org> Date: Fri Nov 23 10:14:49 2012 -0500 Fix 6963 in proposal 198 too. In the list of v1 ciphers, we had listed SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, which didn't belong there, in a likely copy-and-paste issue from tor-spec.txt Fixes #6963; reported by cced. --- proposals/198-restore-clienthello-semantics.txt | 1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/proposals/198-restore-clienthello-semantics.txt b/proposals/198-restore-clienthello-semantics.txt index 3e336b0..c3b74c6 100644 --- a/proposals/198-restore-clienthello-semantics.txt +++ b/proposals/198-restore-clienthello-semantics.txt @@ -75,7 +75,6 @@ Proposed spec changes: TLS_DHE_RSA_WITH_AES_256_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA - SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA If the advertised ciphersuites in the ClientHello are _exactly_[*] the following, they indicate that the Tor v2+ link protocol is in

1 0

[tor-cloud/master] Use sudo bash when running the ec2-prep.sh script, thanks john_
by runa＠torproject.org 27 Nov '12

27 Nov '12

commit aa572c0ff9ddf7ca3f2500c59e50922b59d87530 Author: Runa A. Sandvik <runa.sandvik(a)gmail.com> Date: Tue Nov 27 20:16:52 2012 +0000 Use sudo bash when running the ec2-prep.sh script, thanks john_ --- rc.local | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/rc.local b/rc.local index 8593f96..b6c0644 100644 --- a/rc.local +++ b/rc.local @@ -1,5 +1,5 @@ #!/bin/sh -e sudo apt-get -y update sudo apt-get -y upgrade -sudo /etc/ec2-prep.sh type +sudo bash /etc/ec2-prep.sh type exit 0

1 0

[metrics-tasks/master] Add a graph with relative probabilities (#1854).
by karsten＠torproject.org 27 Nov '12

27 Nov '12

commit bd4e73627eebfe7332e125c772b368c86cd07ce8 Author: Karsten Loesing <karsten.loesing(a)gmx.net> Date: Tue Nov 27 12:44:17 2012 -0500 Add a graph with relative probabilities (#1854). --- task-1854/plot-entropy.R | 13 +++++++++++++ 1 files changed, 13 insertions(+), 0 deletions(-) diff --git a/task-1854/plot-entropy.R b/task-1854/plot-entropy.R index cc963e4..ac02782 100644 --- a/task-1854/plot-entropy.R +++ b/task-1854/plot-entropy.R @@ -45,6 +45,19 @@ scale_colour_hue(name = "Advertised bandwidth cutoff in B/s") + opts(title = paste("Consensus with valid-after time", max(p$validafter)), legend.position = "top") +c <- p[p$advbw >= 1048576, ] +c <- data.frame(advbw = c$advbw, prob = c$prob, + minadvbw = paste("c", c$minadvbw, sep = "")) +c <- cast(c, advbw ~ minadvbw, value = "prob") +c <- data.frame(advbw = c$advbw, rel = c$c1048576 / c$c20480) +ggplot(c, aes(x = advbw, y = rel)) + +geom_point(alpha = 0.25) + +scale_x_log10(name = "\nAdvertised bandwidth in B/s (log scale)") + +scale_y_continuous(name = paste("Ratio of probaility at 1 MiB/s cutoff", + "to probability at 20 KiB/s cutoff\n")) + +opts(title = paste("Consensus with valid-after time ", max(p$validafter), + "\n", sep = ""), legend.position = "top") + e <- read.csv("linf-extracted.csv", header = FALSE, col.names = c("validafter", "min_adv_bw", "relays", "linf", "excl_adv_bw", "graph"), stringsAsFactor = FALSE)

1 0

[metrics-tasks/master] Remove unused GeoIP code (#1854).
by karsten＠torproject.org 27 Nov '12

27 Nov '12

commit 767e93c8b3639e0e06f8e17e3f176e625efde9c5 Author: Karsten Loesing <karsten.loesing(a)gmx.net> Date: Tue Nov 27 09:17:03 2012 -0500 Remove unused GeoIP code (#1854). --- task-1854/pylinf.py | 18 ------------------ 1 files changed, 0 insertions(+), 18 deletions(-) diff --git a/task-1854/pylinf.py b/task-1854/pylinf.py index 3bdd8a2..9885de5 100644 --- a/task-1854/pylinf.py +++ b/task-1854/pylinf.py @@ -11,7 +11,6 @@ rsync -arz --delete metrics.torproject.org::metrics-recent/relay-descriptors/con import sys import math import os -import pygeoip import tarfile import pickle import StringIO @@ -28,8 +27,6 @@ class Router: self.bandwidth = None self.advertised_bw = None self.hex_digest = None - self.country = None - self.as_no = None self.is_exit = None self.is_guard = None @@ -37,8 +34,6 @@ class Router: self.hex_digest = b2a_hex(a2b_base64(values[2]+"=")) self.advertised_bw = self.get_advertised_bw(self.hex_digest) ip = values[5] - #self.country = gi_db.country_code_by_addr(ip) - #self.as_no = self.get_as_details(ip) def add_weights(self, values): self.bandwidth = int(values[0].split('=')[1]) @@ -49,13 +44,6 @@ class Router: if "Guard" in values: self.is_guard = True - def get_as_details(self, ip): - try: - value = as_db.org_by_addr(str(ip)).split() - return value[0] - except: - return "" - def get_advertised_bw(self, hex_digest): try: return descriptors[self.hex_digest.upper()] @@ -213,10 +201,6 @@ def parse_args(): usage = "Usage - python pyentropy.py [options]" parser = OptionParser(usage) - parser.add_option("-g", "--geoip", dest="gi_db", default="GeoIP.dat", - help="Input GeoIP database") - parser.add_option("-a", "--as", dest="as_db", default="GeoIPASNum.dat", - help="Input AS GeoIP database") parser.add_option("-s", "--server_desc", dest="server_desc", default=False, help="Server descriptors directory") parser.add_option("-l", "--linf-output", dest="linf", default="linf.csv", @@ -234,8 +218,6 @@ def parse_args(): if __name__ == "__main__": options = parse_args() - gi_db = pygeoip.GeoIP(options.gi_db) - as_db = pygeoip.GeoIP(options.as_db) server_desc_files = [] global descriptors

1 0