[adrian_b]

The forms of Keccak that were initially standardized in SHA-3 were secure but significantly slower than possible.

This had the consequence that for many applications where speed is important the existing very efficient implementations of BLAKE2b-512 or of the faster but less secure BLAKE3 have been preferred, or SHA-256 or SHA-512, on the CPUs where these are implemented in hardware.

However, it is also possible to use Keccak in modes of operation where it is as fast or faster than any other comparable hash (e.g. by using parallelizable tree hashing, like the BLAKE derivatives). Previously these modes were less known, because they were not standardized and because the existing reference implementations were less polished than those of the BLAKE derivatives.

After being included in standards like this RFC, it can be hoped that these good secure hashes will become more widely available.

Recent ARM-based CPUs have instructions for the core functions of Keccak, while on AMD/Intel CPUs with SHA-512 Keccak is rather fast even without dedicated instructions. Therefore on such CPUs KangarooTwelve and TurboSHAKE can be very fast right now, when using an appropriate implementation.

For instance I use BLAKE2b-512 for file integrity checking, frequently (i.e. at least a few times per day) running it over hundreds of GB or over many TB of data. Now, when I have an AVX-512 capable CPU, i.e. a Zen 5, I should experiment with implementing an optimized KangarooTwelve, because it should be much faster on such a CPU.

[oconnor663]

If you want to try an optimized AVX-512 implementation of KangarooTwelve on the command line, you can `cargo install k12sum`. On my machine it's neck-and-neck with `b3sum --no-mmap` (which does not use threads).

Edit: Oh it looks like another option, `KeccakSum`, was released a couple months ago? https://github.com/XKCP/K12/commit/5271b58c990c1ac33c1097b4e...

[indolering]

Note that the tweaks to Blake2 and Blake3 weakened the cryptanalysis done for the SHA3 hashing contest such that it is not directly applicable. That doesn't mean they are not well respected and probably fine, it's just that we have less confidence in them than K12 and other sibling Keccak hashes.

I would love to hear how the benchmarking goes!

[adrian_b]

EDIT: Typo

I have noticed too late that I have incorrectly written "AMD/Intel CPUs with SHA-512", but I have meant AMD/Intel CPUs with AVX-512".

(There are a few recent Intel CPUs that have SHA-512, i.e. Lunar Lake and the desktop variant of Arrow Lake, i.e. Arrow Lake S, but this has nothing to do with Keccak.)