- tor-dev - lists.torproject.org

Proposal 216: Improved circuit-creation key exchange
by Nick Mathewson 01 Dec '12

01 Dec '12

Hi, all. This is just the ntor proposal draft, as circulated last year, but with a proposal number assigned to it, and a closing section about how to make Tor actually work with it. Filename: 216-ntor-handshake.txt Title: Improved circuit-creation key exchange Author: Nick Mathewson Created: 11-May-2011 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. 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: 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 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) 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 is in G^* [see NOTE below], and computes 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 | 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 . Let m_expand be PROTOID | ":key_expand" 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 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.

3 5

Parallel relaycrypt data structures for review
by Andrea Shepard 01 Dec '12

01 Dec '12

Please review first draft proposed parallel relaycrypt structures in my parallel_relay_crypt branch. -- Andrea Shepard <andrea(a)torproject.org> PGP fingerprint: 3611 95A4 0740 ED1B 7EA5 DF7E 4191 13D9 D0CF BDA5

3 3

questions about extending circuit
by succer110＠tiscali.it 29 Nov '12

29 Nov '12

Hi all, I need to create specific circuit, specifying the exit route. I've already found http://www.thesprawl.org/research/tor-control-protocol/ but this explain how to create circuit with nickames.Suddenly, nickname are not univoque and i think tor have problem creating circuit when the nickname of the exitroute is "Unnamed".Sometimes the creation of a new circuit fails:extendcircuit 0 hackerspaceseoul552 No such router "hackerspaceseoul"extendcircuit 0 HackerSpaceSeoul552 No such router "HackerSpaceSeoul"extendcircuit 0 HackerspaceSeoul552 No such router "HackerspaceSeoul"Even if https://atlas.torproject.org/#search/hack told me they are online. And sometimes this appends even with TorCtl.py DEBUG[Thu Nov 29 23:40:45 2012]:Extending circuit[!!!] Error creating circuit: 552 No such router "Communist" How can i fix? Thank you :) Invita i tuoi amici e Tiscali ti premia! Il consiglio di un amico vale più di uno spot in TV. Per ogni nuovo abbonato 30 € di premio per te e per lui! Un amico al mese e parli e navighi sempre gratis: http://freelosophy.tiscali.it/

2 1

Tor Safe RSA Plugin
by Clay Graham 29 Nov '12

29 Nov '12

I am creating a twitter clone with RSA public key encryption and making it feely available. tweet from my feed: ================= new: http://grailo.org <http://t.co/M1Pbgkdn> twitter clone meets public key encryption github: http://bit.ly/UmUsxm <http://t.co/SCVAvVa4> pic: http://bit.ly/UmUdCn <http://t.co/hchO3QWL> https://twitter.com/claytantor Looking to create a Tor Browser plugin that can do client side decryption. Happy to use javascript, c or java. Clay

1 0

Compiling tor against OpenSSL_1_0_2-stable
by Christian Kujau 29 Nov '12

29 Nov '12

