Performance Comparison of Different SSL Ciphers

My apologies for this being a bit off topic, but I have yet to find any good data for this anywhere online and so I figured the community here might be able to point me in the right direction.

I am looking for relative performance benchmarks between the various different ciphers one might use?

i.e. Just even some baselines on a single common processor architecture would be fantastic (say an Intel E3-1230 v5, or really any version of that processor, or any other common Intel CPU).

In my case, I care most about the actual key exchange part as that is the massive lions share of my CPU usage (and the bulk crypto can take advantage of CPU acceleration features), but others may care separately about the key exchange portion plus actual throughput.

This is relevant as it might impact which ciphers I chose and how I order them preference wise.

Any thoughts are appreciated! It seems like this is important information for the community to have in order to make good decisions about securing the Internet.

So I have been aware of that OpenSSL command for quite some time, but I don't think it maps directly to what I am looking for (though I would be happy to be proved incorrect). Knowing how many bytes per second can be encrypted/decrypted once the bulk cipher has been negotiated is not particularly interesting to me.

I don't think any of the output from that command gives me data on how many key exchanges per second each different cipher combo can do does it? Or is the 2048 bit RSA sign/s and verify/s values what I care about for common 2048 bit certs?

How for instance would I compare speeds of these two cipher options? They use the same bulk crypto portion, but one uses ECDHE RSA, and the other uses just plain old RSA for the key exchange.

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 used ECDH for the key exchange and RSA signing on the server and verification on the client. TLS_RSA_WITH_AES_128_GCM_SHA256 uses RSA encryption on the client and decryption on the server. the plain RSA one will probably be slightly faster, but not by much since the time spent doing EC operations is so much less than the time spent doing RSA. plain RSA also doesn't provide forward secrecy, so you should probably avoid it if you can. TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 would be faster than either of those, use a lot less bandwidth, and be more secure unless you're using 3072-bit or larger RSA keys.

Hey all- Following up with some testing results that our in-house QA team performed.

The test setup was on this type of CPU: Intel(R) Xeon(R) CPU E3-1230 V2 @ 3.30GHz

It was running NGINX fronting a Java app.

The content we are retrieving is extremely small, so the vast majority of the CPU time is burned by the asymmetric key exchange, and not a lot in the symmetric crypto.

Each request was a new TCP handshake and SSL connection - session tickets were NOT used (i.e. every connection was a new handshake from scratch).

Tests were run for five minutes each so they should be very accurate.

Results are in max transactions per second:

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) - 1185.93

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) - 1123.08

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) - 1173.71

TLS_RSA_WITH_AES_128_GCM_SHA256 (0x9c) - 1827.53

TLS_RSA_WITH_AES_128_CBC_SHA256 (0x3c) - 1774.19

TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) - 1804.72

TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x0a) - 1343.5

The results are very understandable. The Elliptic curve key exchange is a bit slower than the RSA one as you might expect (the first three ciphers in the list). With that section of three ciphers GCM is the fastest, probably as it can be parallelized where CBC can not (but since we do very little symmetric crypto in this test, it is very close). Then the CBC with SHA1 signing is a little faster than CBC with SHA256 which is also no shock. Then in the first three RSA key exchanges (the next three in the list) the same things hold true for GCM vs CBC and SHA1 vs SHA256. And finally, the last one is still RSA key exchange, but it is significantly slower. Presumably that is because we are doing some bulk crypto with 3DES and that is just abysmally slow since it is not hardware accelerated like AES is.

I should note that this is now my "go to" cipher list for a lot of applications. It prioritizes Perfect Forward Secrecy ciphers first, and prioritizes GCM mode within that set and also SHA256 over SHA1. If none available, it falls back to RSA for key exchange (not PFS) but with the same GCM and SHA256 priorities. And finally, for super old clients, we support RSA with 3DES just to not loose the laggards.

I will also note that I was looking at the default list of ciphers within Chrome recently and I perhaps even like their take on this better. They take it a step further and include DHE_RSA key exchange methods very high up the list and they really push for GCM mode. They also include the CHACHA20_POLY1305 encryption which is a newer stream cipher that replaces RC4 in a lot of ways. It looks like if they have to fall back to CBC they are bumping the AES level to 256 bits instead of 128 before falling back to 128.

It is extremely clear that someone very smart put a lot of thought into this cipher suite selection list. Too bad it is only implemented in the SSL client in Chrome which under most cases does not get to actually chose the cipher used (normally the server does).

The reality for me though is that until all the app server / load balancer vendors support uploading BOTH RSA and ECDSA certs into them so that they can conditionally serve out the best cert type depending on what the client can support, nobody is going to bother using ECDSA certs since they will break a lot of clients that don't support them.

SSL/TLS configurations are only going to get *more* complex here in the near future as you will need to manage both RSA and ECDSA certs for everything... ;-)

Chrome on Windows XP and online services (ironically, usually "security" scanning tools) using older versions of Java and/or OpenSSL are the usual culprits which we get told about. IE on Windows XP is also hobbled, but there aren't many non-corporate users of that any more.