[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-talk] NSA supercomputer



Thus spake cmeclax (cmeclax-sazri@xxxxxxxxxxxxxxxx):

> On Thursday, April 04, 2013 08:17:29 Nick Mathewson wrote:
> > On Thu, Apr 4, 2013 at 5:51 AM, Bernard Tyers <ei8fdb@xxxxxxxxxx> wrote:
> > > Hi,
> > > 
> > > Is there a reason 1024 bit keys, instead of something higher is not used?
> > > Do higher bit keys affect host performance, or network latency?
> > Because in 2003/2004, when we were designing Tor, 1024-bit keys seemed
> > like they would probably be good enough, AND we weren't confident of
> > our ability to support arbitrary key sizes without screwing it up.
> > 
> > But as of 0.2.4, the forward-secrecy[0] parts of Tor[*] now support
> > 256-bit ECC keys, which are probably about as good as 3072-bit RSA/DH
> > keys, and a lot faster for most uses.  I'd like to make more of the
> > authentication parts of Tor support ECC over the next couple of
> > releases.
> 
> Sounds like a good idea. Now I'm going to throw out some possible attacks and 
> scenarios. I'm not sure how all the keys are used, so if I'm wrong, please 
> correct me.
> 
> *Mallory breaks an identity key. He can then pretend to be that relay. 
> Directory servers will notice that two relays are claiming the same identity.

Not necessarily. 

Because identity keys also authenticate the TLS links between nodes, if
you can break/steal relay identity keys, you can perform a number of
attacks at various points between a client and its guard nodes, or with
a device placed upstream of the relay in question. With the secret half
of the identity key, for the most part you get to behave as if you were
actually operating that relay.

These attacks can be quite powerful (ie full deanonymization of all
traffic, even without the use of timing attacks), and can be targeted at
interesting users.

I think identity keys should be either ephemeral or offline for this
reason. See also:
https://trac.torproject.org/projects/tor/ticket/5563
https://trac.torproject.org/projects/tor/ticket/5968
https://trac.torproject.org/projects/tor/wiki/doc/TorRelaySecurity

> *The NSA runs a Tor relay called Eve. Eve passes all connection data to the 
> NSA. Unless Eve gets picked to be a guard, is an exit, or both, she'll get 
> only middleman data, which won't be much use. This attack has nothing to do 
> with key size.
> 
> *The NSA installs Eves at various ISPs that host or pass data for relays. 
> Alice and Bob are talking on Torchat. If Bob runs a relay, a timing attack is 
> impossible unless one of them sends a file, as the data Bob relays will swamp 
> the tiny amount of data they send by Torchat.

If the NSA can also break or steal identity keys, this attack is still
quite feasible :/.

Unfortunately, based on their own statements about the safety of prime
factorization, either the NSA already *can* break 1024bit RSA identity
keys, or they expect to be capable of this very soon. (My bet is that
bathtubs full of DNA will work out before quantum computing does ;).

Either that, or they are running some kind of massive psy-op to get the
world to switch to smaller ECC keys which they *can* break. Based on
their past behavior in terms of their suggestions wrt crypto, it is
probably safest to assume they are acting in good faith about their
statements about prime factorization.

However, it would be interesting to have some benchmarks for high-bit
ECC implementations. It seems to me they should still be faster than
modular exponentiation at the same bitwidth, no?

Sadly though, it's also not as easy to adjust key sizes for ECC-based
operations as it is for prime integer based groups. The problem is we
need to find "safe" ECC curves for each bitwidth..  This seems more
blackmagic to me than anything else in crypto, save for perhaps S-box
design.

> *The NSA runs a Tor relay called Eve. It's picked as the rendezvous point for 
> a hidden service. Can Eve read the plaintext?

No. Nor are there direct ways to tell which RPs get used with which
hidden services. There are some statistical attacks, but they are error
prone (high amounts of false positives, or low accuracy).
 
> *Eve breaks an onion key. She can read the key exchange when Alice connects 
> first to that relay. But unless Eve breaks the onion key for the second and 
> third relays, she can't read Alices' plaintext. Also the onion key will be 
> changed in a few days, so she won't be able to read Alice's connections for 
> long.

Correct. In the current Tor network, the adversary would simply go after
the identity key. It is way more valuable in terms of the attacks it
enables, and way more long-lived by default.

As far as I can tell, also having the onion key doesn't get you much
beyond what the identity key enables, especially if you're an "external"
adversary (such as we would presume the NSA and other intelligence
agencies to be).


-- 
Mike Perry

Attachment: signature.asc
Description: Digital signature

_______________________________________________
tor-talk mailing list
tor-talk@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk