- tor-dev - lists.torproject.org

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

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

30 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