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.¹ 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.

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,² 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.⁴ 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 secret into keys.

Blazing fast

Halving the rounds roughly doubles throughput for TurboSHAKE over SHAKE. KangarooTwelve then adds parallelism on top, which widens the gap further on long messages. The Keccak team's benchmarks are worth a look: on an Intel SkylakeX, KT128 hashes at 6.29 GB/s while SHA-256 does 0.51 GB/s. On an Apple M1, where SHA-256 has a dedicated hardware instruction and is genuinely fast at 2.43 GB/s, KT128 still nearly doubles it at 4.25 GB/s.

Two caveats though:

1. The parallelism speedup is workload-dependent. For short messages, KangarooTwelve falls back to a single TurboSHAKE call. That's still faster than SHAKE, but you won't see the tree-hashing gains, which only kick in on larger inputs and only when the implementation actually uses SIMD. If throughput on big messages is your bottleneck, this is a big win; if you're hashing tiny values, the win is the round reduction alone. The benchmarks show the effect: on the Cortex-A72, KT128 (0.367 GB/s) actually lands a hair below plain TurboSHAKE128 (0.373 GB/s).

2. This is an IRTF/CFRG Informational RFC, not a NIST FIPS standard. For most applications that distinction doesn't matter: the specification is stable, peer-reviewed, and comes from the people who designed Keccak itself. But if you operate under FIPS compliance requirements, SHA-3/SHAKE remain the approved choices, and you can't swap in KT128 to satisfy a certification.

Cheap to compute, cheap to prove

The round count shows up in a second place, one we spend a lot of time in: proof systems. Hashing is often one of the heaviest workloads in a deployed SNARK, from Merkle openings to hash-based signature aggregation. Recent work has made that a lot cheaper. Flock proves 30k Keccak permutations per second on a single core of an M4 Max, within 250x of native execution.³ Since circuits unroll the rounds, the cost is close to linear in the round count, so 12 rounds instead of 24 is quite literally half the constraints. The case for TurboSHAKE in circuits becomes even stronger.

There's a security argument here too. The usual way to make hashing cheap in a circuit is to pick an arithmetization-oriented design like Poseidon, built out of low-degree power maps over a large prime field. They solve a real problem, but their algebraic structure gives cryptanalysts a lot to pull on, and new attacks keep showing up. Keccak has been hammered on since 2008 and ships in everything. If the proving side can close the performance gap, the standard hash is the easier one to defend.

Why this took nine years

We first proposed KangarooTwelve in 2016, brought it to the CFRG as a draft in 2017, gave TurboSHAKE its own name and identity in 2023 once we realized the underlying sponge function was interesting in its own right, then instantiated the two security levels KT128 and KT256. Publication finally landed in October 2025.

Standards move slowly, and that's mostly a feature. A hash function you're going to build systems on should be scrutinized for years before it gets a stable reference number and an IANA registration. Now it has both: a DOI, COSE algorithm identifiers, and a frozen specification you can cite and implement against.

If you're building something that hashes a lot of data and you have the flexibility to choose your primitive, take a serious look at TurboSHAKE and KangarooTwelve. And if you're shipping an implementation of them and want a second set of eyes, you know where to find us.

Thanks to the co-authors and the CFRG reviewers who carried this across the line.