Authors,
While reviewing this document during AUTH48, please resolve (as necessary) the
following questions, which are also in the source file.
1) <!--[rfced] Please ensure that the guidelines listed in Section 2.1 of RFC
5743 have been
adhered to in this document. -->
2) <!--[rfced] Should the document's short title, which can be seen in the
header
of the PDF output, include "TurboSHAKE" to reflect the full document title?
Original:
KangarooTwelve
Perhaps:
KangarooTwelve and TurboSHAKE
-->
3) <!--[rfced] May we clarify that "similarly to the SHAKE's" is referring
to the SHAKE's security?
Original:
Similarly to the SHAKE's, it proposes two security strengths:
128 bits for TurboSHAKE128 and 256 bits for TurboSHAKE256.
Perhaps:
Similarly to the SHAKE's security, it proposes two security strengths:
128 bits for TurboSHAKE128 and 256 bits for TurboSHAKE256.
-->
4) <!--[rfced] Section 1. We rephrased the following sentence for
consistency with the other sentences in the list and to avoid
using citations as adjectives. If it changes the intended
meaning, please let us know.
Original:
* Unlike any [FIPS202] and [SP800-185] functions but ParallelHash,
KT128 and KT256 exploit available parallelism.
Perhaps:
* Unlike any functions in [FIPS202] and [SP800-185] except for
ParallelHash, KT128 and KT256 exploit available parallelism.
-->
5) <!--[rfced] Section 2.1. We rephrased this text to match similar text
in the first paragraph of Section 3.1. If it changes the intended
meaning, please let us know.
Original:
An instance of TurboSHAKE takes as input parameters a byte-string M,
an OPTIONAL byte D and a positive integer L where
Current:
A TurboSHAKE instance takes a byte string M, an OPTIONAL byte D, and
a positive integer L as input parameters, where:
-->
6) <!--[rfced] Please clarify "for any distinct values D1 and D2". Is the
current text correct or is the intended meaning "for distinct
values D1 and D2" (i.e., without "any")?
Original:
Specifically, for any distinct values D1 and D2, TurboSHAKE(M, D1,
L1) and TurboSHAKE(M, D2, L2) yield independent hashes of M.
Perhaps:
Specifically, for distinct values D1 and D2, TurboSHAKE(M, D1,
L1) and TurboSHAKE(M, D2, L2) yield independent hashes of M.
-->
7) <!--[rfced] Is the space before the colon in "l_e( x ) :" intentional,
or may we update the text as follows to avoid the added space?
Current:
The following figure illustrates the computation flow of KT128
for |S| > 8192 bytes and where TurboSHAKE128 and length_encode( x )
are abbreviated respectively as TSHK128 and l_e( x ) :
Perhaps:
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:
-->
8) <!--[rfced] In the "COSE Algorithms" registry at
<https://www.iana.org/assignments/cose>, IANA lists the values in
descending order. Should Table 3 be ordered to match the IANA
registry (e.g., list "KT256 | -264 " first and "TurboSHAKE128 |
-261" last)?
Also, may we include the "Recommended" column in Table 3 to match
the IANA registry or include the following sentence in the lead-in
text? Please let us know which option is preferred.
Current:
In the COSE Algorithms "COSE Algorithms" registry, IANA has added
the following entries for TurboSHAKE and KangarooTwelve:
Perhaps:
In the COSE Algorithms "COSE Algorithms" registry, IANA has added
the following entries for TurboSHAKE and KangarooTwelve. For each
entry, the "Recommended" column contains "No".
-->
9) <!--[rfced] To improve the readability of "the output L MUST be chosen
long enough", may we update it to "the chose L output MUST be long enough"?
Note that this phrasing occurs in two sentences.
Original:
To achieve 128-bit
security strength, the output L MUST be chosen long enough so that
there are no generic attacks that violate 128-bit security.
...
To achieve 256-bit security strength, the output L MUST be chosen long
enough so that there are no generic attacks that violate 256-bit
security.
Perhaps:
To achieve 128-bit
security strength, the chosen L output MUST be long enough so that
there are no generic attacks that violate 128-bit security.
...
To achieve 256-bit security strength, the chosen L output MUST be long
enough so that there are no generic attacks that violate 256-bit
security.
-->
10) <!--[rfced] As the first sentence is not a full sentence, may we combine
the two sentences below into one sentence?
Original:
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.
Perhaps:
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.
-->
11) <!-- [rfced] References
a) Would you like the references to be alphabetized or left in their
current order?
b) We note that the original [KT] reference entry contained two URL
strings.
The first URL is to a pre-print version of this article available from
the Cryptology ePrint Archive with the most recent version being added
in May 2018: http://eprint.iacr.org/2016/770.pdf.
The other URL is to the published conference paper with a date of June
2018: https://link.springer.com/chapter/10.1007/978-3-319-93387-0_21.
We have modified this reference to use the Springer Link URL as this
appears to be the most recently published version that also includes
a DOI. Please review and let us know if you have any objections.
Original:
[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.
Current:
[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/978-3-319-93387-0_21,
June 2018, <https://link.springer.com/
chapter/10.1007/978-3-319-93387-0_21>.
c) We note that the original [SAKURA] reference entry contained two URL
strings.
The first URL is to a pre-print version of this article available from
the Cryptology ePrint Archive with the most recent version being added
in April 2014: https://eprint.iacr.org/2013/231.pdf.
The other URL is to the published conference paper with a date of
2014: https://link.springer.com/chapter/10.1007/978-3-319-07536-5_14.
We have modified this reference to use the Springer Link URL as this
appears to be the most recently published version that also includes
a DOI. Please review and let us know if you have any objections.
Original:
[SAKURA] Bertoni, G., Daemen, J., Peeters, M., and G. Van Assche,
"Sakura: a flexible coding for tree hashing", WWW
https://link.springer.com/
chapter/10.1007/978-3-319-07536-5_14,
WWW http://eprint.iacr.org/2013/231.pdf, June 2014.
Current:
[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/978-3-319-07536-5_14, 2014,
<https://link.springer.com/
chapter/10.1007/978-3-319-07536-5_14>.
d) Since this reference is to a GitHub repository, please
provide a commit hash in accordance with Part 2 of the RFC Style
Guide: https://www.rfc-editor.org/styleguide/part2/#ref_repo.
[XKCP] "eXtended Keccak Code Package", December 2022,
<https://github.com/XKCP/XKCP>.
-->
12) <!--[rfced] The following lines are 1 character over the 72-character
limit. Please let us know how you would like to adjust the
lines/spacing.
Appendix A.4:
CV = TurboSHAKE128(S[offset : offset + blockSize], `0B`, 32)
Appendix A.5:
CV = TurboSHAKE256(S[offset : offset + blockSize], `0B`, 64)
-->
13) <!--[rfced] Throughout the text, the following terminology appears to be
used
inconsistently. Please review these occurrences and let us know if/how they
may be made consistent.
Chaining Value vs. chaining value
Customization string vs. customization string
Message vs. message
-->
14) <!-- [rfced] Abbreviations
a) FYI - We have added expansions for the following abbreviations
per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
expansion in the document carefully to ensure correctness.
Elliptic Curve Diffie-Hellman (ECDH)
Hashed Message Authentication Code (HMAC)
Original Dialog Identifier (ODI)
single instruction, multiple data (SIMD)
b) FYI: We added a hyphen to the expansion of "XOF" per [FIPS202] and
the NIST glossary.
eXtendable Output Functions -> eXtendable-Output Functions
-->
15) <!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed.
Note that our script did not flag any words in particular, but this should
still
be reviewed as a best practice.
-->
Thank you.
Alanna Paloma and Karen Moore
RFC Production Center
On Sep 15, 2025, at 6:17 PM, RFC Editor via auth48archive
<[email protected]> wrote:
*****IMPORTANT*****
Updated 2025/09/15
RFC Author(s):
--------------
Instructions for Completing AUTH48
Your document has now entered AUTH48. Once it has been reviewed and
approved by you and all coauthors, it will be published as an RFC.
If an author is no longer available, there are several remedies
available as listed in the FAQ (https://www.rfc-editor.org/faq/).
You and you coauthors are responsible for engaging other parties
(e.g., Contributors or Working Group) as necessary before providing
your approval.
Planning your review
---------------------
Please review the following aspects of your document:
* RFC Editor questions
Please review and resolve any questions raised by the RFC Editor
that have been included in the XML file as comments marked as
follows:
<!-- [rfced] ... -->
These questions will also be sent in a subsequent email.
* Changes submitted by coauthors
Please ensure that you review any changes submitted by your
coauthors. We assume that if you do not speak up that you
agree to changes submitted by your coauthors.
* Content
Please review the full content of the document, as this cannot
change once the RFC is published. Please pay particular attention to:
- IANA considerations updates (if applicable)
- contact information
- references
* Copyright notices and legends
Please review the copyright notice and legends as defined in
RFC 5378 and the Trust Legal Provisions
(TLP – https://trustee.ietf.org/license-info).
* Semantic markup
Please review the markup in the XML file to ensure that elements of
content are correctly tagged. For example, ensure that <sourcecode>
and <artwork> are set correctly. See details at
<https://authors.ietf.org/rfcxml-vocabulary>.
* Formatted output
Please review the PDF, HTML, and TXT files to ensure that the
formatted output, as generated from the markup in the XML file, is
reasonable. Please note that the TXT will have formatting
limitations compared to the PDF and HTML.
Submitting changes
------------------
To submit changes, please reply to this email using ‘REPLY ALL’ as all
the parties CCed on this message need to see your changes. The parties
include:
* your coauthors
* [email protected] (the RPC team)
* other document participants, depending on the stream (e.g.,
IETF Stream participants are your working group chairs, the
responsible ADs, and the document shepherd).
* [email protected], which is a new archival mailing list
to preserve AUTH48 conversations; it is not an active discussion
list:
* More info:
https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
* The archive itself:
https://mailarchive.ietf.org/arch/browse/auth48archive/
* Note: If only absolutely necessary, you may temporarily opt out
of the archiving of messages (e.g., to discuss a sensitive matter).
If needed, please add a note at the top of the message that you
have dropped the address. When the discussion is concluded,
[email protected] will be re-added to the CC list and
its addition will be noted at the top of the message.
You may submit your changes in one of two ways:
An update to the provided XML file
— OR —
An explicit list of changes in this format
Section # (or indicate Global)
OLD:
old text
NEW:
new text
You do not need to reply with both an updated XML file and an explicit
list of changes, as either form is sufficient.
We will ask a stream manager to review and approve any changes that seem
beyond editorial in nature, e.g., addition of new text, deletion of text,
and technical changes. Information about stream managers can be found in
the FAQ. Editorial changes do not require approval from a stream manager.
Approving for publication
--------------------------
To approve your RFC for publication, please reply to this email stating
that you approve this RFC for publication. Please use ‘REPLY ALL’,
as all the parties CCed on this message need to see your approval.
Files
-----
The files are available here:
https://www.rfc-editor.org/authors/rfc9861.xml
https://www.rfc-editor.org/authors/rfc9861.html
https://www.rfc-editor.org/authors/rfc9861.pdf
https://www.rfc-editor.org/authors/rfc9861.txt
Diff file of the text:
https://www.rfc-editor.org/authors/rfc9861-diff.html
https://www.rfc-editor.org/authors/rfc9861-rfcdiff.html (side by side)
Diff of the XML:
https://www.rfc-editor.org/authors/rfc9861-xmldiff1.html
Tracking progress
-----------------
The details of the AUTH48 status of your document are here:
https://www.rfc-editor.org/auth48/rfc9861
Please let us know if you have any questions.
Thank you for your cooperation,
RFC Editor
--------------------------------------
RFC9861 (draft-irtf-cfrg-kangarootwelve-17)
Title : KangarooTwelve and TurboSHAKE
Author(s) : B. Viguier, D. Wong, Ed., G. Assche, Ed., Q. Dang, Ed., J.
Daemen, Ed.
WG Chair(s) :
Area Director(s) :
--
auth48archive mailing list -- [email protected]
To unsubscribe send an email to [email protected]
--
auth48archive mailing list -- [email protected]
To unsubscribe send an email to [email protected]
