What advantages does Keccak/SHA-3 have over BLAKE2?

Question

Keccak/SHA-3 is new NIST standard for cryptographic hash functions. However, it is much slower than BLAKE2 in software implementations. Does Keccak have compensating advantages?

Answer 1

(Disclosure: I'm one of the authors of BLAKE2, but not BLAKE.)

Here are the slides from a presentation I gave at Applied Cryptography and Network Security 2013 about this. (Note: the performance numbers in those slides are obsolete — BLAKE2 is even faster now than it was then.)

The slides include quotes from NIST's 3rd-round Report on the SHA-3 Competition which show some of the advantages and disadvantages of BLAKE (not BLAKE2) compared to Keccak, in NIST's opinion.

Here's a blog post I wrote to accompany the slides.

The main reason that NIST gave was that BLAKE was more similar to SHA-2 than Keccak was. When the SHA-3 contest was designed, the whole point of it was to provide a new hash function that would be ready in case SHA-2 got broken, so it made sense to require the winner to be different from SHA-2. However now, with almost a decade more of research and SHA-2 looking no weaker, a hash function being similar to SHA-2 doesn't seem bad, and might even be good.

There was another reason that NIST gave that I omitted from the slides, which was that Keccak is more efficient in ASIC implementation.

That reason may be more important if you are a large organization, like the U.S. military or U.S. government, who is going have special hardware built for your project, but more flexible/general-purpose performance is more important to me. (See Adam Langley's blog post on this topic.)

Besides, everything is fast in hardware! See this catalog of hardware implementations of secure hash functions. ASIC implementations of BLAKE can process about 12.5 GB/s, compared to Keccak, which can process about 44 GB/s. An ASIC implementation of BLAKE2 would be probably about 40% faster than a similar implementation of BLAKE, i.e. around 17.5 GB/s.

But even 12.5 GB/s seems more than sufficient for most uses of a secure hash function.

Answer 2

Blake-2 was not part of the SHA-3 competition, Blake, its predecessor was. Blake-2 is approx 1.3 to 1.7 times faster than Blake in software, with the advantage best for the 512-bit digests.

Performance

A software performance comparison between the two SHA-3 finalists shows that Blake is about 3 times faster than Keccak on a modern CPU for a 512-bit hash, and only 1.26 times faster for a 256-bit hash. Performance listed in cycles per byte.

  Algorithm        512-bit        256-bit
  ---------------------------------------
  Blake            5.18 cpb       6.79 cpb
  Keccak           15.99 cpb      8.56 cpb

Hardware designs however show a substantial win for Keccak. Performance listed in gigabits per second on an ASIC with identical power draw, but different frequencies and transistor counts.

  Algorithm        256-bit
  ---------------------------
  Blake            2.06 Gbps
  Keccak           10.28 Gbps

Here Keccak is 5 times faster at the same power budget. On FPGA platforms, Keccak offers a similar advantage of at least 4X the performance with only 10% more power budget, and the same circuit count or less than Blake.

As part of the standardization process, implementing the Keccak core permutation in future commodity processors such as ARM, Intel, and AMD was discussed. This would use up to 25 128-bit registers to hold the state and all round constants, processing rounds individually, or 13 128-bit registers to hold just the state, and processing a group of rounds, with the round constants generated on the fly. There could also be a special 1600-bit register just for the Keccak state.

This would give Keccak a similar performance advantage as AES was given with appropriate CPU instructions, and could make it faster than Blake-2, almost certainly so for a 256-bit hash, where the performance is already quite close.

Security

Keccak has a round count that is high enough to give it a massive security margin, and the sponge construction it uses gives very good security proofs, which have only been proven better with time.

Blake also has a high security margin, which allowed Blake-2 to have a lower round count and still retain the expected security from a hash function of a given size. The construction used by Blake was also changed for Blake-2, in order to simplify padding and memory access in software platforms, but also locked it to byte processing only. Blake and Keccak can process bitstreams.

The round constants in Keccak are probably its weakest point, due to the low hamming weights and structural similarity. Blake-2 has less constants than Blake as well. This may make some attacks have lower complexity, however the attack complexities were already higher than the expected security of the hash functions. There have been no attacks on either hash function that even come close to breaking them. The only practical attacks on Keccak work on reduced round variants with less than 10 rounds, and on Blake with less than 7 rounds.

Blake-2b is a superior choice for password based key derivation functions, because of the low attacker advantage at a high budget, which is much greater with Keccak.

Other

As part of the standardization process, the flexible sponge construction of Keccak resulted in the SHAKE XOFs which can generate arbitrary length bitstreams for various applications. There was also talk of authenticated encryption based on the Keccak permutation, Keyak is a 2nd round CAESAR candidate based on the Keccak permutation used in SHA-3.

Blake and derivatives are not nearly as flexible, NORX is as close Blake as anything, but they are still not really similar as a package, and the core functions are different.