Is there any concrete reason to call BLAKE more secure than BLAKE2?

Question

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

Answer 1

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.

Answer 2

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