On Mon, Jan 9, 2012 at 9:13 PM, Jacob Appelbaum <[email protected]> wrote: > On 01/09/2012 06:01 PM, Nick Mathewson wrote: >> On Mon, Jan 9, 2012 at 8:49 PM, Jacob Appelbaum <[email protected]> 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, -- Nick _______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
