RFC 9861: KangarooTwelve and TurboSHAKE
- B. Viguier,
- D. Wong, Ed.,
- G. Van Assche, Ed.,
- Q. Dang, Ed.,
- J. Daemen, Ed.
Abstract
This document defines four e
All four functions provide efficient and secure hashing primitives, and the last two are able to exploit the parallelism of the implementation in a scalable way.¶
This document is a product of the Crypto Forum Research Group. It builds up on the definitions of the permutations and of the sponge construction in NIST FIPS 202 and is meant to serve as a stable reference and an implementation guide.¶
Status of This Memo
This document is not an Internet Standards Track specification; it is published for informational purposes.¶
This document is a product of the Internet Research Task Force
(IRTF). The IRTF publishes the results of Internet
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
https://
Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://
1. Introduction
This document defines the TurboSHAKE128, TurboSHAKE256 [TURBOSHAKE],
KT128, and KT256 [KT] e
TurboSHAKE is a sponge function family that makes use of Keccak
KangarooTwelve applies tree hashing on top of TurboSHAKE and comprises two functions, KT128 and KT256. Note that [KT] only defined KT128 under the name KangarooTwelve. KT256 is defined in this document.¶
The SHA-3 and SHAKE functions process data in a serial manner and are strongly limited in exploiting available parallelism in modern CPU architectures. Similar to ParallelHash [SP800-185], KangarooTwelve splits the input message into fragments. It then applies TurboSHAKE on each of them separately before applying TurboSHAKE again on the combination of the first fragment and the digests. More precisely, KT128 uses TurboSHAKE128 and KT256 uses TurboSHAKE256. They make use of Sakura coding for ensuring soundness of the tree hashing mode [SAKURA]. The use of TurboSHAKE in KangarooTwelve makes it faster than ParallelHash.¶
The security of TurboSHAKE128, TurboSHAKE256, KT128, and KT256 builds on the public
scrutiny that Keccak has received since its
publication [KECCAK
With respect to functions defined in [FIPS202] and [SP800-185], TurboSHAKE128, TurboSHAKE256, KT128, and KT256 feature the following advantages:¶
With respect to SHA-256, SHA-512, and other functions defined in [FIPS180], TurboSHAKE128, TurboSHAKE256, KT128, and KT256 feature the following advantages:¶
This document represents the consensus of the Crypto Forum Research Group (CFRG) in the IRTF. It has been reviewed by two members of the Crypto Review Panel, as well as by several members of the CFRG. It is not an IETF product and is not a standard.¶
1.1. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
The following notations are used throughout the document:¶
In the following, x and y are byte strings of equal length:¶
In the following, x and y are integers:¶
2. TurboSHAKE
2.1. Interface
TurboSHAKE is a family of e
A TurboSHAKE instance takes a byte string M, an OPTIONAL byte D, and a positive integer L as input parameters, where:¶
Conceptually, an XOF can be viewed as a hash function with an infinitely long output truncated to L bytes. This means that calling an XOF with the same input parameters but two different lengths yields outputs such that the shorter one is a prefix of the longer one. Specifically, if L1 < L2, then TurboSHAKE(M, D, L1) is the same as the first L1 bytes of TurboSHAKE(M, D, L2).¶
By default, the domain separation byte is `1F`. For an API that does not support a domain separation byte, D MUST be the `1F`.¶
The TurboSHAKE instance produces output that is a hash of the (M, D) couple. If D is fixed, this becomes a hash of the message M. However, a protocol that requires a number of independent hash functions can choose different values for D to implement these. Specifically, for distinct values D1 and D2, TurboSHAKE(M, D1, L1) and TurboSHAKE(M, D2, L2) yield independent hashes of M.¶
Note that an implementation MAY propose an incremental input interface where the input string M is given in pieces. If so, the output MUST be the same as if the function was called with M equal to the concatenation of the different pieces in the order they were given. Independently, an implementation MAY propose an incremental output interface where the output string is requested in pieces of given lengths. When the output is formed by concatenating the pieces in the requested order, it MUST be the same as if the function was called with L equal to the sum of the given lengths.¶
2.2. Specifications
TurboSHAKE makes use of the permutation Keccak
Similarly to SHAKE128, TurboSHAKE128 is a sponge function calling this permutation KP with a rate of 168 bytes or 1344 bits. It follows that TurboSHAKE128 has a capacity of 1600 - 1344 = 256 bits or 32 bytes. Respectively to SHAKE256, TurboSHAKE256 makes use of a rate of 136 bytes or 1088 bits and has a capacity of 512 bits or 64 bytes.¶
We now describe the operations inside TurboSHAKE128.¶
TurboSHAKE256 performs the same steps but makes use of 136-byte blocks with respect to the padding, absorbing, and squeezing phases.¶
The definition of the TurboSHAKE functions equivalently implements the pad10*1 rule; see Section 5.1 of [FIPS202] for a definition of pad10*1. While M can be empty, the D byte is always present and is in the `01`-`7F` range. This last byte serves as domain separation and integrates the first bit of padding of the pad10*1 rule (hence, it cannot be `00`). Additionally, it must leave room for the second bit of padding (hence, it cannot have the most significant bit (MSB) set to 1), should it be the last byte of the block. For more details, refer to Section 6.1 of [KT] and Section 3 of [TURBOSHAKE].¶
The pseudocode versions of TurboSHAKE128 and TurboSHAKE256 are provided in Appendices A.2 and A.3, respectively.¶
3. KangarooTwelve: Tree Hashing over TurboSHAKE
3.1. Interface
KangarooTwelve is a family of e
The customization string MAY serve as domain separation. It is typically a short string such as a name or an identifier (e.g., URI, Object Identifier (OID), etc.). It can serve the same purpose as TurboSHAKE's D input parameter (see Section 2.1) but with a larger range.¶
By default, the customization string is the empty string. For an API that does not support a customization string parameter, C MUST be the empty string.¶
Note that an implementation MAY propose an interface with the input and/or output provided incrementally, as specified in Section 2.1.¶
3.2. Specification of KT128
On top of the sponge function TurboSHAKE128, KT128 uses a
Sakura
Then, split S into n chunks of 8192 bytes.¶
From S_1 .. S_(n-1), compute the 32-byte chaining values CV_1 .. CV_(n-1). In order to be optimally efficient, this computation MAY exploit the parallelism available on the platform, such as single instruction, multiple data (SIMD) instructions.¶
Compute the final node: FinalNode.¶
Finally, the KT128 output is retrieved:¶
The following figure illustrates the computation flow of KT128 for |S| <= 8192 bytes:¶
The following figure illustrates the computation flow of KT128 for |S| > 8192 bytes and where TurboSHAKE128 and length_encode( x ) are abbreviated as TSHK128 and l_e( x ), respectively:¶
A pseudocode version is provided in Appendix A.4.¶
The table below gathers the values of the domain separation bytes used by the tree hash mode:¶
3.3. length_encode( x )
The function length_encode takes as inputs a non-negative integer x < 256**255 and outputs a string of bytes x_(n-1) || .. || x_0 || n where¶
and where n is the smallest non-negative integer such that x < 256**n. n is also the length of x_(n-1) || .. || x_0.¶
For example, length
A pseudocode version is as follows, where { b } denotes the byte of numerical value b.¶
3.4. Specification of KT256
KT256 is specified exactly like KT128, with two differences:¶
A pseudocode version is provided in Appendix A.5.¶
4. Message Authentication Codes
Implementing a Message Authentication Code (MAC) with KT128 or KT256 MAY use a hash-then-MAC construction. This document defines and recommends a method called HopMAC:¶
Similarly to Hashed Message Authentication Code (HMAC), HopMAC consists of two calls: an inner call compressing the message M and the optional customization string C to a digest and an outer call computing the tag from the key and the digest.¶
Unlike HMAC, the inner call to KangarooTwelve in HopMAC is keyless and does not require additional protection against side channel attacks (SCAs). Consequently, in an implementation that has to protect the HopMAC key against an SCA, only the outer call needs protection, and this amounts to a single execution of the underlying permutation (assuming the key length is at most 69 bytes).¶
In any case, TurboSHAKE128, TurboSHAKE256, KT128, and KT256 MAY be used to compute a MAC with the key reversibly prepended or appended to the input. For instance, one MAY compute a MAC on short messages simply calling KT128 with the key as the customization string, i.e., MAC = KT128(M, Key, L).¶
5. Test Vectors
Test vectors are based on the repetition of the pattern `00 01 02 .. F9 FA` with a specific length. ptn(n) defines a string by repeating the pattern `00 01 02 .. F9 FA` as many times as necessary and truncated to n bytes, for example:¶
6. IANA Considerations
In the "Named Information Hash Algorithm Registry", k12-256 refers to the hash function obtained by evaluating KT128 on the input message with default C (the empty string) and L = 32 bytes (256 bits). Similarly, k12-512 refers to the hash function obtained by evaluating KT256 on the input message with default C (the empty string) and L = 64 bytes (512 bits).¶
In the "COSE Algorithms" registry, IANA has added the following entries for TurboSHAKE and KangarooTwelve:¶
7. Security Considerations
This document is meant to serve as a stable reference and an
implementation guide for the KangarooTwelve and TurboSHAKE e
To be more precise, KT128 is made of two layers:¶
This reasoning is detailed and formalized in [KT].¶
KT256 is structured as KT128, except that it uses TurboSHAKE256 as the inner function. The TurboSHAKE256 function is exactly Keccak[r=1088, c=512] (as in SHAKE256) reduced to 12 rounds, and the same reasoning on cryptanalysis applies.¶
TurboSHAKE128 and KT128 aim at 128-bit security. To achieve 128-bit security strength, L, the chosen output length, MUST be large enough so that there are no generic attacks that violate 128-bit security. So for 128-bit (second) preimage security, the output should be at least 128 bits; for 128 bits of security against multi-target preimage attacks with T targets, the output should be at least 128+log_2(T) bits; and for 128-bit collision security, the output should be at least 256 bits. Furthermore, when the output length is at least 256 bits, TurboSHAKE128 and KT128 achieve NIST's post-quantum security level 2 [NISTPQ].¶
Similarly, TurboSHAKE256 and KT256 aim at 256-bit security. To achieve 256-bit security strength, L, the chosen output length, MUST be large enough so that there are no generic attacks that violate 256-bit security. So for 256-bit (second) preimage security, the output should be at least 256 bits; for 256 bits of security against multi-target preimage attacks with T targets, the output should be at least 256+log_2(T) bits; and for 256-bit collision security, the output should be at least 512 bits. Furthermore, when the output length is at least 512 bits, TurboSHAKE256 and KT256 achieve NIST's post-quantum security level 5 [NISTPQ].¶
Unlike the SHA-256 and SHA-512 functions, TurboSHAKE128, TurboSHAKE256, KT128, and KT256 do not suffer from the length extension weakness and therefore do not require the use of the HMAC construction, for instance, when used for MAC computation [FIPS198]. Also, they can naturally be used as a key derivation function. The input must be an injective encoding of secret and diversification material, and the output can be taken as the derived key(s). The input does not need to be uniformly distributed, e.g., it can be a shared secret produced by the Diffie-Hellman or Elliptic Curve Diffie-Hellman (ECDH) protocol, but it needs to have sufficient min-entropy.¶
Lastly, as KT128 and KT256 use TurboSHAKE with three values for D, namely 0x06, 0x07, and 0x0B, protocols that use both KT128 and TurboSHAKE128 or both KT256 and TurboSHAKE256 SHOULD avoid using these three values for D.¶
8. References
8.1. Normative References
- [FIPS202]
-
NIST, "SHA-3 Standard: Permutation
-Based Hash and Extendable , NIST FIPS 202, DOI 10-Output Functions" .6028 , , <https:///NIST .FIPS .202 nvlpubs >..nist .gov /nistpubs /FIPS /NIST .FIPS .202 .pdf - [RFC2119]
-
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10
.17487 , , <https:///RFC2119 www >..rfc -editor .org /info /rfc2119 - [RFC8174]
-
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10
.17487 , , <https:///RFC8174 www >..rfc -editor .org /info /rfc8174 - [SP800-185]
-
Kelsey, J., Chang, S., and R. Perlner, "SHA-3 Derived Functions: cSHAKE, KMAC, TupleHash and ParallelHash", National Institute of Standards and Technology, NIST SP 800-185, DOI 10
.6028 , , <https:///NIST .SP .800 -185 doi >..org /10 .6028 /NIST .SP .800 -185
8.2. Informative References
- [FIPS180]
-
NIST, "Secure Hash Standard", NIST FIPS 180-4, DOI 10
.6028 , , <https:///NIST .FIPS .180 -4 nvlpubs >..nist .gov /nistpubs /FIPS /NIST .FIPS .180 -4 .pdf - [FIPS198]
-
NIST, "The Keyed-Hash Message Authentication Code (HMAC)", NIST FIPS 198-1, DOI 10
.6028 , , <https:///NIST .FIPS .198 -1 nvlpubs >..nist .gov /nistpubs /FIPS /NIST .FIPS .198 -1 .pdf - [KECCAK
_CRYPTANALYSIS] -
Keccak Team, "Summary of Third-party cryptanalysis of Keccak", <https://
www >..keccak .team /third _party .html - [KT]
-
Bertoni, G., Daemen, J., Peeters, M., Van Assche, G., Van Keer, R., and B. Viguier, "KangarooTwelve: Fast Hashing Based on Keccak-p", Applied Cryptography and Network Security (ACNS 2018), Lecture Notes in Computer Science, vol. 10892, pp. 400-418, DOI 10
.1007 , , <https:///978 -3 -319 -93387 -0 _21 link >..springer .com /chapter /10 .1007 /978 -3 -319 -93387 -0 _21 - [NISTPQ]
-
NIST, "Submission Requirements and Evaluation Criteria for the Post-Quantum Cryptography Standardization Process", <https://
csrc >..nist .gov /CSRC /media /Projects /Post -Quantum -Cryptography /documents /call -for -proposals -final -dec -2016 .pdf - [SAKURA]
-
Bertoni, G., Daemen, J., Peeters, M., and G. Van Assche, "Sakura: a Flexible Coding for Tree Hashing", Applied Cryptography and Network Security (ACNS 2014), Lecture Notes in Computer Science, vol. 8479, pp. 217-234, DOI 10
.1007 , , <https:///978 -3 -319 -07536 -5 _14 link >..springer .com /chapter /10 .1007 /978 -3 -319 -07536 -5 _14 - [TURBOSHAKE]
-
Bertoni, G., Daemen, J., Hoffert, S., Peeters, M., Van Assche, G., Van Keer, R., and B. Viguier, "TurboSHAKE", Cryptology ePrint Archive, Paper 2023/342, , <http://
eprint >..iacr .org /2023 /342 - [XKCP]
-
"eXtended Keccak Code Package", commit 64404bee, , <https://
github >..com /XKCP /XKCP
Appendix A. Pseudocode
The subsections of this appendix contain pseudocode definitions of TurboSHAKE128, TurboSHAKE256, and KangarooTwelve. Standalone Python versions are also available in the Keccak Code Package [XKCP] and in [KT]¶
A.1. Keccak-p[1600,n_r=12]
where ROL64(x, y) is a rotation of the 'x' 64-bit word toward the bits with higher indexes by 'y' positions. The 8-bytes byte string x is interpreted as a 64-bit word in little-endian format.¶