On 01/09/2012 06:01 PM, Nick Mathewson wrote:
On Mon, Jan 9, 2012 at 8:49 PM, Jacob Appelbaum jacob@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