[CFRG] Re: KangarooTwelve Review

[Gilles VAN ASSCHE <[e-mail]>]

Hi Colin, hi Jonathan,

Thanks for your feedback.

We will address these comments in the coming two weeks (some of us are on holiday next week).

Kind regards,
Gilles, for the authors




ST Restricted

From: Colin Perkins <[e-mail]>
Sent: jeudi 24 octobre 2024 17:23
To: [e-mail]
Cc: The IRSG <[e-mail]>; [e-mail]; [e-mail]
Subject: Fwd: KangarooTwelve Review


Hi,

Thanks, Jonathan, for the review.

Authors - please consider this the IRSG review of draft-irtf-cfrg-kangarootwelve. My reading is that it would be useful to make some clarifications to the draft to address these comments prior to the IRSG approval ballot, but that the changes should hopefully be minor.

Regards,
Colin


Forwarded message:

From: Jonathan Hoyland <[e-mail]<mailto:[e-mail]>>
To: Colin Perkins <[e-mail]<mailto:[e-mail]>>
Subject: KangarooTwelve Review
Date: Wed, 23 Oct 2024 17:48:49 +0100
Hi Colin,

Unfortunately,  I'm going to be offline for the next few days, so just to prevent unnecessary further delays, I attach my review below. Please could you forward it to the appropriate places?

Regards,

Jonathan

----

Hi All,

I have reviewed the KangarooTwelve draft-14 and I think it's ready for publication, modulo a few nits / places where it's hard to read.

Comments below,

Regards,

Jonathan

```
Halving the number of rounds compared to the original SHAKE functions makes TurboSHAKE roughly twice faster.
```
--> roughly two times faster.


```
The TurboSHAKE functions produce output at the same rate as they process input, whereas SHA-256 and SHA-512 produce output half as fast as they process input.
```
I don't really understand what this means in this context. SHA-256 has a fixed length output, so producing output would seem to be an $O(1)$ function in the length of the input?
Does this mean that the SHA functions hold an increasing amount of internal state as they process bigger inputs?


```
Similarly to SHAKE128, TurboSHAKE128 is a sponge function calling this permutation KP with a rate of 168 bytes or 1344 bits.
```
What does rate mean?
It hasn't been defined yet in the document, and I was confused by its one earlier occurrence.


```
Similarly to SHAKE128, TurboSHAKE128 is a sponge function calling this permutation KP with a rate of 168 bytes or 1344 bits. It follows that TurboSHAKE128 has a capacity of 1600 - 1344 = 256 bits 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 bytes.
```
These numbers and calculations seemingly come out of nowhere. If the reader isn't intimately familiar with Keccak or SHA-3 then these calculations are just magic.
Capacity also hasn't been defined yet.

```
Non-multiple of 168-bytes-length M' are padded with zeroes to the next multiple of 168 bytes while M' with length multiple of 168 bytes are kept as 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. If $M'$ is already a multiple of 168 bytes then no padding is added.

```
In the squeezing phase output is formed by taking the first 168 bytes of the state, repeated as many times as necessary until outputByteLen bytes are obtained, interleaved with the application of KP to the state.
```
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 many times as is necessary.

```
TurboSHAKE256 performs the same steps but makes use of 136-byte blocks with respect to padding, absorbing, and squeezing phases.
```
[...] with respect to the padding [...]

```
Note that an implementation MAY propose an interface with input and/or output incrementality as specified in [Section 2.1](https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-kangarootwelve-14#TurboSHAKE_Interface).
```
[...] with the input and/or output provided incrementally as specified [...]

```
Consequently, in an implementation that has to protect the HopMAC key against SCA only the outer call does need protection, and this amounts to a single execution of the underlying permutation.
```

Is this obviously true? Couldn't the HopMAC key be longer than 8192 bytes, requiring a second invocation?

Is HopMAC defined elsewhere, and this is just a reference to it, or does this document define HopMAC?