Greetings, We do not believe we have heard from you regarding this document's readiness for publication. Please review our previous messages describing the AUTH48 process and containing any document-specific questions we may have had.
We will wait to hear from you before continuing with the publication process. The AUTH48 status page for this document is located here: https://www.rfc-editor.org/auth48/rfc9861 Thank you, Alanna Paloma RFC Production Center > On Sep 15, 2025, at 6:20 PM, [email protected] wrote: > > 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]
