- tor-dev - lists.torproject.org

Proposal 216 (ntor) redux
by Nick Mathewson 14 Dec '12

14 Dec '12

Here's a slightly updated version of the ntor proposal, as changed while I was doing the implementation (see [A] for more information on that). For a diff between the old version and the new one, see [B]. The interesting changes were: * To specify that the key expansion uses HKDF from RFC5869. (This is the standardized version of originally recommended key expansion approach.) * To specify that the length of a node ID is ID_LENGTH bytes, not H_LENGTH. * To make the t_key tweak value not be a prefix of the m_expand value. This is probably cosmetic. * To specify a way for embedding these handshakes in EXTEND/EXTENDED/CREATE/CREATED cells so that they can be used to extend from a server that doesn't know about proposal 200. * To specify checking EXP() outputs for the point at infinity rather than checking inputs for group membership. I am not convinced this is necessary [C], but Ian Goldberg thought it was a good idea. The ntor branch has a reference implementation of the handshake in src/test/ntor_ref.py [D] which has been verified to interoperate with the C implementation. [A] https://trac.torproject.org/projects/tor/ticket/7202 [B] https://gitweb.torproject.org/torspec.git/blobdiff/08b4c89058e7704f9cdb1e11… [C] If a client generates a bad public key, it will at worst get no security. If a server generates a bad public key, it will at worst provide no security--but a server that wants to provide no security can already leak its outputs. The case to worry about would be if an MITM attacker replaced the X value or the Y value when communicating between the server and the client. But I believe that the inclusion of X and Y in the auth_input and secret_input steps prevents such an MITM attacker from successfully convincing the client that the handshake was successful. Still, "belt and suspenders." [D] https://gitweb.torproject.org/nickm/tor.git/blob_plain/ntor:/src/test/ntor_… ==== 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. Let each node have a unique identifier, ID_LENGTH bytes in length. 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_extract" 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 -- ID_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). Both parties check that none of the EXP() operations produced the point at infinity. [NOTE: This is an adequate replacement for checking Y for group membership, if the group is curve25519.] 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 HKDF-SHA256 as defined in RFC5869: K = K_1 | K_2 | K_3 | ... Where K_1 = H(m_expand | INT8(1) , KEY_SEED ) and K_(i+1) = H(K_i | m_expand | INT8(i) , KEY_SEED ) and m_expand 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" In RFC5869's vocabulary, this is HKDF-SHA256 with info == m_expand, salt == t_key, and IKM == secret_input. 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: "ntor-onion-key" 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 "ntor-onion-key" entries to from router descriptors to microdescriptors. In microdescriptors, "ntor-onion-key" can go right after the "onion-key" line. 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 02] for this handshake in CREATE2 and EXTEND2 cells. Specify that this handshake type can be used in EXTEND/EXTENDED/ CREATE/CREATED cells as follows: instead of a 190-byte TAP onionskin, send the 16-byte string "ntorNTORntorNTOR", followed by the client's ntor message. Instead of a 148-byte TAP response, send the server's ntor response. (We need this so that a client can extend from an 0.2.3 server, which doesn't know about CREATE2/CREATED2/EXTEND/EXTENDED2.) Test vectors for HKDF-SHA256: These are some test vectors for HKDF-SHA256 using the values for M_EXPAND and T_KEY above, taking 100 bytes of key material. INPUT: "" (The empty string) OUTPUT: d3490ed48b12a48f9547861583573fe3f19aafe3 f81dc7fc75eeed96d741b3290f941576c1f9f0b2 d463d1ec7ab2c6bf71cdd7f826c6298c00dbfe67 11635d7005f0269493edf6046cc7e7dcf6abe0d2 0c77cf363e8ffe358927817a3d3e73712cee28d8 INPUT: "Tor" (546f72) OUTPUT: 5521492a85139a8d9107a2d5c0d9c91610d0f959 89975ebee6c02a4f8d622a6cfdf9b7c7edd3832e 2760ded1eac309b76f8d66c4a3c4d6225429b3a0 16e3c3d45911152fc87bc2de9630c3961be9fdb9 f93197ea8e5977180801926d3321fa21513e59ac INPUT: "AN ALARMING ITEM TO FIND ON YOUR CREDIT-RATING STATEMENT" (414e20414c41524d494e47204954454d20544f2046494e44204f4e20 594f5552204352454449542d524154494e472053544154454d454e54) OUTPUT: a2aa9b50da7e481d30463adb8f233ff06e9571a0 ca6ab6df0fb206fa34e5bc78d063fc291501beec 53b36e5a0e434561200c5f8bd13e0f88b3459600 b4dc21d69363e2895321c06184879d94b18f0784 11be70b767c7fc40679a9440a0c95ea83a23efbf

