[CFRG] Re: IRTF Chair review of draft-irtf-cfrg-kangarootwelve

[Colin Perkins <[e-mail]>]

Hi,

Thanks, all - this addresses my comments. I'll move the draft forward to the IRSG review stage.

Colin



On 9 May 2024, at 15:06, Gilles VAN ASSCHE wrote:

> Dear Colin,
>
> Thanks for your review. We have prepared a new draft (revision 14) addressing your comments. Please see below for some answers.
>
> Kind regards,
> Benoît, Joan and Gilles
>
>> Following RFC 5743, Section 2.1, the Abstract needs to include a statement that the draft is a product of the Crypto Forum Research Group. Can you please add this.
>>
>> Following RFC 5743, Section 2,1, the Introduction also needs a paragraph describing the level of support for publication, the breadth of review received, and a statement that the draft is a not an IETF product and not a standard. This might be as simple as adding a statement that "This document represents the consensus of the Crypto Forum Research Group (CFRG). This document is not an IETF product and is not a standard."
>>
>> Section 1.1 references RFC 2119. Since the text also uses lower-case "should", "must", etc., would it be appropriate to also reference RFC 8174?
>
> We agree with these comments and addressed them.
>
>> Section 4 says "SHOULD use a HASH-then-MAC construction" and "recommends a method called HopMAC". Would it be appropriate for the draft to say why this is a SHOULD, rather than a MUST, and to describe when the recommended approach might not be suitable?
>
> We replaced the SHOULD with a MAY, as there are many other choices for generating MAC functions.
>
>> Section 5 contains test vectors. Have these been machine checked against a reference implementation to ensure they're correct? Similarly, what checks have been done to ensure the pseudo-code in the appendix is correct and matches the prose description of the algorithm? I believe that both are correct, but it's easy to introduce typos or other mistakes in such a long block of code and set of test vectors.
>
> We generated the test vectors using Python code [1] that is very close to the pseudo-code in the appendix. We also tested the test vectors against implementations of TurboSHAKE and KangarooTwelve in the XKCP and in the CIRCL library.
>
> Following your comment, we improved the Python code to make it match the pseudo-code line per line. This made us discover a typo in the pseudo-code that computes Keccak-p[1600, 12], that we corrected in version 14 of the draft.
>
> [1] https://github.com/cfrg/draft-irtf-cfrg-kangarootwelve/tree/master/py