[tor-dev] Extending deadline for small features in 0.2.3.x by one week (to the 13th)

Jacob Appelbaum jacob at appelbaum.net
Tue Jan 10 02:13:29 UTC 2012

On 01/09/2012 06:01 PM, Nick Mathewson wrote:
> On Mon, Jan 9, 2012 at 8:49 PM, Jacob Appelbaum <jacob at appelbaum.net> wrote:
>> Should I make such a branch and request it for review?
> I don't think this is a good idea for 0.2.3.x without data.  Specifically:
>    * What fraction of servers on the net right now use 2048-bit RSA
> link keys and 2048-bit DH groups?  (Or 1024 bit RSA keys and 1536-bit
> DH keys, etc)

All new EV certs must be 2048-bit RSA - generally speaking, they all use
1024-bit DH groups or a different default provided by the web server

>    * How much would this slow down typical clients and servers?

That's a good question - how shall we answer that?

>>From a security POV, increasing the link key modulus size of 2048 bits
> doesn't seem to do anything useful.  If somebody wants to decrypt an
> intercepted communication, the DH g^x value is what they need to
> solve.  OTOH, if we want to stop somebody from *impersonating* a
> server, then using a 2048-bit link key wouldn't do any good: factoring
> the identity key would give equally good results.

I want to stop sniffers from having useful data. A 2048-bit link key
with a 2048-bit DH group seems like a fine idea and seems to be far
beyond the current reach of anything public - whereas 1024bit seems less
than perfect in short order...

> So I think unless we can make identity keys larger, increasing link
> key size doesn't help.  And without analysis, making the above changes
> on this timeframe seems like a worrying idea.

I think that is only true for active attacks.

> So my thought is that we should target 0.2.4.x for this kind of thing,
> and do it properly.

Ok. I suppose the good news is that this is all server side. So we
really only need a few thousand servers to upgrade rather than millions
of clients, right?

All the best,

More information about the tor-dev mailing list