Re: [tor-talk] NSA has cracked web encryption!

[Nick Mathewson <nickm@xxxxxxxxxxxx>]

On Sat, Sep 7, 2013 at 12:02 PM, krishna e bera <keb@xxxxxxxxxxxxxx> wrote:

One note about that Schneier essay.  On his website[1], he says:
 "EDITED TO ADD: That was written before I could talk about this.[2]"

[1] https://www.schneier.com/blog/archives/2013/09/the_nsas_crypto_1.html
[2] https://www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.html

So if I'm interpreting him right, [2] is probably where operational
security folks should be focusing in the near term. Not that we
shouldn't be looking at [1] too.

 [...]
> Are there some assurances that Tor is using the best parameters on its
> symmetric, public key and curve cryptography?  And how can we check?

I'm as much in the dark here as you.

Public key:

Older Tors, like 0.2.3 and earlier use RSA-1024 and DH-1024
everywhere.  With Tor 0.2.4, forward secrecy uses 256-bit ECC, which
is certainly better[3] , but RSA-1024 is still used in some places for
signatures.

I want to fix all that in 0.2.5 -- see proposal 220 [3], and George
Kadianakis's draft hidden service improvements, and so forth.  I'd
like to see a Tor that can run with no reliance 1024-bit Z_p crypto
inside the next three to six months, if at all possible.

As for "are these the right parameters" -- whether we should be using
a larger ECC group than curve25519 -- I wish I knew more than I did
today.  Bruce is smart, but he doesn't specialize in ECC as far as I
know.  The ECC people I know have told me that they're pretty sure
that curve25519 is okay.  That said, you can be sure that there will
be lots of discussions in the ECC sphere about appropriate group sizes
in the next months and years, and probably cryptographers will be
reconsidering other non-EC, non-Z_p stuff too.

(One issue here is that designing ECC groups is not an exercise for
the likes of me. Using a curve that we made up ourselves would pretty
much guarantee using cryptographic code we implemented ourselves,
which is not the wisest thing in the world.  Maybe in a few months DJB
or somebody will start pushing a "curve38331" or "curve511187"[4] or
something like that.  If that's so, you can bet we'll be jumping.)


Symmetric key:

We're using AES128.  I'm hoping to move to XSalsa20 or something like
it -- I'm mainly waiting for this one paper to get released about the
right wide-block construction and/or once TLS support exists and/or
once we can finally jettison TLS (which is not a sure thing).

The problem here in my mind isn't key length -- it's that 1) AES
software implementation quality is quite variable, which prevents me
from having confidence in compatible Tor implementations that haven't
spent so much time scrutinizing their underlying cryptographic
libraries, and 2) AES offers a pretty bad security/performance
tradeoff; we could IMO be getting more security per cycle out of our
symmetric cryptography.



[3] This only works once users and relays start upgrading to 0.2.4
though.  Please upgrade!
[4] These curve names are completely hypothetical.


peace,
-- 
Nick
-- 
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsusbscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk