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

[Benoît Viguier <[e-mail]>]

Dear Thomas, Dear Alexey, Dear Crypto Panel members,

We would like to thank you for your time into reviewing our draft
and providing us with your constructive comments.

We apologize for the delays (corona & vacations...) and provide you here
with
our modifications to the draft:
https://github.com/cfrg/draft-irtf-cfrg-kangarootwelve/commit/70eff423aa57e9e34121951da2764b5ed73df988
.

On 7/17/20 11:57 PM, Thomas Pornin wrote:
>
> 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).
>
Additionally we added links to the publications at the ACNS
conference 2014 and 2018 for KangarooTwelve and the Sakura tree hashing.
>
> 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.
>
We added a paragraph on that subject in the Security Consideration section.
We present HopMAC(K, M, C, L) = K12( Key, K12(M, C, 32), L) to describe
a way to build a MAC from K12.

> Particular comments:
>
>  
>
> page 2: "splits the input message in fragments" -> "splits ... into
> fragments"
>
> (also page 3)
>
Edited.
>
>  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).
>
Edited.
>
> 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).
>
Edited.
>
> page 4: "the number of output bytes requested" -> this lacks a verb;
>
> probably: "is the requested number of output bytes"
>
Edited.
>
> 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".
>
We clarify that the length of the F function is positive.
This resolve the problem of inputs consisting of no bytes.
In the definition of KangarooTwelve in section 2.2, there are no calls to F
with input of length 0.

We clarify the rounding up to the next multiple of 168.

> (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.)
>
Edited.
>
>  page 11: "against all attacks" (end of first paragraph of section 5):
>
> this lacks a final dot.
>
Edited.
>
>  
>
> Thomas
>
We are open to any additional feedback.

-- 
Kind regards,

Benoît Viguier
Software Engineer - PhD Student | Cryptography & Formal Methods
Radboud University | Mercator 1, Toernooiveld 212
6525 EC Nijmegen, the Netherlands | www.viguier.nl