I'm doing a performance test on AES with CTR mode and HMAC SHA1 for message authentication and found the openssl speed tool for that.

I run multiple tests with openssl speed -evp sha1 aes-128-ctr aes-128-gcm because I want to compare it to the GCM mode which do encryption and message authentication in a single mode.

Now my question: how can I compare these values? Is the value of the sha1 result the "speed" of the combination of ctr + hmac sha1 because it's the bottleneck or do I have to subtract these two values to get the combined speed of ctr + hmac sha1?

enter image description here

  • 2
    $\begingroup$ HMAC-SHA-1 uses the double call of the SHA-1, one is long (almost hashes as same as the message size) and the other one is short, a single block of SHA1 (512-bit for SHA-1). Short messages suffer from initialization, you might need to consider your real case. For the interpretation of the output see How can I interpret openssl speed output? from Stack Overflow. This is mostly off-topic. $\endgroup$
    – kelalaka
    Feb 10, 2022 at 16:46
  • 1
    $\begingroup$ There aren't any AES-CTR cipher suites. Although CTR is used as underlying tech for GCM, the MAC authenticated ciphersuites are all based on CBC, unfortunately using MAC-then-encrypt. Of course, as CTR and CBC use as many block encrypts, the speed difference should be negligible for sane implementations (but there is a lot of insanity in this world). $\endgroup$
    – Maarten Bodewes
    Feb 10, 2022 at 16:56
  • 2
    $\begingroup$ I’m voting to close this question because this is about interpreting the result of a cryptographic library. There is already HMAC speed on Stack Overflow already. $\endgroup$
    – kelalaka
    Feb 10, 2022 at 17:21

1 Answer 1


Is the value of the sha1 result the "speed" of the combination of ctr + hmac sha1 because it's the bottleneck or do I have to subtract these two values to get the combined speed of ctr + hmac sha1?

First of all, you should use AES-CBC just to be sure that you are using the right combination of algorithms. AES-CBC is much slower than AES-CTR on my machine. This is probably due to buffering; it is possible to precalculate large parts of the key stream for AES-CTR.

TLS packets are usually about 1.5 K in size, so you could use the 1024 byte blocks as best indicator. I've done the speed test with SHA-1, AES-CBC as well as AES-GCM.

So let's use the following values:

SHA-1 (representing HMAC-SHA-1): 1467708 kB/s
AES-CBC                        : 1330523 kB/s
AES-GCM                        : 3346640 k

Instead of GB/s you should really be looking at ns per kB, that way you can add the processing time together and then calculate it back to GB/s as you want.

Now we can calculate the speed of SHA-1 + CBC by performing:

$$T_{SHA-1\&CBC} = {1 \over {1 \over T_{SHA-1}} + {1 \over T_{AES-CBC}}}$$

where $T$ is the transfer speed in bytes per second.

This will result in the following value: 697876kB/s for SHA-1 + AES-CBC. That means that AES-GCM is about 4.8 times faster than SHA-1 + AES-CBC for a normal, unthreaded implementation. This is assuming that HMAC has the same speed of SHA-1 (which is approximately true in all probability, even though it has to process a little more data).

  • $\begingroup$ Thanks alot for your detailed answer. The only thing I don't get is why you chose cbc mode? I chose ctr + hmac sha1 because thats the default for srtp protocol $\endgroup$
    – Soteri
    Feb 11, 2022 at 8:08
  • 1
    $\begingroup$ Ah, sorry, I thought that you'd use TLS, because you were referencing OpenSSL. I don't have much time right now, can you get along with the given answer to calculate the aggregate result? I presume that most protocols will not multi-thread for one specific connection, so it should in that case be a valid way of calculating the speed. $\endgroup$
    – Maarten Bodewes
    Feb 11, 2022 at 9:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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