3 2

Re: [tor-dev] Flashproxy alpha bundles
by Veggie Monster 14 Dec '12

14 Dec '12

> connections, so browser implementations don't let you do it. > So the user has to be able to accept connections on his end. Apparently Chrome Canary lets you do that: http://iceddev.github.com/blog/2012/11/05/node-js-in-chrome/ Vmon

2 1

Re: [tor-dev] RFC on obfs3 pluggable transport
by Veggie Monster 13 Dec '12

13 Dec '12

Hey Ian, > [There's no such thing as a "bi-quadratic residue" in this setting; all > quadratic residues in this group have one square root which is itself a > quadratic residue and one which is not.] I guess you are right. Because (q,2) = 1, all quadratic residues are bi-quadratic residues, hence no meaningful distinction: [vmon@telly biquad-attack]$ sage mount_attack.sage Key oracle biquadratic residue ratio: 0.500503540039062 Random oracle biquadratic residue ratio: 0.496414184570312 [https://github.com/vmon/biquad-attack] Thanks, Vmon

1 0

Re: [tor-dev] RFC on obfs3 pluggable transport
by vmonmoonshine＠gmail.com 12 Dec '12

12 Dec '12

>The only issue with your trick, is that I'm not looking forward >implementing a custom DH key exchange in Python (especially the DH >parameter generation and public key validation parts). >From the conversation of Zack with Steven at the breakfast table at Hotel Cellai, I'm pretty sure that Stegotorus is using DH based on elliptic curve and its twist protocol. So you can find an implementation of it there. Though I haven't looked at the crypto part of the code myself. Also could you please refer me to the reference that proves that X or p-X is uniformly random. It seems to me that you are taking a quadratic residue to an even power, so you always get a bi-quadratic residue for X. Then if I'm the distinguisher who knows the public group, and I see that the bi-quadratic residues appears 1/2 times instead of 1/4 of the times then I can smell that something going on. Take care, Vmon

2 1

Stem code review 2012-12-04
by Sean Robinson 08 Dec '12

08 Dec '12

Stem devs, I did a code review of recent Stem commits ("Tor event handling" merge (commit 42872dd08e81d6b3) through "Checking for None by identity" (commit 69f72efc9367092c)). My comments and questions follow. I will skip my own contributions (they were great 8-) in that range, as I am biased. Event._log_if_unrecognized() is a good idea that vastly improves the readability of Event subclasses and reduces code duplication. Regarding commit fb0aec5d95e9d2e6 "tidying up boilerplate": 1) I do not like the new _get_event() with assert_class and assert_content. There are transformations and tests and returned values all within what is a mock object builder, meaning it works via side-effect. This could be surprising to test writers. 2) I vote to keep "self.assertTrue(isinstance(event, stem.response.events.StatusEvent))" style tests after producing the event. The quoted key/value mapping is more readable, now. Good work. Why not look for quoted positional args before non-quoted positional args? Why not do just like kwarg handling? Why restrict SignalEvents to expected_signals when control-spec.txt allows more? This may mean changes later to add support for things the protocol already claims to support. I set up coverage.py for another project and I wondered if it would work with Stem. So, I ran "coverage run --parallel-mode --branch --omit="test*" ./run_tests.py -u -i -t RUN_NONE" in the stem directory. The results are 66% - 100% coverage per module. Another impressive accomplishment. And this is only running a subset of the possible tests. -- Sean Robinson

2 3

stem mock_method usage
by Sean Robinson 08 Dec '12

08 Dec '12

Damian, I am attempting to write a test using test.mocking.mock_method, but I do not understand how to use it correctly. Could you give me pointers on the following smallest (non-)working test case. import stem from stem.control import Controller import test.mocking as mocking socket = stem.socket.ControlSocket() controller = Controller(socket) mocking.mock_method(Controller, 'get_version', mocking.return_value(stem.version.Version('0.1.0.14'))) controller.get_version() The above code fails with: Traceback (most recent call last): File "mock_method-test.py", line 8, in <module> mocking.mock_method(Controller, 'get_version', mocking.return_value(stem.version.Version('0.1.0.14'))) File "stem.dev/test/mocking.py", line 317, in mock_method target_class.__dict__[method_name] = mock_wrapper TypeError: 'dictproxy' object does not support item assignment -- Sean Robinson

