Let's assume I want to setup a HTTPS service on a modern-but-no-so-speedy x86 server without any form of hardware cryptographic accelerator.

Which key algorithm should I choose for the server key in order to maximize server performance with respect to TLS connections/second? Once generated, the public key will be delivered to the CA as part of the signing request.

The server is not critical. A security level equivalent to a symmetric 80-bit key is sufficient: that means (according to NIST) 1024 bits for RSA, 1024/160 bits for DSA, 160 bits for ECDSA, etc.

I can look at performance for raw signing of a popular crypto library to get an idea, but SSL handshake involves more steps than that (key exchange in particular) and I am not sure if the fastest signing algorithm leads to the best overall handshake performance.

  • 1
    Does compatibility matter? EC is fast, but support isn't that great. Nov 17, 2012 at 9:27
  • @CodeInChaos Clients will mainly be popular browsers. I think ECC is supported (IE8, Chrome, FF10). Nov 17, 2012 at 9:32

1 Answer 1


With a modern but not-so-speedy x86 processor, and a good enough implementation, cryptography speed will not be the bottleneck. For instance, consider a quite cheap AMD Athlon 2650e processor, a not-so-modern and really-not-so-speedy processor that I have in my home file server; it is clocked at 1.6 GHz and has a single core. It can still do about 2200 RSA private key operations per second (for a 1024-bit RSA key). I seriously doubt that the Linux kernel on which this machine runs can cope with 2200 new TCP connections per second...

(Note that for anything related to RSA, running an x86 CPU in 64-bit mode is a huge win -- that's what I do with my cheap server, by the way. In 32-bit mode, divide the figure by 3 or 4; this would still be quite respectable performance.)

Also, SSL/TLS has a feature known as "abbreviated handshake" which is about a client connecting again and reusing the asymmetrically exchanged secret of a previous handshake. See section 7.3 of the standard. The abbreviated handshake involves symmetric cryptography only, no RSA. Note that, in practice, the best thing about abbreviated handshake is that it implies less network packets and lower latency; the lower CPU usage is nifty but not so visible when actually measured.

Assuming that you nonetheless find the asymmetric part of SSL to be huge on the CPU budget, your best bet will still be a "plain RSA" cipher suite, although there could be a tie with ECDHE cipher suites (but the only elliptic curve which is decently supported by existing clients is the P-256 curve, which is fine but somewhat an overkill if you just aim at 80-bit security).

SSL/TLS also uses symmetric cryptography, and that one can use some CPU, too. An x86 CPU is more than powerful enough to encrypt all data which can go through a 100 Mbits/s link, but you can have some savings if you choose your algorithms properly. In practical terms, this means: use AES or RC4, not 3DES. AES will be exceptionally fast and cheap if your CPU offers the AES-NI instructions (and if your SSL implementation uses them, of course).

For the hash algorithm, MD5 is somewhat faster than SHA-1, but SHA-1 can already process 240 Mbytes/s (mega-bytes, not megabits) on my cheap AMD CPU.

So this points at TLS_RSA_WITH_RC4_128_SHA and TLS_RSA_WITH_AES_128_CBC_SHA to be the cipher suites of choice for who wants to get the most connections per second for the least CPU. Or possibly TLS_ECDHE_RSA_WITH_RC4_128_SHA or TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, which will be less widely supported, but will give you Perfect Forward Secrecy, which can be a nice thing to have.

This being said, performance can depend a lot on architectural details and the exact operation environments, therefore you shall measure. Try it and see if changing the cipher suite makes any actual difference. Remember that performance has often a lot more to do with the amount of efforts invested in the protocol implementation, than with the intrinsic merits of the algorithms themselves.

  • Your RSA numbers are higher than I expected. The numbers on ebacs(ronald1024) are far worse. Any idea where the difference comes from? Nov 17, 2012 at 15:34
  • My server uses Unbuntu 12.04, which comes with OpenSSL 1.0.1, a rather recent release. Most of the measures in ebacs are older and thus, necessarily, use an older version of OpenSSL. My guess is that the OpenSSL developers added some optimizations in their code, so that it runs better on amd64 systems. Nov 18, 2012 at 13:43
  • Just a note now that it's been more than 5 years since this answer. SHA-1 now has hardware-accelerated instructions on many processors (similar to AES-NI for AES), and ChaCha20 is gaining speed for use as a high-performance cipher.
    – forest
    Feb 1, 2018 at 3:44
  • @forest I just stumbled upon it as well. Should it be brought up to date?
    – Nico
    Mar 7, 2018 at 12:38

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .