What RSA key length should I use for my SSL certif

2019-01-30 03:03发布

问题:

I'm in the process of creating a CSR, and I wonder which is arguably the best length for my RSA key.

Of course, 384 is probably too weak, and 16384 is probably too slow.

Is there a consensus on the key length one should use, depending on the certificate lifetime?

Edit : Like most people, I want my key to be reasonably strong. I'm not concerned that the NSA could maybe break my key in 2019. I just want to know what's the best practice when one plan to do normal business (for example an e-commerce site)

回答1:

This answer is a bit outdated. Be aware that it might not represent current best practice.

If you've kept up-to-date with the field, please consider improving this answer.


Bruce Schneier wrote back in 1999:

Longer key lengths are better, but only up to a point. AES [symmetric cypher] will have 128-bit, 192-bit, and 256-bit key lengths. This is far longer than needed for the foreseeable future. In fact, we cannot even imagine a world where 256-bit brute force searches are possible. It requires some fundamental breakthroughs in physics and our understanding of the universe. For public-key cryptography [asymmetric cyphers], 2048-bit keys have same sort of property; longer is meaningless.

Wikipedia writes:

RSA claims that 1024-bit [asymmetric] keys are likely to become crackable some time between 2006 and 2010 and that 2048-bit keys are sufficient until 2030. An RSA key length of 3072 bits should be used if security is required beyond 2030. NIST key management guidelines further suggest that 15360-bit [asymmetric] RSA keys are equivalent in strength to 256-bit symmetric keys.

RSA Laboratories writes (last time changed 2007 according to archive.org):

RSA Laboratories currently recommends [asymmetric] key sizes of 1024 bits for corporate use and 2048 bits for extremely valuable keys like the root key pair used by a certifying authority

Would be nice, if someone who knows more, could answer why there's this difference.



回答2:

As many customers require compliance with NIST cryptographic standards, I use the guidance in the NIST Special Publication 800‑57, Recommendation for Key Management Part 1, §5.6. Most of our applications are a good fit for 112 "bits" of security, so that corresponds to triple-DES (or a small bump up to 128-bit AES) for symmetric ciphers and a 2048-bit key for RSA. See Table 2 for a rough equivalence.

Valid or not, being able to refer them to a NIST publication helps customers feel better about security (if they bother to ask).



回答3:

Certificate authorities will not sign csrs less than 2048 bits in size so you should generate your csr to be 2048 bits.



回答4:

This coming August, Microsoft is going to deploy a patch to Server 2003/2008, Win7 ect.. that will require the use of a minimum 1024 bit RSA key. So you might as well start making that your "bare minimum" standard.



回答5:

For SSL certificates used on websites, this text from the Thawte.com website (as at 2014-07-22) is important to note:

Industry standards set by the Certification Authority/Browser (CA/B) Forum require that certificates issued after January 1, 2014 MUST be at least 2048-bit key length.



回答6:

I needed to create several new SSL certs and was not satisfied with the answers above because they seemed vague or out dated so I did a little digging. Bottom line the selected answer is correct use "2048-bit keys... longer is meaningless".

Increasing the bit length to 4096 adds a potentially meaningful load to your server (depending on your existing load) while offering basically an insignificant security upgrade

If you are in a situation where you need longer than a 2048 bit key you don't need a longer bit length, you need a new algorithm



回答7:

I think 4096 is ok for RSA

Check This link

The end of the SHA-1 signature is nothing new, but Google has accelerated the process of the chrome. In the next few weeks, you should check their SSL certificates.

This may be helpful



回答8:

ENISA recommends 15360 Bit. Have a look to the PDF (page 35)

http://www.enisa.europa.eu/activities/identity-and-trust/library/deliverables/algorithms-key-sizes-and-parameters-report/at_download/fullReport