Nine Years to Halve a Hash Function: RFC 9861 Is Out - ZK/SEC Quarterly
Back to all posts
Mid-2016, the Keccak team came back with a new algorithm called KangarooTwelve. And you might have guessed, it is to SHA-3 what BLAKE2 is to BLAKE.
— KangarooTwelve (2017)
After nearly a decade in the making, RFC 9861: KangarooTwelve and TurboSHAKE was officially published in October 2025. zkSecurity was among its co-authors, working alongside Benoît Viguier, the Keccak team (Joan Daemen and Gilles Van Assche), and Quynh Dang from NIST. We're glad it's finally out, because the functions it defines deserve to be far more widely used than they are today.
Here's the short version: if you're reaching for SHA-3 or SHAKE, there's now a stable, citable specification for a family of hash functions that do the same job at the same security level, roughly twice as fast .
If you've used BLAKE2, this is the same idea. BLAKE2 took a finalist that the SHA-3 competition had already scrutinized to death, trimmed the round count, and ended up in Argon2, libsodium, and the Noise framework. KangarooTwelve does the same thing to the winner.
Halving the rounds
TurboSHAKE and KangarooTwelve are built on the exact same Keccak-p[1600] permutation as SHA-3 and SHAKE, but with 12 rounds instead of 24 . That's a striking thing to do, and there are few precedents for it. Imagine cutting AES-128 from 10 rounds to 5, or halving the number of steps in SHA-256, or using a 128-bit curve in place of Curve25519. In most designs, that kind of reduction would gut the security margin.
So why is it fine here? Because few primitives have been attacked as much as Keccak. Since its introduction, it has accumulated more third-party cryptanalysis papers than any of its peers, and the results are reassuring: the best known collision attack reaches only 6 rounds .1 Twelve rounds is twice what anyone has managed to break, which is a comfortable margin by any standard. TurboSHAKE128 and TurboSHAKE256 inherit exactly the security claims of SHAKE128 and SHAKE256 (128-bit and 256-bit respectively); they just get there with half the work.
Too much crypto
Jean-Philippe Aumasson has been making the general version of this argument for years. His 2019 paper Too Much Crypto argues that round counts get picked conservatively at design time and then never revisited, no matter what cryptanalysis does or doesn't achieve. He refreshed it just this month, and it goes further than the RFC does: it makes the case for a 10-round SHA-3, which he calls KitTen in a nod to KangarooTwelve, for a 2.4x speed-up.
There's also a longer-standing complaint here, which is that SHA-3 was over-parameterized to begin with. Here's how I put it back in 2017:
This is because SHA-3's parameters are weirdly big. It is hard to know exactly why. The NIST provided some vague explanations. Other reasons might include: [...] Not to be less secure than SHA-2. SHA-2 had 256-bit security against pre-image attacks so SHA-3 had to provide the same [...] To give some credits to the NIST. In view of people's concerns with NIST's ties with the NSA, they could not afford to act lightly around security parameters.
— KangarooTwelve (2017)
The complaint covered both knobs: the capacity, where SHA3-256 spends 512 bits to buy security nobody was asking for,2 and the round count. Both were set so that the standard would look unimpeachable in 2015, not because any attack demanded it. TurboSHAKE and KT fix the rounds the way SHAKE fixed the capacity.
What's actually in the RFC
RFC 9861 defines four functions:
TurboSHAKE128 and TurboSHAKE256 , extendable-output functions (XOFs), meaning you can squeeze out as many output bytes as you want. These are the base primitives: SHAKE with the round count halved.
KT128 and KT256 , the two security levels of KangarooTwelve, which layers a Sakura-compatible tree-hashing mode on top of TurboSHAKE. By splitting the input into chunks that can be hashed independently, KangarooTwelve exploits the parallelism in modern CPUs (SIMD) and hardware to go even faster on longer messages.
A few properties that matter, especially if you work in cryptography-heavy settings like we do:
No length-extension weakness. Unlike SHA-256 and SHA-512, these functions don't need an HMAC wrapper to be used safely as a MAC. The RFC does specify a MAC construction called HopMAC, which hashes the message with a keyless call and only brings in the key at the very end.4 The key therefore flows through a single permutation call regardless of message length.
A low-degree round function. The Keccak round function has algebraic degree 2, which makes masking against side-channel attacks more tractable than with SHA-2.
Customization strings. KT128/KT256 accept a customization string for clean domain separation, similar to the cSHAKE family.
Natural KDF use. With sufficient input min-entropy, these functions work directly as key-derivation functions, handy for turning a Diffie-Hellman or ECDH shared...