1
$\begingroup$

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?

Improve this question
$\endgroup$
5
  • $\begingroup$ One thing you could do is use SHA512(and truncate output if needed), if you are on a 64bit processor as this should be faster. See this question. On HMAC specifically, it hashes data twice, so that is something you could take into consideration. I'm not sure what other solutions are faster. $\endgroup$
    – user58235
    Apr 21, 2018 at 23:42
  • $\begingroup$ @brycx SHA512 is indeed faster on intel platform, but 3 times slower on my android phone, which is qualcomm snapdragon 821 64bit. It must be very arch specific. $\endgroup$
    – ccaapton
    Apr 22, 2018 at 0:27
  • $\begingroup$ As an aside: when comparing the speed of a hash like SHA256 to the speed of a stream cipher like ChaCha20, you’re comparing apples with bananas… and when you add authentication (eg Poly1305) into the mix, you’re actually adding pineapple to your fruit bowl (which makes you end up comparing the speed of Blake2b512 with ChaCha20+Poly1305). Each of those things are build for individual cryptographic purposes! Meaning, each of them resides in a different realm of cryptography. Comparing the speeds of such different solutions to completely different cryptographic problems doesn’t really make sense. $\endgroup$
    – e-sushi
    Apr 22, 2018 at 10:31
  • $\begingroup$ @e-sushi Thanks for the clarification. What I need is message authentication, as fast as possible, which way should I take then? $\endgroup$
    – ccaapton
    Apr 22, 2018 at 12:17
  • $\begingroup$ If your goal is to have encryption-with-authentication then ChaCha20+Poly1305 is a valid choice from both a speed as well as security perspective (while looking at potential resource limits you might be facing with your device). If you only need authentication, I’ld point you to Poly1305 too (in your case). You can very well use Poly1305 apart from the ChaCha20+Poly1305 combination. Related to this, you might want to take a look at the Fast Poly1305 implementation in C on github.com. Hope that helps… $\endgroup$
    – e-sushi
    Apr 22, 2018 at 12:35

1 Answer 1

Reset to default
1
$\begingroup$

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.

Improve this answer
$\endgroup$
4
  • $\begingroup$ Authentication is what I wanted, not encryption. Is it possible to use poly1305 without chacha20? $\endgroup$
    – ccaapton
    Apr 22, 2018 at 5:00
  • $\begingroup$ @ccaapton Yes, but only for a single message under each key. If you want to use the same key for multiple messages, you need to use a pseudorandom function, such as ChaCha20, to derive an effectively independent key for each use of Poly1305. However, you only need to generate a short 256-bit output with the PRF; you don't need to process a long message like with, say HMAC-SHA256, or generate a long pad like ChaCha20 as a stream cipher. There are some finicky details. Please pose this as another question with details about your application and threat model and what you hope to achieve. $\endgroup$
    – Squeamish Ossifrage
    Apr 22, 2018 at 13:57
  • $\begingroup$ I just went through the RFC about chacha20+poly1305, very easy to understand and quite clean. Now I know what you mean by poly1305 only with chacha20 induced key sequence. Will try some coding with python libsodium to see how that performs. Thanks a lot! $\endgroup$
    – ccaapton
    Apr 23, 2018 at 3:49
  • $\begingroup$ Of course, you can't use Poly1305 for applications where collision resistance is necessary. That sounds wrong, because collision resistance is also necessary in protocols such as TLS, otherwise an attacker could forge messages with MACs that collide. It's almost like saying that ChaCha20-HMAC256 is somehow superior to ChaCha20-Poly1305? Apart from the difference in hash output size that is. $\endgroup$
    – Joran Greef
    Jun 29, 2020 at 10:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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