
Most TOR servers are vulnerable (NSA crackable) - cklaus
http://blog.erratasec.com/2013/09/tor-is-still-dhe-1024-nsa-crackable.html
======
anologwintermut
Given the extent of the five eyes (NSA,GCHQ,DSD, etc) taping of major fiber
lines, Tor is almost certainly useless against the NSA even without backdoors.
The NSA doesn't need to resort to expensive key cracking operations to break
either the anonymity or confidentiality of Tor. They just have to be able to
see entry and exit node traffic.

From the original paper by the Tor developers:

"A global passive adversary is the most commonly assumed threat when analyzing
theoretical anonymity designs. But like all practical low-latency systems, Tor
does not protect against such a strong adversary." \--- Tor: The Second-
Generation Onion Router
[http://www.dtic.mil/dtic/tr/fulltext/u2/a465464.pdf](http://www.dtic.mil/dtic/tr/fulltext/u2/a465464.pdf)

~~~
sillysaurus2
I wonder why the common assumption is that the NSA doesn't run Tor nodes. Why
wouldn't they?

The NSA's (authorized) budget is $10.8 billion[1]. For $5 you can get a server
with 20GB SSD and 1TB of transfer per month. It doesn't seem like it'd take
very much money to be able to ensure that at least, say, 1% of Tor users'
traffic passes through your entry and exit nodes, de-anonymizing them. So over
a long enough time scale, that would de-anonymize quite a lot of interesting
traffic, and interesting users.

One solution is VPN over Tor. But the NSA claims they've cracked 30 VPN
providers, and are focused on cracking the rest as soon as possible. That's a
_lot_ of compromised VPN providers.

You could set up your own server and use that as a VPN, but if you pay with
Bitcoin, then it's trivial to analyze the blockchain to tie your identity to
the server, unless you use a tumbling service like bitcoinfog. But even if you
manage to get a server set up anonymously, then what? You still would want to
use VPN over Tor, since that's your best bet for privacy. But as soon as you
get de-anonymized on Tor, that correlates your home IP address with your
anonymous server, thus de-anonymizing your server too.

I can't think of any options to be truly safe from a global passive adversary
that doesn't also cost >1MM to set up initially. Any ideas?

[1] [http://www.washingtonpost.com/wp-
srv/special/national/black-...](http://www.washingtonpost.com/wp-
srv/special/national/black-budget/)

~~~
rubikscube
Do you have a source for the claim that the NSA has cracked thirty VPN
providers? The only source I've seen so far that makes any similar claim was
the cryptome.org document for prosecutors which was a hoax.

~~~
eliasmacpherson
[http://www.nytimes.com/2013/09/06/us/nsa-foils-much-
internet...](http://www.nytimes.com/2013/09/06/us/nsa-foils-much-internet-
encryption.html?pagewanted=4&_r=0) ctrl-f VPN.

What is the cryptome document for prosectors that you refer to?

~~~
eliasmacpherson
I now assume you mean this:

[http://cryptome.org/2013/09/computer-
forensics-2013.pdf](http://cryptome.org/2013/09/computer-forensics-2013.pdf)

[http://cryptome.org/2013/09/computer-
forensics-2013-hoax.pdf](http://cryptome.org/2013/09/computer-
forensics-2013-hoax.pdf)

That's a pretty obvious hoax, detective "Stu Pitt" and "Laughlin Foo". It's
good that it was quickly labelled as such.

------
reirob
"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."

So it is suggested to update to a newer version that uses EC, but we are not
sure if EC is not breakable? Others ([1], [2]) suggest that RSA is more secure
than EC!?

I wish that the security experts could give "clear" advise.

EDIT: Added proper links to sources suggesting RSA over EC.

[1] Bruce Schneider in [http://www.theguardian.com/world/2013/sep/05/nsa-how-
to-rema...](http://www.theguardian.com/world/2013/sep/05/nsa-how-to-remain-
secure-surveillance)

"Prefer symmetric cryptography over public-key cryptography. Prefer
conventional discrete-log-based systems over elliptic-curve systems; the
latter have constants that the NSA influences when they can."

[2] Fefe (it's in German)
[http://blog.fefe.de/?ts=acd52294](http://blog.fefe.de/?ts=acd52294)

~~~
pfortuny
Regarding ECC, whenever a "constant" appears in a cryptographic algorithm,
BEWARE.

Yes, I know about "nothing up my sleeve" numbers... However the ones used for
ECC are not of this type.

What a sad state of affairs.

~~~
nullc
> However the ones used for ECC are not of this type.

Yes they are. The P-XXXr curves which are used by most of the ECC using web
(and Tor, when it uses ECC) were generated by using a deterministic strongly
pseudo-random procedure which you can repeat for yourself. See page 187 of
FIPS 186-3.

~~~
nullc
Okay, I need to eat my words here.

I went to review the deterministic procedure because I wanted to see if I
could reproduce the SECP256k1 curve we use in Bitcoin. They don't give a
procedure for the Koblitz curves, but they have far less design freedom than
the non-koblitz so I thought perhaps I'd stumble into it with the "most
obvious" procedure.

The deterministic procedure basically computes SHA1 on some seed and uses it
to assign the parameters then checks the curve order, etc.. wash rinse repeat.

Then I looked at the random seed values for the P-xxxr curves. For example,
P-256r's seed is c49d360886e704936a6678e1139d26b7819f7e90.

_No_ justification is given for that value. The stated purpose of the
"veritably random" procedure "ensures that the parameters cannot be
predetermined. The parameters are therefore extremely unlikely to be
susceptible to future special-purpose attacks, and no trapdoors can have been
placed in the parameters during their generation".

Considering the stated purpose I would have expected the seed to be some small
value like ... "6F" and for all smaller values to fail the test. Anything else
would have suggested that they tested a large number of values, and thus the
parameters could embody any undisclosed mathematical characteristic whos
rareness is only bounded by how many times they could run sha1 and test.

I now personally consider this to be smoking evidence that the parameters are
cooked. Maybe they were only cooked in ways that make them stronger? Maybe????

SECG also makes a somewhat curious remark:

"The elliptic curve domain parameters over (primes) supplied at each security
level typically consist of examples of two different types of parameters — one
type being parameters associated with a Koblitz curve and the other type being
parameters chosen verifiably at random — although only verifiably random
parameters are supplied at export strength and at extremely high strength."

The fact that only "verifiably random" are given for export strength would
seem to make more sense if you cynically read "verifiably random" as
"backdoored to all heck". (though it could be more innocently explained that
the performance improvements of Koblitz wasn't so important there, and/or they
considered those curves weak enough to not bother with the extra effort
required to produce the Koblitz curves).

~~~
tptacek
You consider it smoking evidence of "cooked" parameters that he hashed a
random string?

This is the technique suggested by all of IEEE-1363 2000, and in every place
its suggested, the standard is at pains to suggest that it provides only a
degree of assurance; the standard authors go as far as to repeat the exact
same text in each location (RSA, DSA, ECC, &c) while customizing the "what
could go wrong" part of the paragraph.

1363 predates the NIST curves, for whatever that's worth.

~~~
pfortuny
I am now rather confused in my ignorance... So the parameters (for ECC) were
chosen "at random" theoretically (and so here lies the trust inherent to
these?). Thanks for the info.

~~~
nullc
The parameters are derived from the SHA1 of high entropy values of unspecified
origin.

It means they very very likely couldn't have algebraically produced a single
set of specific magic evil values that enabled them to crack the cryptosystem,
a true backdoor, since it would have been computationally infeasible to get
SHA1 to output the right values.

However, they could have tried billions and billions of sha1 seeds looking for
parameters which met some unknown to us characteristics which made the
parameters stronger or weaker. Their "veritably random" procedure could have
easily foreclosed this possibility, as was later done for some different
parameter sets, but they did not.

~~~
tptacek
So that's true, but remember that they're simply employing the process that
IEEE 1363 described years earlier. The circumstances are different: IEEE was
trying to explain _how_ to generate parameters, and NIST was specifying
_which_ parameters to use, but the methodology is the same.

It is thus not particularly "telling" that there's an opaque SHA-1 seed. That
is to say, it's not a "tell" that they didn't use a simple string (like the
digits of pi or something), because that's not the IEEE method.

I preemptively agree that we'd have been better off had the seed been
transparently generated, too.

------
m_ram
2.3.25 is the current stable version. 2.4.* is in development. Tor server
operators would have to compile from source or use the upstream deb/rpm repos.

[https://www.torproject.org/download/download-
unix.html.en](https://www.torproject.org/download/download-unix.html.en)

------
contingencies
Posted a gentoo bug:
[https://bugs.gentoo.org/show_bug.cgi?id=484154](https://bugs.gentoo.org/show_bug.cgi?id=484154)

------
eksith
Debian/Ubuntu isn't alone in this. It should be noted that the majority of
nodes are using Linux and of those, the 0.2.4 package is still not available
unless you're running some flavor of "untested" or other bleeding edge distro.

Of course that doesn't stop operators from simply downloading the latest
package themselves from the Tor project or compiling from source.

------
tptacek
_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._

Wait, what?

------
coopdog
So why isn't the repo up to date?

I honestly don't know the answer as I don't deal with Linux repo's much

~~~
lcedp
Because 2.4 is still marked as alpha. Versions on the torproject download
page, their repo and Ubuntu repo all match.

    
    
        % wajig policy tor
        tor:
          Installed: 0.2.3.25-1
          Candidate: 0.2.3.25-1
          Version table:
         *** 0.2.3.25-1 0
                500 http://ua.archive.ubuntu.com/ubuntu/ raring/universe amd64 Packages
                100 /var/lib/dpkg/status
             0.2.3.25-1~quantal+1 0
                500 http://deb.torproject.org/torproject.org/ raring/main amd64 Packages

------
doomrobo
I don't see how ECDHE has any effect on the (in)security mentioned in the
article. It clearly states that the RSA keys being only 1024 bits is the
problem. How does using ECDHE-RSA change this?

------
thingummywut
Why is ECDHE+3DES a "lulz-worthy combination"?

