[tor-dev] Extending deadline for small features in 0.2.3.x by one week (to the 13th)
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