Live data from Hacker News

RFC 9861: KangarooTwelve and TurboSHAKE

datatracker.ietf.org

11–15 of 15 posts

Re: RFC 9861: KangarooTwelve and TurboSHAKE

#11

These Keccak derived hashes are my personal favorite hashes. The Keccak sponge function is a more advanced mathematical foundation of hashing than what we had before. The individual mixing functions were also carefully chosen to do very different things. My favorite attribute, however, is that all the cryptanalysis done on SHA3 maps directly to Keccak (unlike Blake's follow-ons).

Unfortunately a state of 25 64-bit words isn't likely get CPU intrinsics anytime soon.

Keccak is core to the SHA3 standard. If speed is a concern, there are hand tuned assembly versions and hardware implementations out there.

Re: RFC 9861: KangarooTwelve and TurboSHAKE

#12
post #7

Can anyone share real-world examples of where and why one would use these, please?

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 u…

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

Re: RFC 9861: KangarooTwelve and TurboSHAKE

#13

Can anyone share real-world examples of where and why one would use these, please?

The edit window passed, so let me add: where and why one would use an extensible-output function in particular.

This is useful when you use a secure hash function as a key derivation function for some communication protocol or file or disk encryption method. This is one of the most frequent use cases for a secure hash function.

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.

Re: RFC 9861: KangarooTwelve and TurboSHAKE

#14
post #7

Can anyone share real-world examples of where and why one would use these, please?

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 u…

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!

Re: RFC 9861: KangarooTwelve and TurboSHAKE

#15

Earlier quoted context omitted.

The edit window passed, so let me add: where and why one would use an extensible-output function in particular.

This is useful when you use a secure hash function as a key derivation function for some communication protocol or file or disk encryption method. This is one of the most frequent use cases for a secure hash function. 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, dependin…

Thanks for the information.

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.

Post reply on HN