On Fri, Dec 31, 2010 at 5:10 PM, <[email protected]> wrote: > On Fri, Dec 31, 2010 at 09:21:53PM +0100, [email protected] wrote 0.6K > bytes in 20 lines about: > : 1) is there a specific reason why TOR does use RSA with > : a keylength of only 1024 Bit? > > Start here, http://archives.seul.org/or/dev/Dec-2010/msg00012.html. > > : 2) is there a specific reason why TOR does not use ECC, > : which is more secure (with reasonable curve parameters and same > : key length like RSA) *and* uses less or, depending on the > : ECC algorithm, at least not significantly more CPU cycles than RSA? > > A quick answer is most ECC implementations we may want use are patent > encumbered. However, Nick or Roger will have a better answer.
Well, there are at least a number of respectable people who think that some ECC can be used in a non-patent-infringing way. Certicom seems to be taking the position that their patents cover all ECC usage -- and why wouldn't they? -- but others seem to think that ECC using the P groups can be done safely, and DJB of course is quite confident in Curve25519. But to answer your questions, the main reason Tor doesn't use ECC now (and that its RSA keys are 1024 bits except for authority keys) is that back when we designed the relevant parts of the current Tor protocol in 2003-2004, RSA-1024 seemed like a reasonably good idea to us. We figured we could change it pretty easily when it started showing its age, but as [1] should show, it might take a fair bit of engineering to get cipher migration right. There's a related question that people sometimes ask: "Why didn't you make it so Tor could support an arbitrarily large array of cipher combinations?" Three main reasons. First, we were worried about the ciphersuite fingerprinting attacks that plague the cpunk remailer design. If an anonymity design forces users to pick from multiple ciphers, users will stand apart from one another based on their cipher choice. (There's actually an even more subtle argument here; we wrote a paper about it. [2]) Second, we were worried about protocol downgrade attacks and didn't want to have to consider a secure protocol negotiation scheme on top of everything else we were doing. Third, we really wanted to get a working Tor completed in a reasonable amount of time. Robert Ransom and I (and others) are trying to start off a discussion on or-dev about migrating Tor to work with longer keys and faster ciphers; see [1] and [3] for more info there. [1] http://archives.seul.org/or/dev/Dec-2010/msg00012.html [2] http://weis2006.econinfosec.org/docs/41.pdf [3] http://archives.seul.org/or/dev/Dec-2010/msg00013.html peace & happy new year, -- Nick -- Nick *********************************************************************** To unsubscribe, send an e-mail to [email protected] with unsubscribe or-talk in the body. http://archives.seul.org/or/talk/