Hi, while trying to compile the latest git-checkout against openssl-1.0.2, I've come across the following issues: ---- make[1]: Entering directory `/usr/local/src/tor-git' CC src/common/tortls.o cc1: warnings being treated as errors In file included from /opt/openssl/include/openssl/ssl.h:1382, from src/common/tortls.c:36: /opt/openssl/include/openssl/srtp.h:138: error: redundant redeclaration of ‘SSL_get_selected_srtp_profile’ /opt/openssl/include/openssl/srtp.h:135: note: previous declaration of ‘SSL_get_selected_srtp_profile’ was here make[1]: *** [src/common/tortls.o] Error 1 make[1]: Leaving directory `/usr/local/src/tor-git' make: *** [all] Error 2 ---- There is an open ticket[0] in the openssl bugtracker for this. While the proper solution is to fix openssl/include/openssl/srtp.h, I wanted to compile without -Werror. However, when adding CFLAGS="-Wno-error" during ./configure, -Werror is still added to the ./Makefile and overriding -Wno-error. When adding CFLAGS="-Wno-error" during "make" all the other CFLAGS are gone too. Thus I ended up removing -Werror from the Makefile and tortls.o compiled. While this is really an issue with openssl, I wanted to have this documented, just in case anybody else tries the same. If someone knows of a better workaround (i.e. compiling just tortls.c with -Wno-error and everything else with -Werror), please share! :-) A bit later, compilation stops again: ---- CCLD src/or/tor src/common/libor-crypto.a(aes.o): In function `aes_crypt': aes.c:(.text+0x860): undefined reference to `CRYPTO_ctr128_encrypt' collect2: ld returned 1 exit status make[1]: *** [src/or/tor] Error 1 make[1]: Leaving directory `/usr/local/src/tor-git' make: *** [all] Error 2 ---- Hm, this leaves me puzzled for now. CRYPTO_ctr128_encrypt is still included in openssl-1.0.2 and src/common/aes.o seems to be built with this function included as well, not sure why src/common/libor-crypto.a complains now: ---- $ grep -r CRYPTO_ctr128_encrypt /opt/openssl/ /opt/openssl/include/openssl/modes.h:void CRYPTO_ctr128_encrypt(const unsigned char *in, unsigned char *out, /opt/openssl/include/openssl/modes.h:void CRYPTO_ctr128_encrypt_ctr32(const unsigned char *in, unsigned char *out, Binary file /opt/openssl/bin/openssl matches Binary file /opt/openssl/lib/libcrypto.a matches $ grep -r CRYPTO_ctr128_encrypt . ./src/common/aes.c: CRYPTO_ctr128_encrypt((const unsigned char *)input, Binary file ./src/common/aes.o matches Binary file ./src/common/libor-crypto.a matches ---- Why do I (try to) build against openssl-1.0.2? I'm on Debian/stable which still ships openssl-0.9.8o and I wanted to get rid of this "use a more recent OpenSSL" message during startup :-) Otherwise, today's git-checkout of tor runs just fine when built against openssl-0.9.8 (on powerpc) - yay! Christian. [0] http://rt.openssl.org/Ticket/Display.html?id=2724 -- BOFH excuse #330: quantum decoherence

2 2

More TBB usability challenges
by Andrew Lewman 28 Nov '12

28 Nov '12

I was asked to meet with some people doing work in dangerous areas of Latin America. In general, these people can get around and work with Microsoft Windows competently. They are all fluent in English, Spanish, and various dialects found in Latin American countries. Most of them had Spanish-language versions of Windows 7 on their laptops. # Getting TBB During the discussion, an informal usability study happened. I thought having a discussion about this may be better than simply opening a trac ticket. Here's roughly the scenario. I asked people to download Tor Browser from our website. All found Tor's website via Bing. Interestingly, some searched for "tor", others for "tor browser", and one for "tor project". They were all using Internet Explorer and Bing because that's the default for Windows 7. Thankfully, our website is the top result for all three queries at Bing. They all found the big purple "Download Tor" button on the index page. Issue #1: Running TBB from the website. When clicking the orange "Download Tor Browser Bundle" button, IE prompts them to "Run", "Save", or "Cancel". All of them chose "Run". Issue #1A: When choosing "Run", a prompt appears, "The publisher of tor-browser-2.2.39-5_en-US.exe couldn't be verified. Are you sure you want to run the program?". All of them hit "Yes" and ignored the warning. Issue #1B: When the download completed, they were prompted with the 7zip self-extractor giving them a path similar to this: "C:\Users\tor\AppData\Local\Microsoft\Windows\Temporary Internet Files\Content.IE5\T868H68M\". All of them pushed the "Extract" button and let 7zip extract TBB into that temporary directory. A few of them went to the Downloads folder to try to find TBB. However, it's not there because it's extracted into a temporary folder. This folder is not reachable by the user through File Explorer. Issue #2: Downloading TBB. After some Q&A about what happened, I asked them to "Save" rather than "Run". TBB then downloads. The user is prompted with a warning box stating, "The publisher of tor-browser-2.2.39-5_en-US.exe couldn't be verified." And the user is left to choose between "Run" and "View downloads". When clicking "Run" the user is prompted with the 7-zip self-extractor prompt and "C:\Users\tor\Downloads\" is the default path. All of them hit the "Extract" button. None of them were sure what just happened nor why TBB needs to be extracted. Issue #2A: The self-extract completes and the user is left looking at their IE window with the TBB download page. Three of them went to their Downloads folder to find Tor. The other few waited for something to happen. When I asked the waiting few why they were waiting, they said because they "ran TBB" and expected the extraction to automatically start TBB for them. Issue #3: In the Downloads folder there are two things called "tor browser", one is an application the other is a file folder. See https://people.torproject.org/~andrew/2012-11-28-tbb-usability-test/2012-11… for an example. Most of the people had hundreds of files in the Download folder, so it wasn't as clear as this example screenshot. Some people wanted to run the application, because in their mind, you run an application. When asked to go into the Tor Browser folder, they all found "Start Tor Browser" and ran it (some double-left click, some right click and choose "Open"). See https://people.torproject.org/~andrew/2012-11-28-tbb-usability-test/2012-11… for what it looks like by default. Issue #4: Once TBB was started, the users would alt-tab between applications or choose various apps in their task bar at the bottom of the screen. They kept clicking the onion icon because they thought it was TBB, when it brings up the Vidalia control panel. This is what it looks like, https://people.torproject.org/~andrew/2012-11-28-tbb-usability-test/2012-11… Issue #5: No one knew what "Startpage" was nor why it was in the top bar. Just like IE, they all wanted to search from the awesome bar by default. This does work, and they can search via startpage.com via the awesome bar. From here on out, the normal TBB issues apply, as demonstrated by Greg's HotPETS paper, https://people.torproject.org/~andrew/hotpets12-1-usability.pdf # Feedback I asked how we can improve this entire process. The consensus is that TBB needs to be a single application people can just run and get the browser going. The extraction process was confusing and was sometimes called an installation process. They felt that "running" it from the tor download site was fine, so long as everything just worked and a browser window popped up. They also felt that the Vidalia control panel was unnecessary. It just confused them. The only thing they felt was valuable was the Network Map. A caveat is that we were on a US network which didn't censor. The Message Log and bridge/obfsproxy functionality wasn't needed in this case. I suspect it will be when they try this in Latin America. -- Andrew http://tpo.is/contact pgp 0x6B4D6475

1 0

Proposal: Tor Extended ORPort Authentication
by George Kadianakis 27 Nov '12

27 Nov '12

Greetings, I'm attaching a proposal for adding authentication to the Extended ORPort. The Extended ORPort is a yet unimplemented feature, that allows pluggable transports proxies to communicate with Tor; it's a prerequisite for pluggable transport statistics, rate limiting, and other cool things. Filename: XXX-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. [0]: http://archives.seul.org/or/announce/Sep-2007/msg00000.html [1]: https://gitweb.torproject.org/torspec.git/blob/79f488c32c43562522e5592f2c19…

2 2

questions about parallel Tor circuits en masse & adoption drivers
by Simon 27 Nov '12

27 Nov '12

Hello, I'm interesting in discussing the development aspects of using Tor as a massively distributed anonymous file server where blocks (e.g. 4KB) of a particular file (e.g. even several GB in size) might be redundantly distributed on very many hidden service nodes (e.g. a unique 4KB block of a file redundantly duplicated on ~ x hidden nodes from y million total hidden service nodes) and access to the file would be high through-put because very many (e.g. cable bandwidth / 4KB, e.g. 50 Mbps is 6.25 MB/s or 1600 * 4KB blocks per second) concurrent but high latency Tor circuits. Thus each Tor circuit would still be the usual high latency, but very many Tor circuits in parallel would deliver fantastic through-put. What if Tor could handle several rolling window bundles of e.g. 1,600 parallel Tor circuits which request one small block of info from 1,600 unique hidden service nodes? Does Tor parallelized, high bandwidth file sharing already exist? Does Tor already handle a massively parallelized number of Tor circuits, on the scale of thousands or tens of thousands of Tor circuits? Is many concurrent Tor circuits desirable? Who is working on it? Would using Tor as a massively distributed anonymous file server dramatically increase the number of Tor nodes (due to file sharing being more desirable than anonymity) and therefore make the entire Tor system more resilient to attack due to high growth and orders of magnitude more nodes? Is such an expansion -- on the back of a new functional focal point; i.e. not anonymity -- politically desirable for the Tor project? Thanks, Simon Experienced network programming enthusiast from Vancouver, Canada

1 0

tor exit node modules in Tor source codes
by esolve esolve 27 Nov '12

27 Nov '12

I'm doing research on Tor and I want to modify the tor exit node functions. I downloaded the source codes from this link https://gitweb.torproject.org/tor.git/tree/b13c6becc892d9716d8645f16b5d03bd… but I can't find the modules/files which are related to tor exit functions(like receive cells from previous relay router, send HTTP/TCP connection request to webserver/remote_host, buffer management) can anyone give some hints? thanks!

1 0

Re: [tor-dev] RIAA v Verizon: 404
by Christian Kujau 27 Nov '12

27 Nov '12

On Mon, 26 Nov 2012 at 17:40, leez wrote: > The lost document was actually this one: > https://www.eff.org/document/dc-circuit-opinion-granting-verizons-motion-qu… > > I've added a redirect from the broken link, so either will get you > there now. Thanks for fixing this! Christian. -- BOFH excuse #171: NOTICE: alloc: /dev/null: filesystem full

1 0