Score:1

Performance of AES CTR + HMAC SHA1

cn flag

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

kelalaka avatar
in flag
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?](https://stackoverflow.com/q/17410270/1820553) from [so]. This is mostly off-topic.
Maarten Bodewes avatar
in flag
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).
kelalaka avatar
in flag
I’m voting to close this question because this is about interpreting the result of a cryptographic library. There is already [HMAC speed](https://stackoverflow.com/q/58719049/1820553) on [so] already.
Score:0
in flag

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).

Soteri avatar
cn flag
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
Maarten Bodewes avatar
in flag
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.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.