- tor-dev - lists.torproject.org

Re: [tor-dev] Tor glossary
by Shondoit 23 Nov '11

23 Nov '11

During translating last week it occurred to me that we do not have a consistent translation for some common phrases. I've set up a first draft of all common words that are used throughout the various Tor projects. Why I'm sending this to tor-dev is the following: - You as developers know which phrases are important for a clear communication of Tor's (and others) workings. I would very much like if you can add to the lists the words that are essential to be consistently translated. (as of writing this, I know I forgot to add 'Introduction Point') - Sometimes different phrases are used throughout the applications. Sometimes it's called an 'exit node' other times it's an 'exit relay'. It would benefit consistency when devs use the glossary for common terms. - Translators sometimes don't know the definition of words, or the context changes. A directory in the Tor context is different from a directory in an OS context. I'm not sure what the best way is to go about doing this, but we need definitions. The last version of the list can be found in my github: https://github.com/Shondoit/torglossary If you have additions to the list, definitions, suggestions, you can either email or clone/fork the repo and add it yourself. Thanks in advance

1 0

Re: [tor-dev] Regarding Metrics project
by Karsten Loesing 17 Nov '11

17 Nov '11

Hi Qiang, I'm cc'ing tor-dev, because I think your original request to work on Java codebases went there. On 11/17/11 2:13 AM, Qiang Wang wrote: > This is Qiang, and I am very interested in Tor project, and want to > contribute something. I was wondering if I can provide any help about > metrics project? > > Could you please let me know your recommendations? Sure thing. Three ideas come to mind: - Improve the consensus-health script: We have a Java program that downloads the network statuses from all eight directory authorities and compares them to each other to detect problems. One of the outputs is a web page [0], another output is a status email [1], and a third is a message sent to an IRC bot [2]. The code [3] needs some love. - Answer the question what fraction of exit relays exit from a different IP than is in their descriptor. This is a typical question that can be answered using the metrics data [4] we have. We'd want to publish the analysis code in the metrics-tasks repository [5], so that others can reproduce the results or refine the analysis. There's already a lot of Java code in that repository, because that's what I use when analyzing metrics data. We have plenty of other analysis questions similar to this one, so if you don't like this one, take a look at the Analysis component in our bug tracker [6]. - Implement an efficient relay-search database. We have a web site for searching relays by IP, nickname, or fingerprint [7], but it's really slow. The main problem is that the database originally was designed for aggregating statistics about relays, not for searching relays. I have two ideas here: The first is to design a separate PostgreSQL database [8] and go crazy with indexes, the second is to try out CouchDB for this [9]. This task isn't really that Java-specific, except for the fact that I'm using Java to import data and send queries. If anything sounds interesting to you, please let me know. I have more information about these tasks and can help you get started. Also look at the research section of the metrics website [10] to learn more. Best, Karsten [0] https://metrics.torproject.org/consensus-health.html [1] https://lists.torproject.org/pipermail/tor-consensus-health/2011-November/0… [2] See the IRC bot nsa in #tor-bots on OFTC, e.g., "< nsa> or: [consensus-health] The following directory authorities set conflicting or invalid consensus parameters: ides bwauthbestratio=1 bwauthcircs=0 bwauthdescbw=1 bwauthkp=10000 bwauthpid=1 bwauthtd=0 bwauthti=0 bwauthtidecay=5000 cbtnummodes=3 refuseunknownexits=1" [3] https://gitweb.torproject.org/metrics-web.git/tree/HEAD:/src/org/torproject… [4] https://metrics.torproject.org/data.html [5] https://gitweb.torproject.org/metrics-tasks.git [6] https://trac.torproject.org/projects/tor/query?status=!closed&component=Ana… [7] https://metrics.torproject.org/relay-search.html [8] https://trac.torproject.org/projects/tor/ticket/2922 [9] https://trac.torproject.org/projects/tor/ticket/4440 [10] https://metrics.torproject.org/research.html

1 0

About JTor project
by Qiang Wang 17 Nov '11

17 Nov '11

Hello there, I am very interested in Tor project, and I want to contribute something to it. In particular, I'd like to work on JTor. Could anyone tell me whom I can contact with for further information regarding getting involved in? -- Thanks & best regards Qiang Wang

2 2

What Should Tor Bridges and Clients Do When They Get Hosed?
by George Kadianakis 12 Nov '11

12 Nov '11

