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?
(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.
