Re: Debian encouraging use of 4096 bit RSA keys
On Tue, 14 Sep 2010 17:01, h...@debian.org said: I'd appreciate some input from this list about the Debian bias towards 4096 RSA main keys, instead of DSA2 (3072-bit) keys. Is it justified? We have made RSA the default in GnuPG for three reasons: First, DSA 1024 is only supported by more recent versions of OpenPGP implementations whereas RSA is supported for 10 years now with any sane key size. Second, we want to support SHA2 et al as soon as possible; this is not possible with DSA-1024. Third, DSA signing is fast (DSA-3072 is about 7 times faster than RSA-4096) however verification is much slower (~15 times). Given that for most use cases verification is the most prominent operation (think only of checking hundreds of key signatures per key), this is for what we want to optimize. OTOH, DSA vs. RSA is not the real question. I have not seen a threat model for DD keys. I would claim that the best way to attack Debian's code signing is to take over a developer's box and make use of his/her key [1]. With ~ 1000 developers and thus at least this number of boxes and keys this is a by far an easier way for malice actions than even to think about how to break RSA-2048. I doubt that this situation will change in the next 10 years. These keys are used as KSK, as gpg will happily attach subkeys to them for the grunt work... Right, but than you should take the primary key offline or put it on a smart card - this removes the option to attack the primary key on the developer's box. And if one of the subkeys has been compromised it is very easy to replace that subkey. Salam-Shalom, Werner [1] An even easier way is to subvert the upstream source. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Debian encouraging use of 4096 bit RSA keys
[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
Re: Debian encouraging use of 4096 bit RSA keys
Perry E. Metzger pe...@piermont.com writes: One wonders what security model indicated 4096 bits is the ideal length The one that says that if you wind things up past 11 (4096 bits), various things break. (D'you really think they applied any kind of security analysis to the choice of key size? They just wound it up until they got to 11, then declared that the new key size). Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Debian encouraging use of 4096 bit RSA keys
On Tue, 14 Sep 2010, 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 Key lifetime in Debian can be very long, 10 to 15 years. I'd appreciate some input from this list about the Debian bias towards 4096 RSA main keys, instead of DSA2 (3072-bit) keys. Is it justified? These keys are used as KSK, as gpg will happily attach subkeys to them for the grunt work... -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
