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

From: Gilles VAN ASSCHE <[email-masked]>
Date: Mon, 5 Oct 2020 08:03:22 +0000

Dear Alexey,

Thanks to Jean-Philippe and Thomas for their comments.

We think all comments have been addressed. (Maybe, Jean-Philippe could you confirm?) If indeed the case, can you help to move the document forward ?

Thanks & kind regards,
Benoît, David, Gilles, Joan and Quynh

From: Thomas Pornin <[email-masked]>
Sent: Monday, 21 September 2020 16:18
To: Benoît Viguier <[email-masked]>; Alexey Melnikov <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: EXTERNAL: Re: [Crypto-panel] Request for review: draft-irtf-cfrg-kangarootwelve-02

I am not in a good position to make comments on delays, since I also let this email sleep for three weeks...

Your changes look good to me.

I like the idea that the bulk of the data processing in HopMAC has no dependency on the key; it has indeed strong benefits with regard to side channel attacks. Of course, it unavoidably implies that HopMAC relies on the collision resistance of the keyless hash function. In the aftermath of the MD5 and SHA-1 attacks (in the 2000s), there has been a trend of shunning collision resistance, and insisting on using only (second-)preimage resistance; that's how, for instance, Ed25519 signatures in "pure" mode insist on generating the challenge as H(pkey+R+message) and not H(pkey+R+H(message)). This trend implies some practical limitations (e.g. "pure" Ed25519 signatures make it much more difficult to process X.509 certificates in memory-constrained environments). I think your choice in HopMAC is a better trade-off; keyless processing of the bulk of the data has tangible practical benefits, and if K12 is not collision-resistant then the foundation of its other security properties becomes quite flaky.

Thomas

From: Benoît Viguier <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, September 1, 2020 at 10:38
To: Thomas Pornin <[email-masked]<mailto:[email-masked]>>, Alexey Melnikov <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: EXTERNAL: Re: [Crypto-panel] Request for review: draft-irtf-cfrg-kangarootwelve-02

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<https://gbr01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcfrg%2Fdraft-irtf-cfrg-kangarootwelve%2Fcommit%2F70eff423aa57e9e34121951da2764b5ed73df988&data=02%7C01%7Cthomas.pornin%40nccgroup.com%7Ce1e346d59c784399ad6b08d84e84a3e7%7Ca41111be486b45f68bd0ee01a62f368e%7C0%7C0%7C637345678881062176&sdata=s4Pc12tumBCNxqhLGREPxcpTvDU%2F5eyV6awv9a9fQmE%3D&reserved=0> .
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<https://gbr01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.viguier.nl%2F&data=02%7C01%7Cthomas.pornin%40nccgroup.com%7Ce1e346d59c784399ad6b08d84e84a3e7%7Ca41111be486b45f68bd0ee01a62f368e%7C0%7C0%7C637345678881067157&sdata=bxZRTB5IWIUpqrBgVBRrXvguBjmBgJ%2Fl9wtkc09aAPo%3D&reserved=0>

---

From: "Stanislav V. Smyshlyaev" <[email-masked]>
Date: Mon, 12 Oct 2020 16:58:53 +0300

Dear Jean-Philippe,

>> (Maybe, Jean-Philippe could you confirm?
Could you please confirm that you are happy with the changes?..

Regards,
Stanislav

On Mon, 5 Oct 2020 at 11:04, Gilles VAN ASSCHE <[email-masked]>
wrote:

> We think all comments have been addressed. (Maybe, Jean-Philippe could you
> confirm?) If indeed the case, can you help to move the document forward ?
>
>
>
> Thanks & kind regards,
>
> *From:* Thomas Pornin <[email-masked]>
> *Sent:* Monday, 21 September 2020 16:18
> *To:* Benoît Viguier <[email-masked]>; Alexey Melnikov <
> [email-masked]>; [email-masked];
> [email-masked]
> *Subject:* Re: EXTERNAL: Re: [Crypto-panel] Request for review:
> draft-irtf-cfrg-kangarootwelve-02
>
>
>
> I like the idea that the bulk of the data processing in HopMAC has no
> dependency on the key; it has indeed strong benefits with regard to side
> channel attacks. Of course, it unavoidably implies that HopMAC relies on
> the collision resistance of the keyless hash function. In the aftermath of
> the MD5 and SHA-1 attacks (in the 2000s), there has been a trend of
> shunning collision resistance, and insisting on using only
> (second-)preimage resistance; that's how, for instance, Ed25519 signatures
> in "pure" mode insist on generating the challenge as H(pkey+R+message) and
> not H(pkey+R+H(message)). This trend implies some practical limitations
> (e.g. "pure" Ed25519 signatures make it much more difficult to process
> X.509 certificates in memory-constrained environments). I think your choice
> in HopMAC is a better trade-off; keyless processing of the bulk of the data
> has tangible practical benefits, and if K12 is not collision-resistant then
> the foundation of its other security properties becomes quite flaky.
>
>
>
> Thomas
>
>
>
> *From: *Benoît Viguier <[email-masked]>
> *Date: *Tuesday, September 1, 2020 at 10:38
> *To: *Thomas Pornin <[email-masked]>, Alexey Melnikov <
> [email-masked]>, "[email-masked]" <
> [email-masked]>, "[email-masked]" <
> [email-masked]>
> *Subject: *Re: EXTERNAL: Re: [Crypto-panel] Request for review:
> draft-irtf-cfrg-kangarootwelve-02
>
>
>
> our modifications to the draft:
> https://github.com/cfrg/draft-irtf-cfrg-kangarootwelve/commit/70eff423aa57e9e34121951da2764b5ed73df988
> <https://gbr01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcfrg%2Fdraft-irtf-cfrg-kangarootwelve%2Fcommit%2F70eff423aa57e9e34121951da2764b5ed73df988&data=02%7C01%7Cthomas.pornin%40nccgroup.com%7Ce1e346d59c784399ad6b08d84e84a3e7%7Ca41111be486b45f68bd0ee01a62f368e%7C0%7C0%7C637345678881062176&sdata=s4Pc12tumBCNxqhLGREPxcpTvDU%2F5eyV6awv9a9fQmE%3D&reserved=0>
> .
>
> 6525 EC Nijmegen, the Netherlands | www.viguier.nl <https://gbr01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.viguier.nl%2F&data=02%7C01%7Cthomas.pornin%40nccgroup.com%7Ce1e346d59c784399ad6b08d84e84a3e7%7Ca41111be486b45f68bd0ee01a62f368e%7C0%7C0%7C637345678881067157&sdata=bxZRTB5IWIUpqrBgVBRrXvguBjmBgJ%2Fl9wtkc09aAPo%3D&reserved=0>
>
> _______________________________________________
> Crypto-panel mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/crypto-panel
>

---

From: Jean-Philippe Aumasson <[email-masked]>
Date: Mon, 12 Oct 2020 16:02:06 +0200

Yes looks good to me, thanks for asking!

On Mon, Oct 12, 2020 at 3:56 PM Stanislav V. Smyshlyaev <[email-masked]>
wrote:

>> We think all comments have been addressed. (Maybe, Jean-Philippe could
>> you confirm?) If indeed the case, can you help to move the document forward
>> ?
>>
>>
>>
>> Thanks & kind regards,
>>

---

From: "Stanislav V. Smyshlyaev" <[email-masked]>
Date: Mon, 12 Oct 2020 17:06:15 +0300

Great, thanks a lot!