Friday, September 06, 2013

Tor is still DHE 1024 (NSA crackable)

After more revelations, and expert analysis, we still aren't precisely sure what crypto the NSA can break. But everyone seems to agree that if anything, the NSA can break 1024 RSA/DH keys. Assuming no "breakthroughs", the NSA can spend $1 billion on custom chips that can break such a key in a few hours. We know the NSA builds custom chips, they've got fairly public deals with IBM foundries to build chips.

The problem with Tor is that it still uses these 1024 bit keys for much of its crypto, particularly because most people are still using older versions of the software. The older 2.3 versions of Tor uses keys the NSA can crack, but few have upgraded to the newer 2.4 version with better keys.

You can see this for yourself by going to a live listing of Tor servers, like Only 10% of the servers have upgraded to version 2.4.

Recently, I ran a "hostile" exit node and recorded the encryption negotiated by incoming connections (the external link encryption, not the internal circuits). This tells me whether they are using the newer or older software. Only about 24% of incoming connections were using the newer software. Here's a list of the counts:

14134 -- 0x0039 TLS_DHE_RSA_WITH_AES_256_CBC_SHA
 5566 -- 0xc013 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
  905 -- 0x0033 TLS_DHE_RSA_WITH_AES_128_CBC_SHA

The older software negotiates "DHE", which are 1024 bit Diffie-Hellman keys. The newer software chooses ECDHE, which are Elliptical-Curve keys. I show the raw data because I'm confused by the last entry, I'm not sure how the software might negotiate ECDHE+3DES, it seems like a lulz-worthy combination (not that it's insecure -- just odd). Those selecting DHE+3DES are also really old I think. I don't know enough about Tor, but I suspect anything using DHE+3DES is likely more than 5 years old.

(By the way, I used my Ferret tool to generate this, typing "ferret suites -r ".)

The reason software is out of date is because it takes a long time for repositories to be updated. If you type "apt-get install tor" on a Debian/Ubuntu computer, you get the 2.3 version. And this is what pops up as the suggestion of what you should do when you go to the Tor website. Sure, it warns you that the software might be out-of-date, but it doesn't do a good job pointing out that it's almost a year out of date, and the crypto the older version is using is believed to be crackable by the NSA.

Of course, this is still just guessing about the NSA's capabilities. As it turns out, the newer Elliptical keys may turn out to be relatively easier to crack than people thought, meaning that the older software may in fact be more secure. But since 1024 bit RSA/DH has been the most popular SSL encryption for the past decade, I'd assume that it's that, rather than curves, that the NSA is best at cracking.

Therefore, I'd suggest that the Tor community do a better job getting people to upgrade to 2.4. Old servers with crackable crypto, combined with the likelyhood the NSA runs hostile Tor nodes, means that it's of much greater importance.

Update: The above list are the incoming connections from other Tor servers. The following is a list of outgoing connections (since this is an exit node). This has nothing to do with the above discussion, I just include it here for completeness.

      count  suite - description
      39611 0x0005 - TLS_RSA_WITH_RC4_128_SHA
      30138 0x0035 - TLS_RSA_WITH_AES_256_CBC_SHA
      14569 0xc011 - TLS_ECDHE_RSA_WITH_RC4_128_SHA
      10043 0x0004 - TLS_RSA_WITH_RC4_128_MD5
       8576 0xc007 - TLS_ECDHE_ECDSA_WITH_RC4_128_SHA
       7100 0x0039 - TLS_DHE_RSA_WITH_AES_256_CBC_SHA
       4081 0x002f - TLS_RSA_WITH_AES_128_CBC_SHA
       2077 0xc014 - TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
       1900 0x0088 - TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA
       1090 0x0084 - TLS_RSA_WITH_CAMELLIA_256_CBC_SHA
        481 0xc013 - TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
        337 0x000a - TLS_RSA_WITH_3DES_EDE_CBC_SHA
        102 0xc009 - TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
        101 0x0016 - TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
         83 0x009f -
         78 0xc030 - TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
         35 0xc02f - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
         16 0x0033 - TLS_DHE_RSA_WITH_AES_128_CBC_SHA
          6 0x003d - TLS_RSA_WITH_AES_256_CBC_SHA256
          6 0xc028 - TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384


Anonymous said...

Fascinating! Thank you for the analysis and data. Do you know where the 1024-bit limit on DHE comes from? Is that a Tor-specific limitation? Is it that the older versions generated a 1024-bit DH key by default? I don't see anything in the specification of TLS that limits DH to 1024-bit keys.

arc said...

In principle, the shared secret can have any size. A cursory Google search shows NSS had a 1024-bit limit that was lifted in 2004. Have you checked 1024-bit is always the size chosen by the encryption software?

Also, I know 1024-bit factorization is likely "broken in practice", but I couldn't find much info on Diffie-Hellman key exchange sizes. Could you link to it?

Shawn said...

This is a helpful post that highlights an important security issue. However, the paragraph on Tor software being out of date--and the reasons it might be so--isn't quite right. The current recommended stable version of Tor is The current alpha release is Tor, and people running relays are being encouraged to use this version on the mailing lists. So the repositories, by recommending Tor 0.2.3.x, aren't necessarily out of date. However, the Tor website does advise against using the Ubuntu repositories because they aren't "reliably updated" ( Also, the most up to date version of Tor can be found at the following repository: deb tor-nightly-0.2.4.x-wheezy main. None of this, of course, is to say that 2048 bit keys shouldn't be adopted as quickly as possible, but I think it's important to be clear about which version of Tor is which.

Anonymous said...

If you weren't so clearly misinformed I'd think maybe I actually have something to worry about. However you didn't even get the recommended version right. The 2.4 version is a release candidate and wouldn't normally be recommended by the Tor project. When it is ready it'll certainly be the recommended version no doubt. You come off more like an incompetent reporter than someone who has a clue what they are talking. Learn to read. The project clearly advises users NOT to use the version of Tor shipping with Ubuntu. The version shipping with Debian is kept up to date. 2.3.x is the latest stable release and what most users should be using. You doing nothing more than speculating on something you have no clue about.

dre said...

Run 1024 DHE TLS over OpenVPN configured with OpenSSL configured with enable-ec_nistp_64_gcc_128 to support ECC curve P-256. Sounds layered and suboptimal, but suffices?

Anonymous said...


The article is a bit weak on the details:

Did you do the traffic analysis after "your" TOR-Software decrypted the target-adress. (have you altered the tor software or "hooked" the decryption routine, that you can analyse the negotiated keys)

Or did you really only run a rouge exit node (one that redirects, filters and manipulates out and ingoing traffic comming out or in of your exit node )

And just baited about https-everywhere and weak SSL-encryption.

Ron said...

> the newer Elliptical keys may turn out to be relatively easier to crack than people thought

That wold be news to me. Do you have a reference?

Anonymous said...


> That wold be news to me. Do you have a reference?

There's concern that the constants used to define the elliptical curves were influenced by the NSA and give them a way to break it.

Anonymous said...

One thing to remember is that traffic once recorded can be scrutinized any time. Get the uncrackable encrypted data today and break it the day after tomorrow.

So updating to the presumably less (or more) insecure version which uses elliptical keys won't help you with the things you did with Tor 2.3 in case your traffic has been recorded and stored away by the NSA during that time.

Anonymous said...

So, why not use both ECDHE and DHE to encrypt? (and use zillion-bits)