I was looking into server performance when using various SSL Certificates. Specifically 1024-bits vs 2048 vs 4096. It turns out, it makes a big difference!

I've heard a lot of talk lately about vendors issuing 2048 certs by default nowadays and was wondering what the consensus is in the community.

My line of thinking is that for something like sending contact form data 1024 might be okay, but for e-comm transactions and/or logins 2048 would be more appropriate. Is there a good use case for 4096?

What are the implications of using 1024-bit for sensitive information, is there much more risk of an attack?

Just to clarify: I came across this issue when doing performance testing on an AWS load balancer and yes key size did make a big difference, and yes i've dealt with clients that expect a lot of traffic in bursts so it's a legitimate concern not just a hypothetical.

  • It's my experience that choice of cypher-suite may have an even greater impact than assymmetric keys size - openSSL struggles with some of the EC algorithms while the AES support in Intel chips makes a signifcant impact on load and latency.
    – symcbean
    Mar 10 '14 at 12:43

Switching from 1024-bit to 2048-bit means that the operations with the asymmetric private key will take about 8 times as much CPU. A "normal PC" core can do about 1000 1024-bit RSA operations per second, down to about 125 per second for 2048-bit RSA. Note that RSA is used only at the start of the SSL connection, not afterwards; moreover, in SSL, there is an abbreviated handshake by which the client and the server reuse the cryptographic exchange from a previous handshake. Web browsers and Web servers do that a lot, so the cost of RSA in SSL is really for new clients (i.e. clients who have not connected since the last time they closed and reopened their browser). It thus takes a hundred or so new clients per second to actually see performance issues related to the key size on the server. Not every Web server out there can boast such a context.

I encourage to make measures in an actual realistic context. Microbenchmarks ("how many decryptions per second ?") are not always good predictors.

As for security, 1024-bit RSA is, as yet, unbroken. Current breakage record is RSA-768. Some smart people have tried to equate RSA Key length with symmetric key robustness; see this site for details. The comparison is not perfect because breaking big RSA keys involves some operations which use an awful lot of very fast RAM, quite unlike exhaustive search on a symmetric key (an embarrassingly parallel task which has no need for RAM). Yet, 1024-bit RSA is somewhat equivalent to a 77 to 80-bit symmetric key. That's not enough for the paranoid, but still beyond that which has been demonstrated to be breakable with currently deployed technology.

NIST recommends using 2048-bit RSA keys right now (since 2010). If you use a 1024-bit RSA key, your site won't be broken that way (when it is hacked, it will be through another channel than upfront cryptanalysis); however, your customers might conceive the idea that by using an unfashionably small key, you don't really care about them. It is more about public relations than security...

If you really have actual performance trouble with 2048-bit RSA keys (I don't believe it, but hey, weird things happen), I encourage you to investigate elliptic curves. An ECDHE_ECDSA cipher suite with the P-256 NIST curve will be faster than RSA-1024, and as strong as (arguably stronger than) RSA-2048.

  • I presume one needs ECDSA server certificate and existing RSA-2048 certificate cannot be used?
    – Matrix
    Apr 1 '13 at 13:43
  • Using a certificate means presenting it (the public part) to the clients, and computing operations with the private key. So, indeed, using ECDSA means that the server has an ECDSA key pair, the public key of which being contained in its certificate. Apr 1 '13 at 13:57
  • All very good points. One thing to consider for some applications is that 1024 bit (and eventually 2048) bit WILL be broken. It might be next year or it might not happen for a couple decades but it is an inevitability. Storage space is very cheap. An attack can simply record the session and wait until it becomes economical to attack the key. Now obviously for many situations the encrypted data is time sensitive but you should consider "Will this be a problem if an attacker could record the session now and view it in a couple decades?" If so then RSA-3076 or ECC-256 might be warranted. Mar 17 '14 at 17:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.