[Moderator's note: Anonymously forwarded at the request of the sender. If you reply to this, please don't attribute it to me, I didn't send it. --Perry]
Begin forwarded message: [Perry, please forward this anonymously, if you're permitting that these days] On Tue, Sep 14, 2010 at 08:15:52AM -0400, Perry E. Metzger wrote: > The decision that 1024 bit keys are inadequate for code signing is > likely reasonable. The idea that 2048 bits and not something between > 1024 bits and 2048 bits is a reasonable minimum is perhaps arguable. > One wonders what security model indicated 4096 bits is the ideal > length.... I ran into a mindboggling one a couple of weeks ago: a customer complaint that "our new certificate doesn't work" when loaded into one of my employer's SSL offload devices. The actual cause was that the customer had loaded a 4096 bit key and caused end-to-end performance to fall to about 12 TPS from the 1500 TPS they were seeing with their previous 1024 bit key. When we inquired why they were using a 4096 bit key, they indicated that their "information security department" had imposed the requirement that their service keys had to be "twice as long as the CA's key" so that "we are not the weak link in our customers' security". It took some time, but I think we explained the deep folly of this new policy to them. I am a big fan of keys in the 1280-1536 bit range for SSL server certificates. Surveying a large number of commercially signed certificates on the Internet I see the overwhelming majority expire within 3 years of issue. This suggests to me that even if NIST is correct that 2048 bit RSA keys are the reasonable the minimum for new deployments after 2010, much shorter keys are appropriate for most server certificates that these CAs will sign. The CA keys have lifetimes of 10 years or more; the server keys a a quarter to a fifth of that. Making 2048 bit keys the standard on individual servers will reduce server performance to the extent that initiatives like "HTTPS everywhere" will become impractical. Yes, I/O is usually the bottleneck for most servers, but increasing the SSL handshake cost by a factor of 10 changes that quite dramatically. Meanwhile, 1280 bit keys offer a huge increase in resistance to factoring within the next decade and have much less performance impact for servers (since the performance impact on clients is so widely distributed for the HTTPS case I think it can be ignored, but this is of course better for 1280 bit keys too). But people look at the NIST document that recommends 2048 bit keys after 2010 (which I do think is a somewhat misguided recommendation for keys as short-lived as web server keys, though definitely correct for CA keys) and decide to be "double safe" and we get lunacy like Debian trying to atone for their past OpenSSL sins by using 4096 bit keys everywhere and, as a practical matter, *reducing* the spread of service deployment over HTTPS because with 4096 bit keys, you just can't. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com