TurboSHAKE and KangarooTwelve were published in RFC 9861 about two months ago. Now, we are coming back to this topic to try to address the following question: If RFC 9861 is the answer, what is the question? — In a nutshell, TurboSHAKE and KangarooTwelve show Keccak's full potential by providing a better security/performance trade-off than the original SHAKE and SHA-3 functions. RFC 9861 leverages the strong third-party cryptanalysis that Keccak has acquired over the years, with a very limited impact on the implementations. No tweaks, no funnny business, just faster!

Keccak was designed in 2008 and submitted to the SHA-3 competition to provide an alternative in case SHA-2 (i.e., SHA-256 and SHA-512) would be broken; SHA-1 was broken already and SHA-2 is similar to it. Hence, the community strongly focused on the safety margin of the candidate algorithms. At that time, we already felt that 24 rounds were too much for Keccak, but at the same time we wanted to make our candidate stand any foreseeable cryptanalytic attack and firmly play its role as a safe alternative that the SHA-3 competition demanded.

Obviously, a disadvantage of having such a thick safety margin is its impact on performance. In particular, a recurring complain we see is that SHA-3 is slower than SHA-2 in software. The reality is more nuanced, e.g., the SHAKE's are better performers than SHA-3, but clearly Keccak's potential is underused there.

Nowadays, Keccak stands strong security-wise, with an impressive track record of third-party cryptanalysis. In fact, using the number of published scientific papers on cryptanalysis as a metric, Keccak scores better than SHA-256, SHA-512 or any unbroken hash function so far. Reducing the number of rounds from 24 rounds down to 12 rounds is a decision that can be done clearly and transparently in the light of all these results.

If the goal is to have an extendable output function (XOF) or a hash function that is faster than SHAKE or SHA-3, why not change Keccak or just switch to SHA-2 or to some other proposal? That is possible, of course, but RFC 9861 provides a better deal. Tweaking Keccak's round function would mean invalidating all the existing cryptanalysis, and would likely frustrate crypanalysts who would then have to redo their analysis… or just move to another topic instead. Cryptanalysis is a scarce resource. Pruposedly, the change between SHAKE and TurboSHAKE is limited to the number of rounds: Since all the cryptanalysis is done on round-reduced versions, any cryptanalysis on one remains valid on the other!

TurboSHAKE retains the flexibility and convenience of sponge functions, including the ability to make authenticated encryption schemes for instance. KangarooTwelve adds a layer of parallelism to make it blazing fast when using SIMD instructions. Their round function allows super-efficient hardware implementations, as well as masked implementations against side-channel attacks.

If TurboSHAKE and KangarooTwelve nicely combine all these advantages, why not make them available in an RFC?