On Sat, Sep 7, 2013 at 12:02 PM, krishna e bera <[email protected]> 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 - [email protected] To unsusbscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