This is not a proposal. So, since some people in this list, who are not in IRC, seemed interested in censorship resistance, I pose this new question: What should Tor bridges and clients do when they hosed in previous schemes? All those previous proposals dealed with ways to detect fingerprinting adversaries, but not with ways to persuade them that what they are seeing is not Tor. There should be a proposal specifying exactly that, and this is a discussion thread (even monologue can be considered a discussion). Let's start with a quick threat model: --- We consider a nation-state adversary who: a) has a list of hosts suspected to be Tor bridges and wants to block them without suffering huge false positives. OR b) sails the Internet to find Tor bridges. The adversary is controlling the state's Internet infrastructure and can inject, modify or block incoming or outgoing traffic. He can build software that speaks and understands network protocols but he cannot deploy humans to do the necessary testing. To complete his goals, the adversary can directly probe hosts to see what protocol they speak, OR he can MITM all connections towards those hosts to see what protocol their clients speak. --- tl;dr we are dealing with MITMs and direct probes here. Naturally, it would be cool if we could just say "Oh right, all bridges and clients speak HTTPS in case of detection; all is cool", but remember that HTTPS is quite hard to spoof right, both in the server and in the client case [1], especially when it has to be done in C and in the tor.git codebase. Ideally, we would want to be as application-layer-neutral [2] as possible, and with the minimum implementation cost possible. So let's handle client and bridge cases separately and have a go. Clients: Proposal 191 allows clients to detect MITM attempts during the SSL handshake, this is good because we don't have to pretend speaking a specific application layer protocol. I think a good solution would be to send an SSL Alert of "Bad Certificate" type and close the connection when clients detect an SSL MITM attempt. That's what Firefox does when a user selects "Get Me Out Of Here!" on the self-signed certificate dialog, and that's what all applications should do (?) when an MITM attack is detected either by certificate or public-key pinning. In the future we might also want to send innocuous HTTP queries like GETting index.html, but we have to be aware of [1]. Bridges: Bridges have it harder. Proposal 187, allows bridges to detect probing attempts after the SSL handshake, when the probing client sends any sort of packet or a badly formed AUTHORIZE cell. This forces bridges to respond with an application-layer-specific message (or close the connection, but that would be rude). This is where I'm not sure what should be done. I think all implementations MUST provide a way for the bridge operator to configure a network service of his own (FTPS, HTTPS, SMTPS, etc.) and have the bridge send all the adversary traffic to that service. That should do it for technical bridge operators, but there probably should also be something on by default, for bridge operators who don't know how to setup net services on their own. The easy choice is an "HTTPS" server with the default Apache "It Works!", or a closed basic access authentication, but really implementing a spoofed HTTPS server in tor will be a PITA, because censors can easily test us by provoking one of [0] (there is a reason that HTTP servers usually require lots of LoCs to work). Maybe we should ship a configured Apache server with the long-term future "Anti-censorship Tor Bundle"? Also, what happens to Tor on Linux when it can't listen on port 443? Or when port 443 is already taken? HTTPS servers on 9001 sure look sketchy. Any ideas are welcome. Any services widely used, frequently seen with SSL support, that handle traffic that kinda looks like Tor's and are easily implementable, are also welcome. [0]: https://en.wikipedia.org/wiki/List_of_HTTP_status_codes [1]: https://en.wikipedia.org/wiki/List_of_HTTP_header_fields https://trac.torproject.org/projects/tor/ticket/2907 [2]: Let's place SSL on the transport layer for now.

2 1

[Patch] test_util.c
by Gisle Vanem 12 Nov '11

12 Nov '11

Those '{}' constructs are not well liked by MSVC (cl v.16.xx). An easy fix: diff --git a/src/test/test_util.c b/src/test/test_util.c index 2146299..64bf52e 100644 --- a/src/test/test_util.c +++ b/src/test/test_util.c @@ -1597,7 +1597,7 @@ test_util_join_win_cmdline(void *ptr) {"a\\\\\\b", "de fg", "H", NULL}, // Backslashes {"a\\\"b", "\\c", "D\\", NULL}, // Backslashes before quote {"a\\\\b c", "d", "E", NULL}, // Backslashes not before quote - {} // Terminator + { NULL } // Terminator }; const char *cmdlines[] = { @@ -1649,7 +1649,7 @@ test_util_split_lines(void *ptr) {"\n\rfoo\n\rbar\r\n", 12, {"foo", "bar", NULL}}, {"fo o\r\nb\tar", 10, {"fo o", "b.ar", NULL}}, {"\x0f""f\0o\0\n\x01""b\0r\0\r", 12, {".f.o.", ".b.r.", NULL}}, - {NULL, 0, {}} + {NULL, 0, { NULL }} }; int i, j; --gv

2 1

[Patch] or/eventdns.c
by Gisle Vanem 09 Nov '11

09 Nov '11

I've made eventdns.c + '-DEVDNS_MAIN' compile and work under Windows / MSVC. Some simple patches: * Use set_socket_nonblocking() instead of the F_SETFL hacks. * Preserve the ret-val from evdns_config_windows_nameservers(). * In main(), call network_init() to call WSAStartup() etc. * Removed 'evdns_resolv_conf_parse(DNS_OPTION_NAMESERVERS, ...' and call evdns_init() instead. This uses 'DNS_OPTIONS_ALL'. Does that really matter? Attached diff-1.txt. (sorry, I'm a Git neophyte). --gv

2 2

SHA-3 isn't looking so hot to me
by Markku-Juhani O. Saarinen 04 Nov '11

04 Nov '11

Watson Ladd: > (HMAC is a bad idea anyway: quadratic security bounds are not the best > possible, we have to use nonces anyway to prevent replay attacks, so > Wegman-Carter is a better idea for better in{faster, more secure}. GCM > would be an example of this.) GCM has quadratic security bounds, not only in the proof but in practice too. Furthermore a 128-bit GCM MAC offers much less than 128-bit security; in this sense it is certainly weaker than, say, MD5-HMAC ! And there are the implementation caveats mentioned already mentioned in the list, including Joux's "forbidden attack" which may indeed be very real in many implementations. GCM also tends to be slow on software. I've been told that GCM was pushed through the NIST standardization process mainly by CISCO who were concerned about the performance of their hardware crypto accelerators (many hash functions are tricky to implement on hardware). There's also the issue of weak keys etc. See http://eprint.iacr.org/2011/202.pdf This came out in ECRYPT II Hash Workshop 2011, 19-20 May 2011, Tallinn, Estonia. The current ECRYPT recommendations take this into account, see section 8.5.5 of "ECRYPT II Yearly Report on Algorithms and Keysizes (2010-2011)" for a brief discussion: http://www.ecrypt.eu.org/documents/D.SPA.17.pdf I should be expanding this work as Niels Ferguson noted in the Redmond Crypto Retreat workshop last August that there's a trivial extension of this attack that allows arbitrary message modification. Also a significantly faster method for identifying weak AES-GCM keys has been discovered. As a hash function researcher I would personally select SHA-512 with digest truncated to required number of bits as an interim solution. SHA-512/256 tends to be faster than SHA-256 in software. Also it makes sense to implement a single hash core rather than two (SHA-256 and SHA-512 are fundamentally different). This is also in the standards, see: http://csrc.nist.gov/publications/drafts/fips180-4/Draft-FIPS180-4_Feb2011.… Cheers, - markku Dr. Markku-Juhani O. Saarinen <mjos(a)reveresecurity.com>

8 8

Subject: Re: The consequences of key compromise (or the reasons for changing)
by Markku-Juhani O. Saarinen 04 Nov '11

04 Nov '11

From: Jon Callas <joncallas(a)me.com> > People should get off of 80-bit crypto as soon as is reasonably possible. This means RSA 1024, SHA-1, etc. NIST recommended doing this by the end of 2010, but are now holding their nose and saying that 2013 is the real new date. Absolutely agree. The 80-bit figure was apparently adopted by U.S. Government some 25+ years ago (skipjack etc). > This seems basically reasonable to me. No one has yet factored a 768-bit number, let alone a 1K one. 768-bit RSA was factored in 2009 and the authors of that paper conjecture that 1024 bits would be factored "within a decade" and recommend that 1024-bit RSA should be phased out within a couple of years. http://eprint.iacr.org/2010/006.pdf I am certainly doing that with the stuff that I am maintaining. > SHA-1 actually looks safer today than it did in 2005. But still. Moving away is a Good Thing, so long as it doesn't make you do something stupid. Well, after the 2005 Wang-Yin-Yu paper which had a 2^69 attack, there was a claimed 2^52 attack in 2009 which turned out to have a flawed cost evaluation. There has also been talk of a 2^63 attack, but that difference can be put down to attack implementation skill and detail. I was always doubtful whether or not those techniques could be expanded to work against the SHA-2 algorithms. It is also funny that many people talk about SHA-2 as if was a single algorithm; there are actually two quite distinct algorithms, one for (now fading) 32-bit architectures (SHA-224,SHA-256) and one for 64-bit algorithms (SHA-384,SHA-512,SHA-512/224,SHA-512/256). The variants of these two algorithms only differ in the number of output bits and the IV values and hence have a constant speed regardless of their digest size. You can run "openssl speed sha" to see a real-world performance comparison on a particular box. Cheers, - markku Dr. Markku-Juhani O. Saarinen <mjos(a)reveresecurity.com>

2 1

The consequences of key compromise (or the reasons for changing)
by Watson Ladd 04 Nov '11

04 Nov '11

Dear all, Recently Zooko forwarded an email asking why we have to migrate. I am outlining the reasons in this email why I believe Tor needs to use stronger cryptography very soon. Tor currently uses RSA-1024 bit keys for OR public identities and 1024-bit Diffie Hellman for the negotiation of keys protecting circuits. It also uses SHA-1 for a hash in serveral applications, including key fingerprints. When deciding if these are adequate it is necessary to think about what compromise gives an attacker and what it costs to compromise Tor cryptography. We are aiming to protect users from TLAs with ASICs. Directory keys are 3024 bit RSA. Compromising a directory key is sufficient to generate directories containing fake entries, and thus break the anonymityof all users who see the fake directory. In the event of a compromise, Tor would be unusable until a new version is put out with a longer key length and new directory keys. But these are long keys. However, the keys that actually sign the directories are 1024 bits, but rotate every 3 months. OR keys are also 1024 bit RSA. Compromise of an OR key enables impersonation of the OR to an OP. Combined with fun and games with BGP it enables impersonation of an OR to other ORs, which can direct significant traffic to the fake OR. Detection is likely as the real OR will notice various refusals to connect by other OR to whom it is not connected. And if you can break the directory key why bother with ORs. Hidden services are also identified by 1024 bit RSA keys. At the circuit level DH keys are 1024 bits. An attacker who compromises these can read data intended for further down in the circuit. In particular they can determine the rest of a circuit if they are the first node. There is also the issue of keysize. A Tor cell is 512 bytes long. Thisis sufficent for only 4 keys, if we pack them very tightly. Smaller keys could enable fast circuit initiation or other cool tricks we cannot use today. So, how strong or weak are RSA-1024 and DH-1024 currently? We are using DH over F_q* where q = a big prime. For DH the best known algorithm is the index calculus. This attack proceeds in 3 steps. The first step, which can be spread over multiple keys is the collection of relations among a factor base, usually of small primes. The second step, again spread over multiple keys, is solving the linear system of equations from the first step. The third step is fast and key specific: given an element h,and generator g we attempt to factor g^s*h over the factor base. The general number field sieve is a very similar algorithm for factoring. It is more complicated but again relies on finding smooth numbers and factoring them with respect to a factor base of small primes. Currently the complexity of these algorithms is L_n[1/3,\sqrt^3_{\frac{64}{9}}]for GNFS and L_n[1/2,c] for index calculus. (From wikipedia). Sadly the sieving stepscan be done very well on special hardware. TWIRL, a specialized hardwaredevice designed by Adi Shamir and Eran Tromer is believed by Shamir and Tromer to be capable of factoring a 1024-bit RSA key in a year at a cost of $10 million dollars. To break 10 directory keys in 3 months is 10 times as many keys, and 4 times the speed. That will be $400 million dollars. That is half the cost of Golden Shield for a year: an amount of money that is not ludicrous. And such a machine once built can crack the next 10 keys for free. The cost is design and fabrication of this device: power is comparatively cheap. Of course, such a machine would be unsuited to other bit sizes. If the attacker instead decides to find a discrete logarithm base for DH over 1024, then they will have the ability to break DH-1024 fairly quickly. I haven't seen a good estimate for the time it would take to do this, but it will be a bit more. It will not be much more. And it will be a total break: once a factor basis is found discrete logs are very fast. So an adversary can spend more time and still be happy with the results. So it isn't just directory signing that is an issue but the link protocol as well. And $400 million is a lot. But when you are the Golden Shield director and someone says "for $400 million we can break Tor for a long time" that is not entirely out of the picture. As technology for ASIC fabrication gets better, this price drops. As GNFS gets better it also drops. As index calculus gets better it drops. And as Balmol's cost disease drives up the cost and budget of Golden Shields regular activities, the price drops. Sincerely, Watson Ladd

3 2

[idle speculation] Combining bridge partioning and limiting directory trust?
by Watson Ladd 04 Nov '11

04 Nov '11

Dear all, I read arma's blog entry calling for someone to see if limiting zig-zag attacks would harm anonymity. Well, I don't have an answer, but I did notice that we could increase the number of bridge authorities by having each bridge authority take a distinct subset of bridges to hand out, and then implementing a honest forwarder that forwards an email asking for bridges to a bridge authority based on some hash function of the requesting gmail address. Compromising an authority results in those bridges being cut off, but only a subset of users are affected. This also prevents zig-zag attacks: there are no clients who see bridges in two distinct authorities mandate. Unfortunately this only works if bridges are careful not to be listed by multiple authorities. Sincerely, Watson Ladd -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin

1 0