On Mon, Jan 9, 2012 at 9:13 PM, Jacob Appelbaum jacob@appelbaum.net wrote:
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.
Well, we can't forge EV certs, so we should probably instead be looking at the fraction of 2048 non-EV certs out there.
Also, having longer RSA keys than DH groups is totally backwards for our needs. We'd like the work factor for breaking forward-secrecy to be pretty high, since it's relevant for longer, whereas the work factor for impersonating a server is less important, since we can move to longer keys later.
I wonder if EFF's SSL observatory has data here.
* How much would this slow down typical clients and servers?
That's a good question - how shall we answer that?
Testing or calculation, I'd guess.
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...
For beating passive observer, it's the DH group size that matters.
[...]
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?
Sounds right. Though really, we should also be looking into similar increases in key strength for our other crypto too, particularly our circuit handshake. My new-crypto-ops draft tried to make progress here; I should try to revise it soon.
cheers,