Debian encouraging use of 4096 bit RSA keys

[Perry E. Metzger]

[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 majordomo at metzdowd.com