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. > * 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 _______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
