- tor-dev - lists.torproject.org

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

Looking for ways to get involved
by Leonardo Camargo 04 Dec '12

04 Dec '12

Hi, First of all, if that's not a suitable message for [tor-dev], I apologise and will promptly go for [tor-talk] instead. I'm a CS undergrad and am time-pressed to present a graduation project proposal. Getting involved with Tor is something that has been on my mind for a long time, but I only now started taking the time to actually look into it. I need to present a proposal about something specific in the next few days, though I probably can refine/redirect my objectives in the following weeks. Something that really interests me is the possible move of tor traffic from tcp to udp, in the foreseeable future. I'd like to work on something that helps moving Tor closer to the point where this architectural change can start happening. Network programming and security are two topics that interest me a lot. I need something specific of the likes of "Look into X and tell us how to best achieve Y" or "Research W looking for a, b and c" ; something that could realistically help and something that can be a proposal. I'm not expecting people to teach me anything, just to point me in the right direction so I don't waste time on something that won't be realistically useful. I'm not simply looking for anything that will fit as a graduation project, I'm actually trying to combine* several goals in one*: (a) study tor in depth, (b) help out with something realistically useful, (c) graduate. And my wish in to continue my involvement with tor after my project is done. My desire is to work on "my thing" rather than my (future) advisor's thing(whatever he's got), if I come up to him with something already thought-throught he'll be less likely to try and sway me towards something else. I'm reading up the docs. But right now something specific for me to present as proposal would help a lot. Any ideas are welcome. Thanks,

1 0

Windows binary flash proxy packages
by David Fifield 03 Dec '12

03 Dec '12

Thanks to Alexandre's work on #7283, we now have Windows .exe packages of the flash proxy client programs. http://www.bamsoftware.com/dist/flashproxy/flashproxy-client-0.9-win32.zip http://www.bamsoftware.com/dist/flashproxy/flashproxy-client-0.9-win32.zip.… These are in addition to the already existing packages that require you to have Python installed. http://www.bamsoftware.com/dist/flashproxy/flashproxy-client-0.9.zip http://www.bamsoftware.com/dist/flashproxy/flashproxy-client-0.9.zip.asc Some people might be interested in the technical details of compiling Python applications on Windows. https://gitweb.torproject.org/flashproxy.git/blob/688010d2:/doc/windows-dep… https://gitweb.torproject.org/flashproxy.git/blob/688010d2:/Makefile The next step is https://trac.torproject.org/projects/tor/ticket/7621, which is about installing these programs into a Tor Browser Bundle. Perhaps we should try to coordinate this into a combined pyobfsproxy/flash proxy bundle? David Fifield

2 1

Grailo.net is live (but very young)
by Clay Graham 02 Dec '12

02 Dec '12

Hey all, You may remember an email from me about a week ago, and I could really use some pointers. We just stealth launched an alpha version of http://grailo.net and I would love all of you to try it out and give me feedback. Its 100% open source, 100% free, and you can even fork the project yourself on github. Its goal: Create a simple to use client side, RSA public key encryption for microblogging on the internet. The reason I am reaching out to you is I am I am interested in creating a client side plugin for the TOR browser so that people can use the client side encryption safely and privately, and without fear. Since scripting is disabled in TOR, with good reason, I want a plugin that is blessed by the TOR project as open and safe for encryption. Any leads on where to get started are greatly appreciated. Clay

4 6

Damian's Status Report - November 2012
by Damian Johnson 02 Dec '12

02 Dec '12

