rfc9861v1.txt		rfc9861.txt
	skipping to change at line 98 ¶		skipping to change at line 98 ¶
	This document defines the TurboSHAKE128, TurboSHAKE256 [TURBOSHAKE],		This document defines the TurboSHAKE128, TurboSHAKE256 [TURBOSHAKE],
	KT128, and KT256 [KT] eXtendable-Output Functions (XOFs), i.e., hash		KT128, and KT256 [KT] eXtendable-Output Functions (XOFs), i.e., hash
	function generalizations 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
	skipping to change at line 168 ¶		skipping to change at line 168 ¶
	* 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 functions in [FIPS180], 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", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in		"OPTIONAL" in this document are to be interpreted as described in
	BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all		BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	The following notations are used throughout the document:		The following notations are used throughout the document:
	skipping to change at line 239 ¶		skipping to change at line 240 ¶
	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].)
	A TurboSHAKE instance takes a byte string M, an OPTIONAL byte D, and		A TurboSHAKE instance takes a byte string M, an OPTIONAL byte D, and
	a positive integer L as input parameters, where:		a positive integer L as input parameters, where:
	* M byte string is the Message,		* 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, an 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
	an XOF with the same input parameters but two different lengths		an XOF with the same input parameters but two different lengths
	yields outputs such that the shorter one is a prefix of the longer		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		one. Specifically, if L1 < L2, then TurboSHAKE(M, D, L1) is the same
	as 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.
	skipping to change at line 351 ¶		skipping to change at line 352 ¶
	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 (XOFs)		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 two byte strings (M, C) and a positive integer L as		instance takes two byte strings (M, C) and a positive integer L as
	input parameters, where:		input parameters, where:
	* M byte string is the Message,		* 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 is 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,
	Original Dialog Identifier (ODI), etc.). It can serve the same		Original Dialog Identifier (ODI), etc.). It can serve the same
	purpose as TurboSHAKE's D input parameter (see Section 2.1) but with		purpose as TurboSHAKE's D input parameter (see Section 2.1) but with
	a larger range.		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
	skipping to change at line 386 ¶		skipping to change at line 387 ¶
	See Section 3.3.		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 single		exploit the parallelism available on the platform, such as single
	instruction, multiple data (SIMD) 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.
	skipping to change at line 425 ¶		skipping to change at line 426 ¶
	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 respectively as 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 line 989 ¶		skipping to change at line 990 ¶
	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
	the inner function. The TurboSHAKE256 function is exactly		the inner function. The TurboSHAKE256 function is exactly
	Keccak[r=1088, c=512] (as in SHAKE256) reduced to 12 rounds, and the		Keccak[r=1088, c=512] (as in SHAKE256) reduced to 12 rounds, and the
	same reasoning 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 Elliptic Curve		shared secret produced by the Diffie-Hellman or Elliptic Curve
	Diffie-Hellman (ECDH) protocol, but it needs to have sufficient min-		Diffie-Hellman (ECDH) protocol, but it needs to have sufficient min-
	entropy.		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] 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>.
	[SP800-185]		[SP800-185]
	Kelsey, J., Chang, S., and R. Perlner, "SHA-3 Derived		Kelsey, J., Chang, S., and R. Perlner, "SHA-3 Derived
	Functions: cSHAKE, KMAC, TupleHash and ParallelHash",		Functions: cSHAKE, KMAC, TupleHash and ParallelHash",
	National Institute of Standards and Technology, NIST		National Institute of Standards and Technology, NIST
	SP 800-185, DOI 10.6028/NIST.SP.800-185, December 2016,		SP 800-185, DOI 10.6028/NIST.SP.800-185, December 2016,
	<https://doi.org/10.6028/NIST.SP.800-185>.		<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/
	Cryptology ePrint Archive, Paper 2023/342, March 2023,		NIST.FIPS.180-4.pdf>.
	<http://eprint.iacr.org/2023/342>.
			[FIPS198] NIST, "The Keyed-Hash Message Authentication Code (HMAC)",
			NIST FIPS 198-1, DOI 10.6028/NIST.FIPS.198-1, July 2008,
			<https://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		[KT] Bertoni, G., Daemen, J., Peeters, M., Van Assche, G., Van
	Keer, R., and B. Viguier, "KangarooTwelve: Fast Hashing		Keer, R., and B. Viguier, "KangarooTwelve: Fast Hashing
	Based on Keccak-p", Applied Cryptography and Network		Based on Keccak-p", Applied Cryptography and Network
	Security (ACNS 2018), Lecture Notes in Computer Science,		Security (ACNS 2018), Lecture Notes in Computer Science,
	vol. 10892, pp. 400-418, DOI 10.1007/978-3-319-93387-0_21,		vol. 10892, pp. 400-418, DOI 10.1007/978-3-319-93387-0_21,
	June 2018, <https://link.springer.com/		June 2018, <https://link.springer.com/
	chapter/10.1007/978-3-319-93387-0_21>.		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] Bertoni, G., Daemen, J., Peeters, M., and G. Van Assche,
	"Sakura: a Flexible Coding for Tree Hashing", Applied		"Sakura: a Flexible Coding for Tree Hashing", Applied
	Cryptography and Network Security (ACNS 2014), Lecture		Cryptography and Network Security (ACNS 2014), Lecture
	Notes in Computer Science, vol. 8479, pp. 217-234,		Notes in Computer Science, vol. 8479, pp. 217-234,
	DOI 10.1007/978-3-319-07536-5_14, 2014,		DOI 10.1007/978-3-319-07536-5_14, 2014,
	<https://link.springer.com/		<https://link.springer.com/
	chapter/10.1007/978-3-319-07536-5_14>.		chapter/10.1007/978-3-319-07536-5_14>.
	[KECCAK_CRYPTANALYSIS]		[TURBOSHAKE]
	Keccak Team, "Summary of Third-party cryptanalysis of		Bertoni, G., Daemen, J., Hoffert, S., Peeters, M., Van
	Keccak", <https://www.keccak.team/third_party.html>.		Assche, G., Van Keer, R., and B. Viguier, "TurboSHAKE",
			Cryptology ePrint Archive, Paper 2023/342, March 2023,
	[XKCP] "eXtended Keccak Code Package", December 2022,		<http://eprint.iacr.org/2023/342>.
	<https://github.com/XKCP/XKCP>.
	[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>.
	[FIPS180] NIST, "Secure Hash Standard", NIST FIPS 180-4,
	DOI 10.6028/NIST.FIPS.180-4, August 2015,
	<https://nvlpubs.nist.gov/nistpubs/FIPS/
	NIST.FIPS.180-4.pdf>.
	[FIPS198] NIST, "The Keyed-Hash Message Authentication Code (HMAC)",		[XKCP] "eXtended Keccak Code Package", commit 64404bee, December
	NIST FIPS 198-1, DOI 10.6028/NIST.FIPS.198-1, July 2008,		2022, <https://github.com/XKCP/XKCP>.
	<https://nvlpubs.nist.gov/nistpubs/FIPS/
	NIST.FIPS.198-1.pdf>.
	Appendix A. Pseudocode		Appendix A. Pseudocode
	The subsections 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]
	skipping to change at line 1246 ¶		skipping to change at line 1247 ¶
	if |S| <= 8192		if |S| <= 8192
	return TurboSHAKE128(S, `07`, outputByteLen)		return TurboSHAKE128(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 = TurboSHAKE128(S[offset : offset + blockSize], `0B`, 32)		CV = TurboSHAKE128(S[offset : offset+blockSize], `0B`, 32)
	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 TurboSHAKE128(FinalNode, `06`, outputByteLen)		return TurboSHAKE128(FinalNode, `06`, outputByteLen)
	end		end
	A.5. KT256		A.5. KT256
	skipping to change at line 1271 ¶		skipping to change at line 1272 ¶
	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
End of changes. 22 change blocks.
	70 lines changed or deleted		71 lines changed or added
This html diff was produced by rfcdiff 1.48.