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

[Jacob Appelbaum]

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
software.

>    * 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,
Jake