November was a month that included eating far too much pie. There was some stem work too on the side, though delicious pumpkin pies are always how that month should be remembered. My primary focus for November was tor event handling [1], which is the last major feature we need before having parity with TorCtl. We presently support nine of the nineteen event types, including the most commonly used ones (logging, BW, CIRC, STREAM, etc). I'll be spending a good chunk of December finishing this up. Besides this I've been really thrilled at how contributors are coming out of the woodwork to help! Ravi * Ravi has volunteered to take a lead on moving stem onto tor's site. Unfortunately this is presently blocked on getting a subdomain. [2] * Provided a patch to move stem's controller exceptions to the top level namespace. [3] * Fix for the repurpose_circuit() integ test [4] and discovered an issue with the stem.process test. [5] Eoin * Submitted a great patch overhauling and expanding verification of server descriptor content. [6] * Caught a possible tor bug related to 'GETINFO orconn-status' queries when disconnected. [7] * Numerous spelling fixes [8] and caught an issue with respect to how the descriptor reader handles archives. [9] Sean * Reviewed my event parsing branch, offering feedback [10] and catching a bug where STREAM events could have a zero port. [11] * Submitted patches to add close_circuit() to the Controller [12] and a setup.py [13]. The former led to a discussion about stem's licensing and copyright for patches. * Helped resolve an issue with EXTENDCIRCUIT where we weren't taking into account when the path was optional or not. [14] Other things I did this month includes... * Preparation for the 2013 Outreach Program for Women [15], the application deadline for which is now only two days away. This mostly involved helping others add their project ideas to the volunteer page and adding one of my own. [16] * Made a landing page for stem's bug tracking [17] and linked to it from stem's site. * Revamped stem's enum documentation to be both more readable and support interlinking. [18] * Provided a code review for Karsten's pygeodate.py. [19] * Answered a handful of controller inquiries on our lists. Stem's now at a point where I don't mind suggesting it to developers. If you're scripting or writing an application around tor then please give stem a try! I'd love to get more feedback on where its rough edges are before we make an initial release. [20][21][22][23] Cheers! -Damian [1] https://trac.torproject.org/7328 [2] https://trac.torproject.org/7324 [3] https://trac.torproject.org/6357 [4] https://trac.torproject.org/7259 [5] https://trac.torproject.org/7284 [6] https://trac.torproject.org/5810 [7] https://trac.torproject.org/7558 [8] https://gitweb.torproject.org/stem.git/commitdiff/2a59741 [9] https://gitweb.torproject.org/stem.git/commitdiff/69c55ab [10] https://trac.torproject.org/7328#comment:3 [11] https://trac.torproject.org/7598 [12] https://trac.torproject.org/7566 [13] https://trac.torproject.org/7565 [14] https://trac.torproject.org/6666 [15] https://live.gnome.org/OutreachProgramForWomen [16] https://www.torproject.org/getinvolved/volunteer.html.en#stemUsability [17] https://trac.torproject.org/projects/tor/wiki/doc/stem/bugs [18] https://gitweb.torproject.org/stem.git/commitdiff/0e99a26 [19] https://trac.torproject.org/6471 [20] https://lists.torproject.org/pipermail/tor-relays/2012-November/001774.html [21] https://lists.torproject.org/pipermail/tor-talk/2012-November/026299.html [22] https://lists.torproject.org/pipermail/tor-dev/2012-November/004162.html [23] https://lists.torproject.org/pipermail/tor-dev/2012-November/004195.html

2 1

Re: [tor-dev] [tor-talk] torsocks is broken and unmaintained
by Jacob Appelbaum 02 Dec '12

02 Dec '12

Matthew Finkel: > On 11/02/2012 07:36 PM, Jacob Appelbaum wrote: >> Nick Mathewson: >>> On Fri, Nov 2, 2012 at 1:34 PM, adrelanos <adrelanos(a)riseup.net> wrote: >>>> >>>> >>>> Could you blog it please? >>> >>> >>> I'd like to see more discussion from more people here first, and see >>> whether somebody steps up to say, "Yeah, I can maintain that" here, or >>> whether somebody else who knows more than me about the issues has something >>> to say. Otherwise I don't know whether to write a "looking for maintainer" >>> post, a "who wants to fork" post, a "don't use Torsocks, use XYZZY" post, >>> or what. >>> >> >> If Robert wants someone to maintain it, I'd be happy to do so. I had >> wanted to extend it to do some various things anyway. I think it would >> be a suitable base for a bunch of things I'd like to do in the next year. >> >> All the best, >> Jake >> > > I saw this thread earlier but didn't have a chance to reply. I was > thinking about volunteering to patch it up and maintain it if no one > else wanted to take it on, also, but if you want to take the lead on it > then I'm more than happy to help you where ever possible...assuming this > is the direction that's decided upon. > Hi, I've pushed my first branch to fix the dlopen bugs: https://gitweb.torproject.org/torsocks.git/shortlog/refs/heads/dlerror It seems to fix the issues on my Ubuntu system. I could use some testing on OS X, other GNU/Linux, and *BSD systems. I've also updated the bug: http://code.google.com/p/torsocks/issues/detail?id=3 One person has found that it fixed the issue for them as well. Also - it seems that we probably should address this issue very soon: http://code.google.com/p/torsocks/issues/detail?id=37 https://trac.torproject.org/projects/tor/wiki/doc/torsocks#WorkaroundforIPv… I've taken a stab at at least blocking IPv6 connect() calls: https://gitweb.torproject.org/torsocks.git/shortlog/refs/heads/ipv6 https://gitweb.torproject.org/torsocks.git/commit/95528585c1d13b0e17e9d3538… Thoughts? All the best, Jake

4 5

OutreachProgramForWomen
by Buket akın 02 Dec '12

02 Dec '12

Hi everybody, My name is Buket Akın and I am from Turkey, Çanakkale. I am computer engineering student at Çanakkale 18 Mart University. I am going to refer " Stem Usability Improvements" project. Please can you tell me what can I do about project? Thanks very much for your kindness.

2 1

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