rfc9861.original   rfc9861.txt 
Crypto Forum B. Viguier Internet Research Task Force (IRTF) B. Viguier
Internet-Draft ABN AMRO Bank Request for Comments: 9861 ABN AMRO Bank
Intended status: Informational D. Wong, Ed. Category: Informational D. Wong, Ed.
Expires: 25 August 2025 zkSecurity ISSN: 2070-1721 zkSecurity
G. Van Assche, Ed. G. Van Assche, Ed.
STMicroelectronics STMicroelectronics
Q. Dang, Ed. Q. Dang, Ed.
NIST NIST
J. Daemen, Ed. J. Daemen, Ed.
Radboud University Radboud University
21 February 2025 October 2025
KangarooTwelve and TurboSHAKE KangarooTwelve and TurboSHAKE
draft-irtf-cfrg-kangarootwelve-17
Abstract Abstract
This document defines four eXtendable Output Functions (XOF), hash This document defines four eXtendable-Output Functions (XOFs), hash
functions with output of arbitrary length, named TurboSHAKE128, functions with output of arbitrary length, named TurboSHAKE128,
TurboSHAKE256, KT128 and KT256. TurboSHAKE256, KT128, and KT256.
All four functions provide efficient and secure hashing primitives, All four functions provide efficient and secure hashing primitives,
and the last two are able to exploit the parallelism of the and the last two are able to exploit the parallelism of the
implementation in a scalable way. implementation in a scalable way.
This document is a product of the Crypto Forum Research Group. It This document is a product of the Crypto Forum Research Group. It
builds up on the definitions of the permutations and of the sponge builds up on the definitions of the permutations and of the sponge
construction in [FIPS 202], and is meant to serve as a stable construction in NIST FIPS 202 and is meant to serve as a stable
reference and an implementation guide. reference and an implementation guide.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Research Task Force
and may be updated, replaced, or obsoleted by other documents at any (IRTF). The IRTF publishes the results of Internet-related research
time. It is inappropriate to use Internet-Drafts as reference and development activities. These results might not be suitable for
material or to cite them other than as "work in progress." deployment. This RFC represents the consensus of the Crypto Forum
Research Group of the Internet Research Task Force (IRTF). Documents
approved for publication by the IRSG are not candidates for any level
of Internet Standard; see Section 2 of RFC 7841.
This Internet-Draft will expire on 25 August 2025. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9861.
Copyright Notice Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document.
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Conventions
2. TurboSHAKE . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. TurboSHAKE
2.1. Interface . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Interface
2.2. Specifications . . . . . . . . . . . . . . . . . . . . . 6 2.2. Specifications
3. KangarooTwelve: Tree hashing over TurboSHAKE . . . . . . . . 8 3. KangarooTwelve: Tree Hashing over TurboSHAKE
3.1. Interface . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1. Interface
3.2. Specification of KT128 . . . . . . . . . . . . . . . . . 8 3.2. Specification of KT128
3.3. length_encode( x ) . . . . . . . . . . . . . . . . . . . 11 3.3. length_encode( x )
3.4. Specification of KT256 . . . . . . . . . . . . . . . . . 11 3.4. Specification of KT256
4. Message authentication codes . . . . . . . . . . . . . . . . 11 4. Message Authentication Codes
5. Test vectors . . . . . . . . . . . . . . . . . . . . . . . . 12 5. Test Vectors
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 6. IANA Considerations
7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 7. Security Considerations
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 8. References
8.1. Normative References . . . . . . . . . . . . . . . . . . 22 8.1. Normative References
8.2. Informative References . . . . . . . . . . . . . . . . . 23 8.2. Informative References
Appendix A. Pseudocode . . . . . . . . . . . . . . . . . . . . . 24 Appendix A. Pseudocode
A.1. Keccak-p[1600,n_r=12] . . . . . . . . . . . . . . . . . . 24 A.1. Keccak-p[1600,n_r=12]
A.2. TurboSHAKE128 . . . . . . . . . . . . . . . . . . . . . . 25 A.2. TurboSHAKE128
A.3. TurboSHAKE256 . . . . . . . . . . . . . . . . . . . . . . 26 A.3. TurboSHAKE256
A.4. KT128 . . . . . . . . . . . . . . . . . . . . . . . . . . 27 A.4. KT128
A.5. KT256 . . . . . . . . . . . . . . . . . . . . . . . . . . 28 A.5. KT256
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses
1. Introduction 1. Introduction
This document defines the TurboSHAKE128, TurboSHAKE256 [TURBOSHAKE], This document defines the TurboSHAKE128, TurboSHAKE256 [TURBOSHAKE],
KT128 and KT256 [KT] eXtendable Output Functions (XOF), i.e., a hash KT128, and KT256 [KT] eXtendable-Output Functions (XOFs), i.e., hash
function generalization that can return an output of arbitrary function generalizations that can return an output of arbitrary
length. Both TurboSHAKE128 and TurboSHAKE256 are based on a Keccak-p length. Both TurboSHAKE128 and TurboSHAKE256 are based on a Keccak-p
permutation specified in [FIPS202] and have a higher speed than the permutation specified in [FIPS202] and have a higher speed than the
SHA-3 and SHAKE functions. SHA-3 and SHAKE functions.
TurboSHAKE is a sponge function family that makes use of Keccak- TurboSHAKE is a sponge function family that makes use of Keccak-
p[n_r=12,b=1600], a round-reduced version of the permutation used in p[n_r=12,b=1600], a round-reduced version of the permutation used in
SHA-3. Similarly to the SHAKE's, it proposes two security strengths: SHA-3. Similarly to the SHAKE's security, it proposes two security
128 bits for TurboSHAKE128 and 256 bits for TurboSHAKE256. Halving strengths: 128 bits for TurboSHAKE128 and 256 bits for TurboSHAKE256.
the number of rounds compared to the original SHAKE functions makes Halving the number of rounds compared to the original SHAKE functions
TurboSHAKE roughly two times faster. makes TurboSHAKE roughly two times faster.
KangarooTwelve applies tree hashing on top of TurboSHAKE and KangarooTwelve applies tree hashing on top of TurboSHAKE and
comprises two functions, KT128 and KT256. Note that [KT] only comprises two functions, KT128 and KT256. Note that [KT] only
defined KT128 under the name KangarooTwelve. KT256 is defined in defined KT128 under the name KangarooTwelve. KT256 is defined in
this document. this document.
The SHA-3 and SHAKE functions process data in a serial manner and are The SHA-3 and SHAKE functions process data in a serial manner and are
strongly limited in exploiting available parallelism in modern CPU strongly limited in exploiting available parallelism in modern CPU
architectures. Similar to ParallelHash [SP800-185], KangarooTwelve architectures. Similar to ParallelHash [SP800-185], KangarooTwelve
splits the input message into fragments. It then applies TurboSHAKE splits the input message into fragments. It then applies TurboSHAKE
on each of them separately before applying TurboSHAKE again on the on each of them separately before applying TurboSHAKE again on the
combination of the first fragment and the digests. More precisely, combination of the first fragment and the digests. More precisely,
KT128 uses TurboSHAKE128 and KT256 uses TurboSHAKE256. They make use KT128 uses TurboSHAKE128 and KT256 uses TurboSHAKE256. They make use
of Sakura coding for ensuring soundness of the tree hashing mode of Sakura coding for ensuring soundness of the tree hashing mode
[SAKURA]. The use of TurboSHAKE in KangarooTwelve makes it faster [SAKURA]. The use of TurboSHAKE in KangarooTwelve makes it faster
than ParallelHash. than ParallelHash.
The security of TurboSHAKE128, TurboSHAKE256, KT128 and KT256 builds The security of TurboSHAKE128, TurboSHAKE256, KT128, and KT256 builds
on the public scrutiny that Keccak has received since its publication on the public scrutiny that Keccak has received since its publication
[KECCAK_CRYPTANALYSIS][TURBOSHAKE]. [KECCAK_CRYPTANALYSIS] [TURBOSHAKE].
With respect to [FIPS202] and [SP800-185] functions, TurboSHAKE128, With respect to functions defined in [FIPS202] and [SP800-185],
TurboSHAKE256, KT128 and KT256 feature the following advantages: TurboSHAKE128, TurboSHAKE256, KT128, and KT256 feature the following
advantages:
* Unlike SHA3-224, SHA3-256, SHA3-384, SHA3-512, the TurboSHAKE and * Unlike SHA3-224, SHA3-256, SHA3-384, and SHA3-512, the TurboSHAKE
KangarooTwelve functions have an extendable output. and KangarooTwelve functions have an extendable output.
* Unlike any [FIPS202] defined function, similarly to functions * Unlike any functions in [FIPS202], and similar to functions in
defined in [SP800-185], KT128 and KT256 allow the use of a [SP800-185], KT128 and KT256 allow the use of a customization
customization string. string.
* Unlike any [FIPS202] and [SP800-185] functions but ParallelHash, * Unlike any functions in [FIPS202] and [SP800-185] except for
KT128 and KT256 exploit available parallelism. ParallelHash, KT128 and KT256 exploit available parallelism.
* Unlike ParallelHash, KT128 and KT256 do not have overhead when * Unlike ParallelHash, KT128 and KT256 do not have overhead when
processing short messages. processing short messages.
* The permutation in the TurboSHAKE functions has half the number of * The permutation in the TurboSHAKE functions has half the number of
rounds compared to the one in the SHA-3 and SHAKE functions, rounds compared to the one in the SHA-3 and SHAKE functions,
making them faster than any function defined in [FIPS202]. The making them faster than any function defined in [FIPS202]. The
KangarooTwelve functions immediately benefit from the same KangarooTwelve functions immediately benefit from the same
speedup, improving over [FIPS202] and [SP800-185]. speedup, improving over [FIPS202] and [SP800-185].
With respect to SHA-256 and SHA-512 and other [FIPS180] functions, With respect to SHA-256, SHA-512, and other functions defined in
TurboSHAKE128, TurboSHAKE256, KT128 and KT256 feature the following [FIPS180], TurboSHAKE128, TurboSHAKE256, KT128, and KT256 feature the
advantages: following advantages:
* Unlike [FIPS180] functions, the TurboSHAKE and KangarooTwelve * Unlike any functions in [FIPS180], the TurboSHAKE and
functions have an extendable output. KangarooTwelve functions have an extendable output.
* The TurboSHAKE functions produce output at the same rate as they * The TurboSHAKE functions produce output at the same rate as they
process input, whereas SHA-256 and SHA-512, when used in a mask process input, whereas SHA-256 and SHA-512, when used in a mask
generation function (MGF) construction, produce output half as generation function (MGF) construction, produce output half as
fast as they process input. fast as they process input.
* Unlike the SHA-256 and SHA-512 functions, TurboSHAKE128, * Unlike the SHA-256 and SHA-512 functions, TurboSHAKE128,
TurboSHAKE256, KT128 and KT256 do not suffer from the length TurboSHAKE256, KT128, and KT256 do not suffer from the length
extension weakness. extension weakness.
* Unlike any [FIPS180] functions, TurboSHAKE128, TurboSHAKE256, * Unlike any functions in [FIPS180], TurboSHAKE128, TurboSHAKE256,
KT128 and KT256 use a round function with algebraic degree 2, KT128, and KT256 use a round function with algebraic degree 2,
which makes them more suitable to masking techniques for which makes them more suitable to masking techniques for
protections against side-channel attacks. protections against side-channel attacks.
This document represents the consensus of the Crypto Forum Research This document represents the consensus of the Crypto Forum Research
Group (CFRG) in the IRTF. It is not an IETF product and is not a Group (CFRG) in the IRTF. It has been reviewed by two members of the
standard. 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 1.1. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in BCP 14 [RFC2119] "OPTIONAL" in this document are to be interpreted as described in
[RFC8174] when, and only when, they appear in all capitals, as shown BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
here. capitals, as shown here.
The following notations are used throughout the document: The following notations are used throughout the document:
`...` denotes a string of bytes given in hexadecimal. For example, * `...` denotes a string of bytes given in hexadecimal. For
`0B 80`. example, `0B 80`.
|s| denotes the length of a byte string `s`. For example, |`FF FF`| * |s| denotes the length of a byte string `s`. For example, |`FF
= 2. FF`| = 2.
`00`^b denotes a byte string consisting of the concatenation of b * `00`^b denotes a byte string consisting of the concatenation of b
bytes `00`. For example, `00`^7 = `00 00 00 00 00 00 00`. bytes `00`. For example, `00`^7 = `00 00 00 00 00 00 00`.
`00`^0 denotes the empty byte-string. * `00`^0 denotes the empty byte string.
a||b denotes the concatenation of two strings a and b. For example, * a||b denotes the concatenation of two strings, a and b. For
`10`||`F1` = `10 F1` example, `10`||`F1` = `10 F1`.
s[n:m] denotes the selection of bytes from n (inclusive) to m * s[n:m] denotes the selection of bytes from n (inclusive) to m
(exclusive) of a string s. The indexing of a byte-string starts (exclusive) of a string s. The indexing of a byte string starts
at 0. For example, for s = `A5 C6 D7`, s[0:1] = `A5` and s[1:3] = at 0. For example, for s = `A5 C6 D7`, s[0:1] = `A5` and s[1:3] =
`C6 D7`. `C6 D7`.
s[n:] denotes the selection of bytes from n to the end of a string * s[n:] denotes the selection of bytes from n to the end of a string
s. For example, for s = `A5 C6 D7`, s[0:] = `A5 C6 D7` and s[2:] s. For example, for s = `A5 C6 D7`, s[0:] = `A5 C6 D7` and s[2:]
= `D7`. = `D7`.
In the following, x and y are byte strings of equal length: In the following, x and y are byte strings of equal length:
x^=y denotes x takes the value x XOR y. * x^=y denotes x takes the value x XOR y.
x & y denotes x AND y. * x & y denotes x AND y.
In the following, x and y are integers: In the following, x and y are integers:
x+=y denotes x takes the value x + y. * x+=y denotes x takes the value x + y.
x-=y denotes x takes the value x - y. * x-=y denotes x takes the value x - y.
x**y denotes the exponentiation of x by y. * x**y denotes the exponentiation of x by y.
x mod y denotes the remainder of the division of x by y. * x mod y denotes the remainder of the division of x by y.
x / y denotes the integer dividend of the division of x by y. * x / y denotes the integer dividend of the division of x by y.
2. TurboSHAKE 2. TurboSHAKE
2.1. Interface 2.1. Interface
TurboSHAKE is a family of eXtendable Output Functions (XOF). TurboSHAKE is a family of eXtendable-Output Functions (XOFs).
Internally, it makes use of the sponge construction, parameterized by Internally, it makes use of the sponge construction, parameterized by
two integers, the rate and the capacity, that sum to the permutation two integers, the rate and the capacity, that sum to the permutation
width (here, 1600 bits). The rate gives the number of bits processed width (here, 1600 bits). The rate gives the number of bits processed
or produced per call to the permutation, whereas the capacity or produced per call to the permutation, whereas the capacity
determines the security level, see [FIPS202] for more details. This determines the security level; see [FIPS202] for more details. This
document focuses on only two instances, namely, TurboSHAKE128 and document focuses on only two instances, namely TurboSHAKE128 and
TurboSHAKE256. (Note that the original definition includes a wider TurboSHAKE256. (Note that the original definition includes a wider
range of instances parameterized by their capacity [TURBOSHAKE].) range of instances parameterized by their capacity [TURBOSHAKE].)
An instance of TurboSHAKE takes as input parameters a byte-string M, A TurboSHAKE instance takes a byte string M, an OPTIONAL byte D, and
an OPTIONAL byte D and a positive integer L where a positive integer L as input parameters, where:
M byte-string, is the Message and * M byte string is the message,
D byte in the range [`01`, `02`, .. , `7F`], is an OPTIONAL Domain * D byte in the range [`01`, `02`, .. , `7F`] is an OPTIONAL domain
separation byte and separation byte, and
L positive integer, is the requested number of output bytes. * L positive integer is the requested number of output bytes.
Conceptually, a XOF can be viewed as a hash function with an Conceptually, an XOF can be viewed as a hash function with an
infinitely long output truncated to L bytes. This means that calling infinitely long output truncated to L bytes. This means that calling
a XOF with the same input parameters but two different lengths yields an XOF with the same input parameters but two different lengths
outputs such that the shorter one is a prefix of the longer one. yields outputs such that the shorter one is a prefix of the longer
Specifically, if L1 < L2, then TurboSHAKE(M, D, L1) is the same as one. Specifically, if L1 < L2, then TurboSHAKE(M, D, L1) is the same
the first L1 bytes of TurboSHAKE(M, D, L2). as the first L1 bytes of TurboSHAKE(M, D, L2).
By default, the Domain separation byte is `1F`. For an API that does By default, the domain separation byte is `1F`. For an API that does
not support a domain separation byte, D MUST be the `1F`. not support a domain separation byte, D MUST be the `1F`.
The TurboSHAKE instance produces output that is a hash of the (M, D) 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. couple. If D is fixed, this becomes a hash of the message M.
However, a protocol that requires a number of independent hash However, a protocol that requires a number of independent hash
functions can choose different values for D to implement these. functions can choose different values for D to implement these.
Specifically, for any distinct values D1 and D2, TurboSHAKE(M, D1, Specifically, for distinct values D1 and D2, TurboSHAKE(M, D1, L1)
L1) and TurboSHAKE(M, D2, L2) yield independent hashes of M. and TurboSHAKE(M, D2, L2) yield independent hashes of M.
Note that an implementation MAY propose an incremental input Note that an implementation MAY propose an incremental input
interface where the input string M is given in pieces. If so, the 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 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 the concatenation of the different pieces in the order they were
given. Independently, an implementation MAY propose an incremental given. Independently, an implementation MAY propose an incremental
output interface where the output string is requested in pieces of output interface where the output string is requested in pieces of
given lengths. When the output is formed by concatenating the pieces 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 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. called with L equal to the sum of the given lengths.
2.2. Specifications 2.2. Specifications
TurboSHAKE makes use of the permutation Keccak-p[1600,n_r=12], i.e., TurboSHAKE makes use of the permutation Keccak-p[1600,n_r=12], i.e.,
the permutation used in SHAKE and SHA-3 functions reduced to its last the permutation used in SHAKE and SHA-3 functions reduced to its last
n_r=12 rounds and specified in FIPS 202, Sections 3.3 and 3.4 n_r=12 rounds as specified in FIPS 202; see Sections 3.3 and 3.4 of
[FIPS202]. KP denotes this permutation. [FIPS202]. KP denotes this permutation.
Similarly to SHAKE128, TurboSHAKE128 is a sponge function calling Similarly to SHAKE128, TurboSHAKE128 is a sponge function calling
this permutation KP with a rate of 168 bytes or 1344 bits. It this permutation KP with a rate of 168 bytes or 1344 bits. It
follows that TurboSHAKE128 has a capacity of 1600 - 1344 = 256 bits follows that TurboSHAKE128 has a capacity of 1600 - 1344 = 256 bits
or 32 bytes. Respectively to SHAKE256, TurboSHAKE256 makes use of a 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 rate of 136 bytes or 1088 bits and has a capacity of 512 bits or 64
bytes. bytes.
+-------------+--------------+ +---------------+===========+==========+
| Rate | Capacity | | | Rate | Capacity |
+----------------+-------------+--------------+ +===============+===========+==========+
| TurboSHAKE128 | 168 Bytes | 32 Bytes | | TurboSHAKE128 | 168 Bytes | 32 Bytes |
| | | | +===============+-----------+----------+
| TurboSHAKE256 | 136 Bytes | 64 Bytes | | TurboSHAKE256 | 136 Bytes | 64 Bytes |
+----------------+-------------+--------------+ +===============+-----------+----------+
Table 1
We now describe the operations inside TurboSHAKE128. We now describe the operations inside TurboSHAKE128.
* First the input M' is formed by appending the domain separation * First, the input M' is formed by appending the domain separation
byte D to the message M. byte D to the message M.
* If the length of M' is not a multiple of 168 bytes then it is * If the length of M' is not a multiple of 168 bytes, then it is
padded with zeros at the end to make it a multiple of 168 bytes. padded with zeros at the end to make it a multiple of 168 bytes.
If M' is already a multiple of 168 bytes then no padding is added. If M' is already a multiple of 168 bytes, then no padding is
Then a byte `80` is XORed to the last byte of the padded input M' added. Then, a byte `80` is XORed to the last byte of the padded
and the resulting string is split into a sequence of 168-byte input M' and the resulting string is split into a sequence of
blocks. 168-byte blocks.
* M' never has a length of 0 bytes due to the presence of the domain * M' never has a length of 0 bytes due to the presence of the domain
separation byte. separation byte.
* As defined by the sponge construction, the process operates on a * As defined by the sponge construction, the process operates on a
state and consists of two phases: the absorbing phase that state and consists of two phases: the absorbing phase, which
processes the padded input M' and the squeezing phase that processes the padded input M', and the squeezing phase, which
produces the output. produces the output.
* In the absorbing phase the state is initialized to all-zero. The * In the absorbing phase, the state is initialized to all zero. The
message blocks are XORed into the first 168 bytes of the state. message blocks are XORed into the first 168 bytes of the state.
Each block absorbed is followed with an application of KP to the Each block absorbed is followed with an application of KP to the
state. state.
* In the squeezing phase the output is formed by taking the first * In the squeezing phase, the output is formed by taking the first
168 bytes of the state, applying KP to the state, and repeating as 168 bytes of the state, applying KP to the state, and repeating as
many times as is necessary. many times as is necessary.
TurboSHAKE256 performs the same steps but makes use of 136-byte TurboSHAKE256 performs the same steps but makes use of 136-byte
blocks with respect to the padding, absorbing, and squeezing phases. blocks with respect to the padding, absorbing, and squeezing phases.
The definition of the TurboSHAKE functions equivalently implements The definition of the TurboSHAKE functions equivalently implements
the pad10*1 rule; see Section 5.1 of [FIPS202] for a definition of 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 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 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 and integrates the first bit of padding of the pad10*1 rule (hence,
cannot be `00`). Additionally, it must leave room for the second bit it cannot be `00`). Additionally, it must leave room for the second
of padding (hence it cannot have the MSB set to 1), should it be the bit of padding (hence, it cannot have the most significant bit (MSB)
last byte of the block. For more details, refer to Section 6.1 of set to 1), should it be the last byte of the block. For more
[KT] and Section 3 of [TURBOSHAKE]. details, refer to Section 6.1 of [KT] and Section 3 of [TURBOSHAKE].
The pseudocode versions of TurboSHAKE128 and TurboSHAKE256 are The pseudocode versions of TurboSHAKE128 and TurboSHAKE256 are
provided respectively in Appendix A.2 and Appendix A.3. provided in Appendices A.2 and A.3, respectively.
3. KangarooTwelve: Tree hashing over TurboSHAKE 3. KangarooTwelve: Tree Hashing over TurboSHAKE
3.1. Interface 3.1. Interface
KangarooTwelve is a family of eXtendable Output Functions (XOF) KangarooTwelve is a family of eXtendable-Output Functions (XOFs)
consisting of the KT128 and KT256 instances. A KangarooTwelve consisting of the KT128 and KT256 instances. A KangarooTwelve
instance takes as input parameters two byte-strings (M, C) and a instance takes two byte strings (M, C) and a positive integer L as
positive integer L where input parameters, where:
M byte-string, is the Message and * M byte string is the message,
C byte-string, is an OPTIONAL Customization string and * C byte string is an OPTIONAL customization string, and
L positive integer, the requested number of output bytes. * L positive integer is the requested number of output bytes.
The Customization string MAY serve as domain separation. It is The customization string MAY serve as domain separation. It is
typically a short string such as a name or an identifier (e.g. URI, typically a short string such as a name or an identifier (e.g., URI,
ODI...). It can serve the same purpose as TurboSHAKE's D input Object Identifier (OID), etc.). It can serve the same purpose as
parameter (see Section 2.1), but with a larger range. 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 By default, the customization string is the empty string. For an API
that does not support a customization string parameter, C MUST be the that does not support a customization string parameter, C MUST be the
empty string. empty string.
Note that an implementation MAY propose an interface with the input Note that an implementation MAY propose an interface with the input
and/or output provided incrementally as specified in Section 2.1. and/or output provided incrementally, as specified in Section 2.1.
3.2. Specification of KT128 3.2. Specification of KT128
On top of the sponge function TurboSHAKE128, KT128 uses a Sakura- On top of the sponge function TurboSHAKE128, KT128 uses a Sakura-
compatible tree hash mode [SAKURA]. First, merge M and the OPTIONAL compatible tree hash mode [SAKURA]. First, merge M and the OPTIONAL
C to a single input string S in a reversible way. length_encode( |C| C to a single input string S in a reversible way.
) gives the length in bytes of C as a byte-string. See Section 3.3. length_encode( |C| ) gives the length in bytes of C as a byte string.
See Section 3.3.
S = M || C || length_encode( |C| ) S = M || C || length_encode( |C| )
Then, split S into n chunks of 8192 bytes. Then, split S into n chunks of 8192 bytes.
S = S_0 || .. || S_(n-1) S = S_0 || .. || S_(n-1)
|S_0| = .. = |S_(n-2)| = 8192 bytes |S_0| = .. = |S_(n-2)| = 8192 bytes
|S_(n-1)| <= 8192 bytes |S_(n-1)| <= 8192 bytes
From S_1 .. S_(n-1), compute the 32-byte Chaining Values CV_1 .. 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 CV_(n-1). In order to be optimally efficient, this computation MAY
exploit the parallelism available on the platform such as SIMD exploit the parallelism available on the platform, such as single
instructions. instruction, multiple data (SIMD) instructions.
CV_i = TurboSHAKE128( S_i, `0B`, 32 ) CV_i = TurboSHAKE128( S_i, `0B`, 32 )
Compute the final node: FinalNode. Compute the final node: FinalNode.
* If |S| <= 8192 bytes, FinalNode = S * If |S| <= 8192 bytes, FinalNode = S.
* Otherwise compute FinalNode as follows: * Otherwise, compute FinalNode as follows:
FinalNode = S_0 || `03 00 00 00 00 00 00 00` FinalNode = S_0 || `03 00 00 00 00 00 00 00`
FinalNode = FinalNode || CV_1 FinalNode = FinalNode || CV_1
.. ..
FinalNode = FinalNode || CV_(n-1) FinalNode = FinalNode || CV_(n-1)
FinalNode = FinalNode || length_encode(n-1) FinalNode = FinalNode || length_encode(n-1)
FinalNode = FinalNode || `FF FF` FinalNode = FinalNode || `FF FF`
Finally, the KT128 output is retrieved: Finally, the KT128 output is retrieved:
* If |S| <= 8192 bytes, from TurboSHAKE128( FinalNode, `07`, L ) * If |S| <= 8192 bytes, from TurboSHAKE128( FinalNode, `07`, L )
KT128( M, C, L ) = TurboSHAKE128( FinalNode, `07`, L ) KT128( M, C, L ) = TurboSHAKE128( FinalNode, `07`, L )
* Otherwise from TurboSHAKE128( FinalNode, `06`, L ) * Otherwise, from TurboSHAKE128( FinalNode, `06`, L )
KT128( M, C, L ) = TurboSHAKE128( FinalNode, `06`, L ) KT128( M, C, L ) = TurboSHAKE128( FinalNode, `06`, L )
The following figure illustrates the computation flow of KT128 The following figure illustrates the computation flow of KT128
for |S| <= 8192 bytes: for |S| <= 8192 bytes:
+--------------+ TurboSHAKE128(.., `07`, L) +--------------+ TurboSHAKE128(.., `07`, L)
| S |-----------------------------> output | S |-----------------------------> output
+--------------+ +--------------+
The following figure illustrates the computation flow of KT128 The following figure illustrates the computation flow of KT128
for |S| > 8192 bytes and where TurboSHAKE128 and length_encode( x ) for |S| > 8192 bytes and where TurboSHAKE128 and length_encode( x )
are abbreviated as respectively TSHK128 and l_e( x ) : are abbreviated as TSHK128 and l_e( x ), respectively:
+--------------+ +--------------+
| S_0 | | S_0 |
+--------------+ +--------------+
|| ||
+--------------+ +--------------+
| `03`||`00`^7 | | `03`||`00`^7 |
+--------------+ +--------------+
|| ||
+---------+ TSHK128(..,`0B`,32) +--------------+ +---------+ TSHK128(..,`0B`,32) +--------------+
skipping to change at page 10, line 42 skipping to change at line 465
| `FF FF` | | `FF FF` |
+--------------+ +--------------+
| TSHK128(.., `06`, L) | TSHK128(.., `06`, L)
+--------------------> output +--------------------> output
A pseudocode version is provided in Appendix A.4. A pseudocode version is provided in Appendix A.4.
The table below gathers the values of the domain separation bytes The table below gathers the values of the domain separation bytes
used by the tree hash mode: used by the tree hash mode:
+--------------------+------------------+ +==================+======+
| Type | Byte | | Type | Byte |
+--------------------+------------------+ +==================+======+
| SingleNode | `07` | | SingleNode | `07` |
| | | +------------------+------+
| IntermediateNode | `0B` | | IntermediateNode | `0B` |
| | | +------------------+------+
| FinalNode | `06` | | FinalNode | `06` |
+--------------------+------------------+ +------------------+------+
Table 2
3.3. length_encode( x ) 3.3. length_encode( x )
The function length_encode takes as inputs a non-negative integer 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 256**255 and outputs a string of bytes x_(n-1) || .. || x_0 || n
where where
x = sum of 256**i * x_i for i from 0 to n-1 x = sum of 256**i * x_i for i from 0 to n-1
and where n is the smallest non-negative integer such that x < 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. 256**n. n is also the length of x_(n-1) || .. || x_0.
As example, length_encode(0) = `00`, length_encode(12) = `0C 01` and For example, length_encode(0) = `00`, length_encode(12) = `0C 01`,
length_encode(65538) = `01 00 02 03` and length_encode(65538) = `01 00 02 03`.
A pseudocode version is as follows where { b } denotes the byte of A pseudocode version is as follows, where { b } denotes the byte of
numerical value b. numerical value b.
length_encode(x): length_encode(x):
S = `00`^0 S = `00`^0
while x > 0 while x > 0
S = { x mod 256 } || S S = { x mod 256 } || S
x = x / 256 x = x / 256
S = S || { |S| } S = S || { |S| }
skipping to change at page 11, line 41 skipping to change at line 513
return S return S
end end
3.4. Specification of KT256 3.4. Specification of KT256
KT256 is specified exactly like KT128, with two differences: KT256 is specified exactly like KT128, with two differences:
* All the calls to TurboSHAKE128 in KT128 are replaced with calls to * All the calls to TurboSHAKE128 in KT128 are replaced with calls to
TurboSHAKE256 in KT256. TurboSHAKE256 in KT256.
* The chaining values CV_1 to CV_(n-1) are 64-byte long in KT256 and * The chaining values CV_1 to CV_(n-1) are 64 bytes long in KT256
are computed as follows: and are computed as follows:
CV_i = TurboSHAKE256( S_i, `0B`, 64 ) CV_i = TurboSHAKE256( S_i, `0B`, 64 )
A pseudocode version is provided in Appendix A.5. A pseudocode version is provided in Appendix A.5.
4. Message authentication codes 4. Message Authentication Codes
Implementing a MAC with KT128 or KT256 MAY use a hash-then-MAC Implementing a Message Authentication Code (MAC) with KT128 or KT256
construction. This document defines and recommends a method called MAY use a hash-then-MAC construction. This document defines and
HopMAC: recommends a method called HopMAC:
HopMAC128(Key, M, C, L) = KT128(Key, KT128(M, C, 32), L) HopMAC128(Key, M, C, L) = KT128(Key, KT128(M, C, 32), L)
HopMAC256(Key, M, C, L) = KT256(Key, KT256(M, C, 64), L) HopMAC256(Key, M, C, L) = KT256(Key, KT256(M, C, 64), L)
Similarly to HMAC, HopMAC consists of two calls: an inner call Similarly to Hashed Message Authentication Code (HMAC), HopMAC
compressing the message M and the optional customization string C to consists of two calls: an inner call compressing the message M and
a digest, and an outer call computing the tag from the key and the the optional customization string C to a digest and an outer call
digest. computing the tag from the key and the digest.
Unlike HMAC, the inner call to KangarooTwelve in HopMAC is keyless Unlike HMAC, the inner call to KangarooTwelve in HopMAC is keyless
and does not require additional protection against side channel and does not require additional protection against side channel
attacks (SCA). Consequently, in an implementation that has to attacks (SCAs). Consequently, in an implementation that has to
protect the HopMAC key against SCA only the outer call does need protect the HopMAC key against an SCA, only the outer call needs
protection, and this amounts to a single execution of the underlying protection, and this amounts to a single execution of the underlying
permutation (assuming the key length is at most 69 bytes). permutation (assuming the key length is at most 69 bytes).
In any case, TurboSHAKE128, TurboSHAKE256, KT128 and KT256 MAY be In any case, TurboSHAKE128, TurboSHAKE256, KT128, and KT256 MAY be
used to compute a MAC with the key reversibly prepended or appended 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 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., simply calling KT128 with the key as the customization string, i.e.,
MAC = KT128(M, Key, L). MAC = KT128(M, Key, L).
5. Test vectors 5. Test Vectors
Test vectors are based on the repetition of the pattern `00 01 02 .. 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 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 the pattern `00 01 02 .. F9 FA` as many times as necessary and
truncated to n bytes e.g. truncated to n bytes, for example:
Pattern for a length of 17 bytes: Pattern for a length of 17 bytes:
ptn(17) = ptn(17) =
`00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10` `00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10`
Pattern for a length of 17**2 bytes: Pattern for a length of 17**2 bytes:
ptn(17**2) = ptn(17**2) =
`00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F `00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F
20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F
skipping to change at page 20, line 32 skipping to change at line 922
3C 37 F1 EC AF 8D 2C 2C 96 C1 D1 6C 64 B1 24 96` 3C 37 F1 EC AF 8D 2C 2C 96 C1 D1 6C 64 B1 24 96`
KT256(M=ptn(8192 bytes), C=ptn(8190 bytes), 64): KT256(M=ptn(8192 bytes), C=ptn(8190 bytes), 64):
`F4 B5 90 8B 92 9F FE 01 E0 F7 9E C2 F2 12 43 D4 `F4 B5 90 8B 92 9F FE 01 E0 F7 9E C2 F2 12 43 D4
1A 39 6B 2E 73 03 A6 AF 1D 63 99 CD 6C 7A 0A 2D 1A 39 6B 2E 73 03 A6 AF 1D 63 99 CD 6C 7A 0A 2D
D7 C4 F6 07 E8 27 7F 9C 9B 1C B4 AB 9D DC 59 D4 D7 C4 F6 07 E8 27 7F 9C 9B 1C B4 AB 9D DC 59 D4
B9 2D 1F C7 55 84 41 F1 83 2C 32 79 A4 24 1B 8B` B9 2D 1F C7 55 84 41 F1 83 2C 32 79 A4 24 1B 8B`
6. IANA Considerations 6. IANA Considerations
In the Named Information Hash Algorithm Registry, k12-256 refers to In the "Named Information Hash Algorithm Registry", k12-256 refers to
the hash function obtained by evaluating KT128 on the input message the hash function obtained by evaluating KT128 on the input message
with default C (the empty string) and L = 32 bytes (256 bits). with default C (the empty string) and L = 32 bytes (256 bits).
Similarly, k12-512 refers to the hash function obtained by evaluating Similarly, k12-512 refers to the hash function obtained by evaluating
KT256 on the input message with default C (the empty string) and L = KT256 on the input message with default C (the empty string) and L =
64 bytes (512 bits). 64 bytes (512 bits).
In the COSE Algorithms registry, the following entries are assigned In the "COSE Algorithms" registry, IANA has added the following
to TurboSHAKE and KangarooTwelve: entries for TurboSHAKE and KangarooTwelve:
+---------------+-------+-------------------+--------------+ +===============+=======+===================+==============+
| Name | Value | Description | Capabilities | | Name | Value | Description | Capabilities |
+---------------+-------+-------------------+--------------+ +===============+=======+===================+==============+
| TurboSHAKE128 | -261 | TurboSHAKE128 XOF | [kty] | | TurboSHAKE128 | -261 | TurboSHAKE128 XOF | [kty] |
| | | | | +---------------+-------+-------------------+--------------+
| TurboSHAKE256 | -262 | TurboSHAKE256 XOF | [kty] | | TurboSHAKE256 | -262 | TurboSHAKE256 XOF | [kty] |
| | | | | +---------------+-------+-------------------+--------------+
| KT128 | -263 | KT128 XOF | [kty] | | KT128 | -263 | KT128 XOF | [kty] |
| | | | | +---------------+-------+-------------------+--------------+
| KT256 | -264 | KT256 XOF | [kty] | | KT256 | -264 | KT256 XOF | [kty] |
+---------------+-------+-------------------+--------------+ +---------------+-------+-------------------+--------------+
Table 3
7. Security Considerations 7. Security Considerations
This document is meant to serve as a stable reference and an This document is meant to serve as a stable reference and an
implementation guide for the KangarooTwelve and TurboSHAKE eXtendable implementation guide for the KangarooTwelve and TurboSHAKE
Output Functions. The security assurance of these functions relies eXtendable-Output Functions. The security assurance of these
on the cryptanalysis of reduced-round versions of Keccak and they functions relies on the cryptanalysis of reduced-round versions of
have the same claimed security strength as their corresponding SHAKE Keccak, and they have the same claimed security strength as their
functions. corresponding SHAKE functions.
+-------------------------------+ +---------------+=============================+
| security claim | | | Security Claim |
+-----------------+-------------------------------+ +===============+=============================+
| TurboSHAKE128 | 128 bits (same as SHAKE128) | | TurboSHAKE128 | 128 bits (same as SHAKE128) |
| | | +===============+-----------------------------+
| KT128 | 128 bits (same as SHAKE128) | | KT128 | 128 bits (same as SHAKE128) |
| | | +===============+-----------------------------+
| TurboSHAKE256 | 256 bits (same as SHAKE256) | | TurboSHAKE256 | 256 bits (same as SHAKE256) |
| | | +===============+-----------------------------+
| KT256 | 256 bits (same as SHAKE256) | | KT256 | 256 bits (same as SHAKE256) |
+-----------------+-------------------------------+ +===============+-----------------------------+
Table 4
To be more precise, KT128 is made of two layers: To be more precise, KT128 is made of two layers:
* The inner function TurboSHAKE128. The security assurance of this * The inner function TurboSHAKE128. The security assurance of this
layer relies on cryptanalysis. The TurboSHAKE128 function is layer relies on cryptanalysis. The TurboSHAKE128 function is
exactly Keccak[r=1344, c=256] (as in SHAKE128) reduced to 12 exactly Keccak[r=1344, c=256] (as in SHAKE128) reduced to 12
rounds. Any cryptanalysis of reduced-round Keccak is also rounds. Any cryptanalysis of reduced-round Keccak is also
cryptanalysis of reduced-round TurboSHAKE128 (provided the number cryptanalysis of reduced-round TurboSHAKE128 (provided the number
of rounds attacked is not higher than 12). of rounds attacked is not higher than 12).
* The tree hashing over TurboSHAKE128. This layer is a mode on top * The tree hashing over TurboSHAKE128. This layer is a mode on top
of TurboSHAKE128 that does not introduce any vulnerability thanks of TurboSHAKE128 that does not introduce any vulnerability thanks
to the use of Sakura coding proven secure in [SAKURA]. to the use of Sakura coding proven secure in [SAKURA].
This reasoning is detailed and formalized in [KT]. This reasoning is detailed and formalized in [KT].
KT256 is structured as KT128, except that it uses TurboSHAKE256 as KT256 is structured as KT128, except that it uses TurboSHAKE256 as
inner function. The TurboSHAKE256 function is exactly Keccak[r=1088, the inner function. The TurboSHAKE256 function is exactly
c=512] (as in SHAKE256) reduced to 12 rounds, and the same reasoning Keccak[r=1088, c=512] (as in SHAKE256) reduced to 12 rounds, and the
on cryptanalysis applies. same reasoning on cryptanalysis applies.
TurboSHAKE128 and KT128 aim at 128-bit security. To achieve 128-bit TurboSHAKE128 and KT128 aim at 128-bit security. To achieve 128-bit
security strength, the output L MUST be chosen long enough so that security strength, L, the chosen output length, MUST be large enough
there are no generic attacks that violate 128-bit security. So for so that there are no generic attacks that violate 128-bit security.
128-bit (second) preimage security the output should be at least 128 So for 128-bit (second) preimage security, the output should be at
bits, for 128 bits of security against multi-target preimage attacks least 128 bits; for 128 bits of security against multi-target
with T targets the output should be at least 128+log_2(T) bits and preimage attacks with T targets, the output should be at least
for 128-bit collision security the output should be at least 256 128+log_2(T) bits; and for 128-bit collision security, the output
bits. Furthermore, when the output length is at least 256 bits, should be at least 256 bits. Furthermore, when the output length is
TurboSHAKE128 and KT128 achieve NIST's post-quantum security level 2 at least 256 bits, TurboSHAKE128 and KT128 achieve NIST's post-
[NISTPQ]. quantum security level 2 [NISTPQ].
Similarly, TurboSHAKE256 and KT256 aim at 256-bit security. To Similarly, TurboSHAKE256 and KT256 aim at 256-bit security. To
achieve 256-bit security strength, the output L MUST be chosen long achieve 256-bit security strength, L, the chosen output length, MUST
enough so that there are no generic attacks that violate 256-bit be large enough so that there are no generic attacks that violate
security. So for 256-bit (second) preimage security the output 256-bit security. So for 256-bit (second) preimage security, the
should be at least 256 bits, for 256 bits of security against multi- output should be at least 256 bits; for 256 bits of security against
target preimage attacks with T targets the output should be at least multi-target preimage attacks with T targets, the output should be at
256+log_2(T) bits and for 256-bit collision security the output least 256+log_2(T) bits; and for 256-bit collision security, the
should be at least 512 bits. Furthermore, when the output length is output should be at least 512 bits. Furthermore, when the output
at least 512 bits, TurboSHAKE256 and KT256 achieve NIST's post- length is at least 512 bits, TurboSHAKE256 and KT256 achieve NIST's
quantum security level 5 [NISTPQ]. post-quantum security level 5 [NISTPQ].
Unlike the SHA-256 and SHA-512 functions, TurboSHAKE128, Unlike the SHA-256 and SHA-512 functions, TurboSHAKE128,
TurboSHAKE256, KT128 and KT256 do not suffer from the length TurboSHAKE256, KT128, and KT256 do not suffer from the length
extension weakness, and therefore do not require the use of the HMAC extension weakness and therefore do not require the use of the HMAC
construction for instance when used for MAC computation [FIPS198]. construction, for instance, when used for MAC computation [FIPS198].
Also, they can naturally be used as a key derivation function. The Also, they can naturally be used as a key derivation function. The
input must be an injective encoding of secret and diversification input must be an injective encoding of secret and diversification
material, and the output can be taken as the derived key(s). The 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 input does not need to be uniformly distributed, e.g., it can be a
shared secret produced by the Diffie-Hellman or ECDH protocol, but it shared secret produced by the Diffie-Hellman or Elliptic Curve
needs to have sufficient min-entropy. Diffie-Hellman (ECDH) protocol, but it needs to have sufficient min-
entropy.
Lastly, as KT128 and KT256 use TurboSHAKE with three values for D, Lastly, as KT128 and KT256 use TurboSHAKE with three values for D,
namely 0x06, 0x07, and 0x0B. Protocols that use both KT128 and namely 0x06, 0x07, and 0x0B, protocols that use both KT128 and
TurboSHAKE128, or both KT256 and TurboSHAKE256, SHOULD avoid using TurboSHAKE128 or both KT256 and TurboSHAKE256 SHOULD avoid using
these three values for D. these three values for D.
8. References 8. References
8.1. Normative References 8.1. Normative References
[FIPS202] NIST, "SHA-3 Standard: Permutation-Based Hash and
Extendable-Output Functions", NIST FIPS 202,
DOI 10.6028/NIST.FIPS.202, August 2015,
<https://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.202.pdf>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[FIPS202] National Institute of Standards and Technology, "FIPS PUB
202 - SHA-3 Standard: Permutation-Based Hash and
Extendable-Output Functions",
WWW http://dx.doi.org/10.6028/NIST.FIPS.202, August 2015.
[SP800-185] [SP800-185]
National Institute of Standards and Technology, "NIST Kelsey, J., Chang, S., and R. Perlner, "SHA-3 Derived
Special Publication 800-185 SHA-3 Derived Functions: Functions: cSHAKE, KMAC, TupleHash and ParallelHash",
cSHAKE, KMAC, TupleHash and ParallelHash", National Institute of Standards and Technology, NIST
WWW https://doi.org/10.6028/NIST.SP.800-185, December SP 800-185, DOI 10.6028/NIST.SP.800-185, December 2016,
2016. <https://doi.org/10.6028/NIST.SP.800-185>.
8.2. Informative References 8.2. Informative References
[TURBOSHAKE] [FIPS180] NIST, "Secure Hash Standard", NIST FIPS 180-4,
Bertoni, G., Daemen, J., Hoffert, S., Peeters, M., Van DOI 10.6028/NIST.FIPS.180-4, August 2015,
Assche, G., Van Keer, R., and B. Viguier, "TurboSHAKE", <https://nvlpubs.nist.gov/nistpubs/FIPS/
WWW http://eprint.iacr.org/2023/342, March 2023. NIST.FIPS.180-4.pdf>.
[KT] Bertoni, G., Daemen, J., Peeters, M., Van Assche, G., Van
Keer, R., and B. Viguier, "KangarooTwelve: fast hashing
based on Keccak-p", WWW https://link.springer.com/
chapter/10.1007/978-3-319-93387-0_21,
WWW http://eprint.iacr.org/2016/770.pdf, July 2018.
[SAKURA] Bertoni, G., Daemen, J., Peeters, M., and G. Van Assche, [FIPS198] NIST, "The Keyed-Hash Message Authentication Code (HMAC)",
"Sakura: a flexible coding for tree hashing", WWW NIST FIPS 198-1, DOI 10.6028/NIST.FIPS.198-1, July 2008,
https://link.springer.com/ <https://nvlpubs.nist.gov/nistpubs/FIPS/
chapter/10.1007/978-3-319-07536-5_14, NIST.FIPS.198-1.pdf>.
WWW http://eprint.iacr.org/2013/231.pdf, June 2014.
[KECCAK_CRYPTANALYSIS] [KECCAK_CRYPTANALYSIS]
Keccak Team, "Summary of Third-party cryptanalysis of Keccak Team, "Summary of Third-party cryptanalysis of
Keccak", WWW https://www.keccak.team/third_party.html, Keccak", <https://www.keccak.team/third_party.html>.
2022.
[XKCP] Bertoni, G., Daemen, J., Peeters, M., Van Assche, G., and [KT] Bertoni, G., Daemen, J., Peeters, M., Van Assche, G., Van
R. Van Keer, "eXtended Keccak Code Package", Keer, R., and B. Viguier, "KangarooTwelve: Fast Hashing
WWW https://github.com/XKCP/XKCP, December 2022. Based on Keccak-p", Applied Cryptography and Network
Security (ACNS 2018), Lecture Notes in Computer Science,
vol. 10892, pp. 400-418, DOI 10.1007/978-3-319-93387-0_21,
June 2018, <https://link.springer.com/
chapter/10.1007/978-3-319-93387-0_21>.
[NISTPQ] National Institute of Standards and Technology, [NISTPQ] NIST, "Submission Requirements and Evaluation Criteria for
"Submission Requirements and Evaluation Criteria for the the Post-Quantum Cryptography Standardization Process",
Post-Quantum Cryptography Standardization Process", WWW <https://csrc.nist.gov/CSRC/media/Projects/Post-Quantum-
https://csrc.nist.gov/CSRC/media/Projects/Post-Quantum-
Cryptography/documents/call-for-proposals-final-dec- Cryptography/documents/call-for-proposals-final-dec-
2016.pdf, December 2016. 2016.pdf>.
[FIPS180] National Institute of Standards and Technology (NIST), [SAKURA] Bertoni, G., Daemen, J., Peeters, M., and G. Van Assche,
"Secure Hash Standard (SHS)", FIPS PUB 180-4, "Sakura: a Flexible Coding for Tree Hashing", Applied
WWW https://doi.org/10.6028/NIST.FIPS.180-4, August 2015. Cryptography and Network Security (ACNS 2014), Lecture
Notes in Computer Science, vol. 8479, pp. 217-234,
DOI 10.1007/978-3-319-07536-5_14, 2014,
<https://link.springer.com/
chapter/10.1007/978-3-319-07536-5_14>.
[FIPS198] National Institute of Standards and Technology (NIST), [TURBOSHAKE]
"The Keyed-Hash Message Authentication Code (HMAC)", FIPS Bertoni, G., Daemen, J., Hoffert, S., Peeters, M., Van
PUB 198-1, WWW https://doi.org/10.6028/NIST.FIPS.198-1, Assche, G., Van Keer, R., and B. Viguier, "TurboSHAKE",
July 2008. Cryptology ePrint Archive, Paper 2023/342, March 2023,
<http://eprint.iacr.org/2023/342>.
[XKCP] "eXtended Keccak Code Package", commit 64404bee, December
2022, <https://github.com/XKCP/XKCP>.
Appendix A. Pseudocode Appendix A. Pseudocode
The sub-sections of this appendix contain pseudocode definitions of The subsections of this appendix contain pseudocode definitions of
TurboSHAKE128, TurboSHAKE256 and KangarooTwelve. Standalone Python TurboSHAKE128, TurboSHAKE256, and KangarooTwelve. Standalone Python
versions are also available in the Keccak Code Package [XKCP] and in versions are also available in the Keccak Code Package [XKCP] and in
[KT] [KT]
A.1. Keccak-p[1600,n_r=12] A.1. Keccak-p[1600,n_r=12]
KP(state): KP(state):
RC[0] = `8B 80 00 80 00 00 00 00` RC[0] = `8B 80 00 80 00 00 00 00`
RC[1] = `8B 00 00 00 00 00 00 80` RC[1] = `8B 00 00 00 00 00 00 80`
RC[2] = `89 80 00 00 00 00 00 80` RC[2] = `89 80 00 00 00 00 00 80`
RC[3] = `03 80 00 00 00 00 00 80` RC[3] = `03 80 00 00 00 00 00 80`
skipping to change at page 25, line 40 skipping to change at line 1169
state = `00`^0 state = `00`^0
for y from 0 to 4 for y from 0 to 4
for x from 0 to 4 for x from 0 to 4
state = state || lanes[x][y] state = state || lanes[x][y]
return state return state
end end
where ROL64(x, y) is a rotation of the 'x' 64-bit word toward the 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 bits with higher indexes by 'y' positions. The 8-bytes byte string x
is interpreted as a 64-bit word in little-endian format. is interpreted as a 64-bit word in little-endian format.
A.2. TurboSHAKE128 A.2. TurboSHAKE128
TurboSHAKE128(message, separationByte, outputByteLen): TurboSHAKE128(message, separationByte, outputByteLen):
offset = 0 offset = 0
state = `00`^200 state = `00`^200
input = message || separationByte input = message || separationByte
# === Absorb complete blocks === # === Absorb complete blocks ===
while offset < |input| - 168 while offset < |input| - 168
state ^= input[offset : offset + 168] || `00`^32 state ^= input[offset : offset + 168] || `00`^32
state = KP(state) state = KP(state)
offset += 168 offset += 168
skipping to change at page 28, line 4 skipping to change at line 1233
while outputByteLen > 136 while outputByteLen > 136
output = output || state[0:136] output = output || state[0:136]
outputByteLen -= 136 outputByteLen -= 136
state = KP(state) state = KP(state)
output = output || state[0:outputByteLen] output = output || state[0:outputByteLen]
return output return output
A.4. KT128 A.4. KT128
KT128(inputMessage, customString, outputByteLen):
S = inputMessage || customString
S = S || length_encode( |customString| )
if |S| <= 8192 KT128(inputMessage, customString, outputByteLen):
return TurboSHAKE128(S, `07`, outputByteLen) S = inputMessage || customString
else S = S || length_encode( |customString| )
# === Kangaroo hopping ===
FinalNode = S[0:8192] || `03` || `00`^7
offset = 8192
numBlock = 0
while offset < |S|
blockSize = min( |S| - offset, 8192)
CV = TurboSHAKE128(S[offset : offset + blockSize], `0B`, 32)
FinalNode = FinalNode || CV
numBlock += 1
offset += blockSize
FinalNode = FinalNode || length_encode( numBlock ) || `FF FF` if |S| <= 8192
return TurboSHAKE128(S, `07`, outputByteLen)
else
# === Kangaroo hopping ===
FinalNode = S[0:8192] || `03` || `00`^7
offset = 8192
numBlock = 0
while offset < |S|
blockSize = min( |S| - offset, 8192)
CV = TurboSHAKE128(S[offset : offset+blockSize], `0B`, 32)
FinalNode = FinalNode || CV
numBlock += 1
offset += blockSize
return TurboSHAKE128(FinalNode, `06`, outputByteLen) FinalNode = FinalNode || length_encode( numBlock ) || `FF FF`
end
return TurboSHAKE128(FinalNode, `06`, outputByteLen)
end
A.5. KT256 A.5. KT256
KT256(inputMessage, customString, outputByteLen): KT256(inputMessage, customString, outputByteLen):
S = inputMessage || customString S = inputMessage || customString
S = S || length_encode( |customString| ) S = S || length_encode( |customString| )
if |S| <= 8192 if |S| <= 8192
return TurboSHAKE256(S, `07`, outputByteLen) return TurboSHAKE256(S, `07`, outputByteLen)
else else
# === Kangaroo hopping === # === Kangaroo hopping ===
FinalNode = S[0:8192] || `03` || `00`^7 FinalNode = S[0:8192] || `03` || `00`^7
offset = 8192 offset = 8192
numBlock = 0 numBlock = 0
while offset < |S| while offset < |S|
blockSize = min( |S| - offset, 8192) blockSize = min( |S| - offset, 8192)
CV = TurboSHAKE256(S[offset : offset + blockSize], `0B`, 64) CV = TurboSHAKE256(S[offset : offset+blockSize], `0B`, 64)
FinalNode = FinalNode || CV FinalNode = FinalNode || CV
numBlock += 1 numBlock += 1
offset += blockSize offset += blockSize
FinalNode = FinalNode || length_encode( numBlock ) || `FF FF` FinalNode = FinalNode || length_encode( numBlock ) || `FF FF`
return TurboSHAKE256(FinalNode, `06`, outputByteLen) return TurboSHAKE256(FinalNode, `06`, outputByteLen)
end end
Authors' Addresses Authors' Addresses
Benoît Viguier Benoît Viguier
ABN AMRO Bank ABN AMRO Bank
Groenelaan 2 Groenelaan 2
Amstelveen Amstelveen
Netherlands
Email: cs.ru.nl@viguier.nl Email: cs.ru.nl@viguier.nl
David Wong (editor) David Wong (editor)
zkSecurity zkSecurity
Email: davidwong.crypto@gmail.com Email: davidwong.crypto@gmail.com
Gilles Van Assche (editor) Gilles Van Assche (editor)
STMicroelectronics STMicroelectronics
Email: gilles.vanassche@st.com Email: gilles.vanassche@st.com
 End of changes. 125 change blocks. 
337 lines changed or deleted 354 lines changed or added

This html diff was produced by rfcdiff 1.48.