Subject: Re: [Crypto-panel] Request for review: draft-irtf-cfrg-kangarootwelve-02

From: Alexey Melnikov <[email-masked]>
Date: Tue, 14 Jul 2020 15:53:29 +0100

Dear Crypto Panel members,

On 19/06/2020 18:01, Alexey Melnikov wrote:
> Dear Crypto Panel members,
>
> Nick, Stanislav and I would like to ask Crypto Review Panel members 
> for an extra review of 
> <https://datatracker.ietf.org/doc/draft-irtf-cfrg-kangarootwelve/?include_text=1> 
> ("KangarooTwelve").

Any other volunteers?

Thank you,

Alexey

>
>
> Jean-Philippe Aumasson has made an excellent review of -01. 
> Jean-Philippe, can I ask you to double check that your comments were 
> addressed in -02?
>
>
>
> Thank you,
>
> Alexey (on behalf of chairs)
>
> _______________________________________________
> Crypto-panel mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/crypto-panel

---

From: Thomas Pornin <[email-masked]>
Date: Tue, 14 Jul 2020 15:11:29 +0000

I can make a review.

Thomas

On 2020-07-14, 10:54, "Crypto-panel on behalf of Alexey Melnikov" <[email-masked] on behalf of [email-masked]> wrote:

    On 19/06/2020 18:01, Alexey Melnikov wrote:
    > <https://gbr01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-irtf-cfrg-kangarootwelve%2F%3Finclude_text%3D1&amp;data=02%7C01%7Cthomas.pornin%40nccgroup.com%7C3c823fbe95dd4576780e08d82805cf99%7Ca41111be486b45f68bd0ee01a62f368e%7C0%7C0%7C637303352719553314&amp;sdata=fWkqX5Z6qvVe%2BcUK59okL%2FIkbipkDkBpaD3U%2BPXEoPU%3D&amp;reserved=0> 
    > ("KangarooTwelve").
    
    Any other volunteers?
    
    Thank you,
    
    Alexey
    
    > https://gbr01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.irtf.org%2Fmailman%2Flistinfo%2Fcrypto-panel&amp;data=02%7C01%7Cthomas.pornin%40nccgroup.com%7C3c823fbe95dd4576780e08d82805cf99%7Ca41111be486b45f68bd0ee01a62f368e%7C0%7C0%7C637303352719553314&amp;sdata=0INP7miyc3y4LWTLgBPW3CoiYav8m4zaicWhPgi87vs%3D&amp;reserved=0
    
    _______________________________________________
    Crypto-panel mailing list
    [email-masked]
    https://gbr01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.irtf.org%2Fmailman%2Flistinfo%2Fcrypto-panel&amp;data=02%7C01%7Cthomas.pornin%40nccgroup.com%7C3c823fbe95dd4576780e08d82805cf99%7Ca41111be486b45f68bd0ee01a62f368e%7C0%7C0%7C637303352719553314&amp;sdata=0INP7miyc3y4LWTLgBPW3CoiYav8m4zaicWhPgi87vs%3D&amp;reserved=0

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 14 Jul 2020 16:13:18 +0100

> I can make a review.
Thank you Thomas, much appreciated!

---

From: Thomas Pornin <[email-masked]>
Date: Fri, 17 Jul 2020 21:57:01 +0000

Here is my review of draft-irtf-cfrg-kangarootwelve-02:

General comments:

The function is well described. The specification is not self-contained

since it relies on FIPS 202, but that's not a problem in my opinion (there

already are other RFCs that reference FIPS 202).

The function already exists and is specified in a note published on

eprint since 2016, so there is no point in changing it now; this is an

RFC that describes an existing situation, not one that introduces new

stuff (otherwise, I would insist, for aesthetical reasons, on making

length_encode() use little-endian instead of the current big-endian).

Some poor soul, somewhere, will want to make a MAC out of K12 and will

try to use it in HMAC. This is probably not a very good idea, though

it won't be weak. HMAC requires knowledge of the "block size" of the

algorithm, so that block size should be specified somewhere. Intuitively,

I suppose the "block size" is 168 bytes, but it would be better to state

it explicitly somewhere.

Also, some guidance about a better way to turn K12 into a MAC would be

helpful. Normally, a simple K12(key || data) would be enough, provided

that the concatenation of 'key' and 'data' is unambiguous. It is

tempting to use the key as customization string, but then, you do not

have a customization string anymore. A related question is whether the

MAC output length should be part of the input/customization string.

Particular comments:

page 2: "splits the input message in fragments" -> "splits ... into fragments"

(also page 3)

page 3: "does not have overhead": this is a bold statement. What is meant

here is that the tree hashing mode of K12 does not introduce _additional_

overhead (due to the tree hashing mode) compared with, say, SHAKE; but

there remains the elementary overhead which makes it so that, for instance,

hashing 10 bytes is not less expensive than hashing 120 bytes.

Speaking of overhead, it may be worth pointing out that the tree mode

implies maintaining two separate Keccak contexts (at least for inputs

longer than 8192 bytes), hence double the RAM usage; this may matter

for constrained embedded devices (i.e. low-end smartcards and

microcontrollers, where 200 bytes of RAM are a lot).

page 4: "from n to m exclusive" is a bit confusing since byte at index m

is excluded, but byte at index n is included. Maybe: "selection of bytes from

index n (inclusive) to m (exclusive)"? Also say somewhere that the first

byte of a string has index 0 (i.e. this is C/Rust, not Pascal).

page 4: "x**y denotes x multiplied by itself y times" -> this would

actually be x**(y+1) (if you multiply x by itself _once_, you get x*x).

page 4: "the number of output bytes requested" -> this lacks a verb;

probably: "is the requested number of output bytes"

page 5: "First the message is padded with zeroes to the closest multiple of

168 bytes.  Then a byte `80` is XORed to the last byte of the padded

message.  and the resulting string is split into a sequence of 168-byte

blocks."

-> This could be made clearer, first to indicate that it is the length,

in bytes, of the padded message which is to be a multiple of 168; also,

that the "closest" is really a rounding-up (e.g. with a 169-byte input,

we really need to append 167 other bytes, even though 168 is arguably

much closer to 169 than 336). There should be an explicit specification

about what to do if the input size already has a size multiple of 168:

should we add 168 extra bytes of value zero, or none at all? Note that,

in the latter case, there must be a special case for an input of length

0: if the padded input consists of no byte at all, then it becomes

difficult to XOR 0x80 into "the last byte".

(Three paragraphs later, we learn that the input length is at least

1 byte, which avoids any issue related to a zero-length input; this

should probably be explained a bit earlier in the text.)

page 11: "against all attacks" (end of first paragraph of section 5):

this lacks a final dot.

Thomas

On 2020-07-14, 11:11, "Thomas Pornin" <[email-masked]> wrote:

    I can make a review.

    Thomas

        Any other volunteers?

        Thank you,

        Alexey

        [email-masked]