Rfc 9861: Kangarootwelve and Turboshake
Posted3 months agoActive2 months ago
datatracker.ietf.orgTechstory
calmneutral
Debate
40/100
CryptographyHash FunctionsRfc
Key topics
Cryptography
Hash Functions
Rfc
The IETF has published RFC 9861, introducing KangarooTwelve and TurboSHAKE, new cryptographic hash functions, sparking discussion among HN users about their security, performance, and potential applications.
Snapshot generated from the HN discussion
Discussion Activity
Moderate engagementFirst comment
8d
Peak period
7
Day 9
Avg / period
4.7
Comment distribution14 data points
Loading chart...
Based on 14 loaded comments
Key moments
- 01Story posted
Oct 15, 2025 at 10:44 PM EDT
3 months ago
Step 01 - 02First comment
Oct 23, 2025 at 6:54 PM EDT
8d after posting
Step 02 - 03Peak activity
7 comments in Day 9
Hottest window of the conversation
Step 03 - 04Latest activity
Oct 25, 2025 at 7:47 PM EDT
2 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45600897Type: storyLast synced: 11/20/2025, 2:09:11 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
There is no difficulty in defining AVX-512 instructions that would operate on a hash state of this size.
The real amount of 64-bit registers in a modern CPU is well above one thousand and the implementation of the SHA-3 functions is very efficient in hardware, so adding instructions for these hashes would have a very modest cost.
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.
Edit: Oh it looks like another option, `KeccakSum`, was released a couple months ago? https://github.com/XKCP/K12/commit/5271b58c990c1ac33c1097b4e...
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.)
I would love to hear how the benchmarking goes!
In such cases, you hash some random value or a salted password or a shared secret value obtained by some kind of Diffie-Hellman exchange, and you must generate a variable number of secret keys, depending on the target protocol. You typically need to generate at least an encryption key and an authentication key, but frequently you need to generate even more keys, e.g. in a communication protocol you may use different keys for the 2 directions of communication, or you may change the keys after a certain amount of time or of transmitted data.
When you have just a hash function with fixed output size, e.g. SHA-512, you must transform it in a hash function with extensible output size, to get all the keys that you need.
Typically this is done by hashing repeatedly the secret value, but each time concatenated with some distinct data, e.g. the value of a counter. Like for any cryptographic operation, every detail of the implementation matters and it is easy to make mistakes.
If you already have available a hash function that has been designed to provide extensible output, then you can use it as it is and you do not have to bother with designing an ad-hoc method for extending the size of its output and with the analysis of its correctness.
This sounds like something I would use HKDF for. But, to your point, it's nice to be able to build the design with a fewer number of primitives, and likely more performant, too.