This question already has an answer here:

I read a blog article which discussed SHA-3. I noticed it mention that security was often compromised in the name of speed (not always a bad thing, of course). It gave some examples:

What I'm saying is that although they care deeply about security, they are also looking for compromises to gain speed. This can be seen with the push for 0-RTT in TLS, but I believe we're seeing it here as well with a push for either KangarooTwelve (K12) or BLAKE2 instead of SHA-3/SHAKE and BLAKE (which are more secure versions of K12 and BLAKE2).

This is explicitly claiming that BLAKE is more secure than BLAKE2. I wasn't able to find anyone else claiming that, so I went to read the actual paper to see what changes it made to the original:

  • Fewer constants used. The original argument was that the constants improve diffusion.

  • Fewer rounds used (from 14 to 10 for 256-bit digests and from 16 to 12 for 512-bit digests).

  • Fancy features such as hash trees and personalization values added.

  • Some generic security trade-offs made (in regards to salt and IV processing).

  • Extensive speed and memory optimizations for implementations in software.

The first two points do not increase security at all, and arguably reduce security. Reducing the rounds was done because the best preimage attack was only found against a 2.5 round variant. This improves speed considerably at the expense of security (at least on a theoretical level). The reduced number of round constants reduce diffusion in the name of a lower ROM footprint.

It's possible that the author of the blog post mentioned simply read about it using fewer rounds and claimed the security was meaningfully reduced as a result, or it could be that it may have practical implications. My question is whether or not there is any concrete reason to consider BLAKE2 to be less secure than BLAKE and to use the latter instead for that reason (when speed is not an issue).


marked as duplicate by forest, Community Dec 30 '18 at 11:01

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • $\begingroup$ Everything in my question here was inadvertently answered in another question looking to elaborate on the impact of the removal of constants, which linked to Analysis of BLAKE2, so I'm marking this as duplicate. $\endgroup$ – forest Dec 30 '18 at 11:02

The approach is not so much ‘compromising security in the name of speed’, but rather engineering something the world is confident provides at least a prescribed security level, and then tweaking it to be faster without compromising confidence in that security level.

After years of cryptanalysis during the SHA-3 competition, the best attacks on BLAKE were able to reach only 6 rounds, so 10 rounds as used by BLAKE2 seems more than ample to provide the advertised security level with a hedge against future incremental improvements.

The other changes are obviously irrelevant to security (additional features, faster implementations of the same function), or don't seem to hurt it based on the current understanding of cryptanalysis (changed rotation counts, fewer constants).


I guess that reducing the rounds is indeed the main reason to call it less secure. Generally attacks are over a specific number of rounds. If better attacks are found then the reduction of rounds could mean that Blake2 gets broken while Blake is not.

How secure something is is up for discussion for the simple reason that we cannot predict the future. I guess that the authors were confident enough in the overall structure of Blake to make the changes.

Neither algorithm has been broken so up to now they are right and Blake2 is as secure as Blake. The full rounds version of neither is affected by the attacks.

However as an attack is more likely to affect Blake2 you can still argue that Blake2 is less secure if an uncertain future is taken into account. With so few rounds broken you can argue that the difference is minimal (AES has many more broken rounds) but it's there.

  • 1
    $\begingroup$ AES has many more broken rounds Each of BLAKE's rounds are similar to two ChaCha rounds, so you can't really compare its rounds with AES. 6 broken rounds in BLAKE implies 12 half-rounds ("real" rounds) being broken, which is more than AES. Though naturally you can't directly compare a hash and a cipher... $\endgroup$ – forest Dec 27 '18 at 3:19
  • $\begingroup$ Yeah, it is hard to compare these two, but this is trying to find some kind of hand-hold. Any comparison implies simplification and is therefore dangerous. I was mainly using that comparison that a break of a minimum number amounts is no indication whatsoever that the full round scheme is broken. If that was the case we would have to do away with rounds altogether :) $\endgroup$ – Maarten Bodewes Dec 27 '18 at 12:06

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