Future proof your certificate with a 2048 bit key
It was time to renew a couple of certs and it turned out that the CSR I had originally used was generated with a 512 bit key. Dynadot, who, by the way, offers a pretty sweet $15/year price on single root RapidSSL certs, suggested that I regenerate with a minimum of 1024 bits.
Indeed, it looks like 1024 bit key length is the minimum currently recommended. In fact, depending on whom you ask, it may already be insufficient.
NIST guidelines are comparatively optimistic, but even according to their 2007 Recommendation for Key Management, time for 1024 bit keys is passing quick.
| Algorithm security lifetimes | Symmetric key algorithms (Encryption & MAC) |
FFC (e.g., DSA, D-H) |
IFC (e.g., RSA) |
ECC (e.g., ECDSA) |
|---|---|---|---|---|
| Through 2010 (min. of 80 bits of strength) |
2TDEA 3TDEA AES-128 AES-192 AES-256 |
Minimum: L = 1024; N =160 |
Minimum: k=1024 |
Minimum: f=160 |
| Through 2030 (min. of 112 bits of strength) |
3TDEA AES-128 AES-192 AES-256 |
Minimum: L = 2048 N = 224 |
Minimum: k=2048 |
Minimum: f=224 |
| Beyond 2030 (min. of 128 bits of strength) |
AES-128 AES-192 AES-256 |
Minimum: L = 3072 N = 256 |
Minimum: k=3072 |
Minimum: f=256 |
The trade off with longer key length is of course speed, decryption speed in particular, as that's what the server will be doing. The penalty is significant. According to a study titled "Performance Analysis of Secure Web Server Based on SSL", doubling of the key length resulted in nearly 8x performance penalty:
| RSA Key Size | Performance |
|---|---|
| 512 bit | 11 ms |
| 1024 bit | 68 ms |
| 2048 bit | 481 ms |
In my case, I'm working with low volume applications, 2048 bit key length should be fine:
openssl genrsa -rand /dev/urandom -out your.name.key 2048
openssl req -new -nodes -key your.name.key -out your.name.csr
Leave a comment