Key length and PK algorithm of TOR

[Nick Mathewson]

On Fri, Dec 31, 2010 at 5:10 PM,  <andrew at torproject.org> wrote:
> On Fri, Dec 31, 2010 at 09:21:53PM +0100, canconsulting at web.de 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 majordomo at torproject.org with
unsubscribe or-talk    in the body. http://archives.seul.org/or/talk/