Is authentication more computationally expensive than encryption?

Question

newbie in crypto here. I've a application that needs integrity protection. Confidentiality would be nice but has less priority over performance throughput. So I test "openssl speed" on my laptop, and find out sha256 is actually slower than chacha20. About the same speed as chacha20+poly1305. I assume this sha256 is about the same speed as HMAC(sha256), is that correct? Also in openssl, chacha20+poly1305 is faster than blake2b512.

Is it the general case that integrity protection is much more computationally expensive than encryption? By using aead algorithms I get confidentiality for free?

Answer 1

SHA-256 is designed to be collision-resistant, which is much costlier than pseudorandomness or unforgeability. It should come as no surprise that it is slower. The difference between SHA-256 and HMAC-SHA256 for bulk data is negligible: a call to HMAC-SHA256 on a long input costs the same as one call to SHA-256 on a long input plus one call to SHA-256 on a short input. The same goes for SHA-512, BLAKE2, SHA-3, etc. You can use HMAC-SHA256 as a MAC for unforgeability, but you're paying a huge tax for unnecessary collision resistance.

In contrast, polynomial evaluation message authentication codes such as Poly1305 are some of the fastest crypto primitives available. These are essentially chains of 128-bit additions and multiplications, with considerable flexibility in the order of operations to maximize vector unit utilization by virtue of working in a convenient prime field. For MACs, collision resistance is not relevant. Of course, you can't use Poly1305 for applications where collision resistance is necessary.

In chacha20+poly1305, the Poly1305 computation is easily the fastest part. The speed of Poly1305 is a large part of why chacha20+poly1305 is much generally faster than, e.g., AES-CBC with HMAC-SHA256. Another part is that software AES is slow, and software AES without timing side channels is horrifically slow—and worse for AES-CBC, which must work on arbitrary inputs, than for AES-CTR with highly structured inputs.

Similarly, for AES-GCM, there is a catch that most CPUs don't easily support fast binary field multiplication in software, whereas most CPUs do easily support fast prime field multiplication in software, so AES-GCM is also much slower than chacha20+poly1305 without dedicated hardware support—and horrifyingly slow without timing side channels.

As for whether AEAD gives you confidentiality: Yes, AEAD means authenticated encryption with associated data. If you skip the authenticated part, then often you don't get confidentiality in the scenario of active attacks. You should generally always use authenticated encryption; forget about unauthenticated encryption schemes as anything more than an implementation detail for authenticated encryption.