2 1

R: Re: questions about extending circuit
by succer110＠tiscali.it 07 Dec '12

07 Dec '12

HiFrom your code, does not seems possible to create new circuits specifying fingerprint. https://stem.readthedocs.org/en/latest/_modules/stem/control.html#Controlle… Also i don't think it's possibile to extendcircuits with fingerprint from command line with control port... i've tried but i failed. This sounds very strange to me: it should be possibile to create circuits with the 500 "unnamed" router constantly connected!Where Am I wrong?Thankyou ----Messaggio originale---- Da: atagar(a)torproject.org Data: 30/11/2012 2.21 A: <tor-dev(a)lists.torproject.org> Ogg: Re: [tor-dev] questions about extending circuit Hi. Both HackerSpaceSeoul and HackerspaceSeoul lack the named flag, which likely is why tor isn't allowing you to refer to it by the nickname. Have you tried referring to it by the fingerprint instead? Speaking of which, TorCtl is being deprecated in favor of a couple newer controller libraries... https://stem.readthedocs.org/en/latest/ - replacement with a similar design to TorCtl, see the tutorial for usage https://txtorcon.readthedocs.org/en/latest/ - twisted controller library If you try using stem then let me know if run into any issues or have questions! -Damian _______________________________________________ tor-dev mailing list tor-dev(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev 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

Detecting if a IP address belongs to a Tor Exit node.
by Jorge Couchet 07 Dec '12

07 Dec '12

A FlashProxy (https://crypto.stanford.edu/flashproxy/) is a normal browser that has a Javascript code in order to act as a Proxy. The browser acting as a Proxy is contacting a special server (the "Facilitator" developed in Python) in order to ask for a client and a Tor relay. In the case that the Facilitator 's answer is positive, then the FlashProxy is acting as a bridge in order to connect the client with the Tor relay (i.e. helping the client to connect to the Tor Network from a country with the known relays censored). I'm working with the ticket 7549 (https://trac.torproject.org/projects/tor/ticket/7549) The ticket 's goal is to avoid a "Tor in Tor situation" when a FlashProxy is serving a client request. This "Tor in Tor situation" could be described as the FlashProxy being itelsf inside of the Tor Network when is trying to help a client computer to connect to the Tor Network. In order to avoid this situation, the goal here is that the Facilitator is checking if the FlashProxy 's public IP belongs to a Tor Exit node, if so then the Facilitator is giving a negative answer to the Proxy. One possible solution for this scenario is that the Facilitator is running an online lookup that queries a locally running Tor instance in order to known if a given IP address belongs to a Tor Exit node or not. So, the question is: is there any other reasonable way (efficient -development and execution time- and safe) to see if an IP address belongs to a Tor Exit node? Thanks in advance for your help!

5 7

tor exit node receive buffer and sending buffer
by esolve esolve 04 Dec '12

04 Dec '12

are there any specification on how tor exit node manage its receive buffer(e.g, for receiving packets from remote webserver) and its sending buffer(for sending packets back to the client)?

1 1

Re: [tor-dev] [tor-reports] George's status report: November 2012
by Mike Perry 04 Dec '12

04 Dec '12

Thus spake George Kadianakis (desnacked(a)riseup.net) > Hi, > > - Started researching and developing obfs3, an improved version of the > obfs2 pluggable transport. The proposed protocol currently looks > like this: > https://gitweb.torproject.org/user/asn/pyobfsproxy.git/blob/refs/heads/obfs… > > The current implementation uses curve25519 to do ECDH, but > curve25519 public keys don't look random enough on the wire and we > will probably need to use a curve similar to the one that Telex > uses. > > Ian, Philipp and Roger helped a lot with this. Holy crap. In what way are the public keys in curve25519 "not random enough"? I don't really know anything of substance about ECC (especially ECC curve choice), but if the public keys are distributed unevenly over the keyspace, isn't this a hint of something extremely bad? At the very least, it sounds like it hints at reduced strength of the curve: non-uniformity over a 256bit keyspace means it takes less than 256 bits to describe the keypair mapping, which should mean a technique exists with less than 2^128 operations for solving the ECDLP (as compared to using Shanks or rho collisions, etc). Did you write this up anywhere? I see the XXX for the "FAQ" entry in your spec... Also, to help reduce my ignorance: Does anyone know if ECC curves are usually tested for key distribution uniformity? -- Mike Perry

3 2