Subject: [Cfrg] RGLC on draft-irtf-cfrg-kangarootwelve-01

From: Alexey Melnikov <[email-masked]>
Date: Sun, 16 Feb 2020 11:16:21 +0000

Dear CFRG participants,

This message is starting 2 weeks RGLC on draft-irtf-cfrg-kangarootwelve-01 ("KangarooTwelve"), that will end on March 1st 2020. If you've read the document and think that it is ready (or not ready) for publication as an RFC, please send a message in reply to this email or directly to CFRG chairs ([email-masked]). If you have detailed comments, these would also be very helpful at this point.

Thank you,

Alexey, for CFRG chairs.

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 16 Feb 2020 14:53:18 +0000

Hiya,

On 16/02/2020 11:16, Alexey Melnikov wrote:
> Dear CFRG participants,
> 
> This message is starting 2 weeks RGLC on
> draft-irtf-cfrg-kangarootwelve-01 ("KangarooTwelve"), that will end
> on March 1st 2020. If you've read the document and think that it is
> ready (or not ready) for publication as an RFC, please send a message
> in reply to this email or directly to CFRG chairs
> ([email-masked]). If you have detailed comments, these would
> also be very helpful at this point.

I had my 1st read of this and think it needs a bit of
work, but am overall unclear if it ought be published
now. (I also looked back at the list archive messages
referring to k12.)

I don't think CFRG ought be publishing very novel
algorithm RFCs and am unclear how much study k12 has
gotten outside the author team. The main reference
given [1] has pointers to lots of work with titles that
mention reduced-round keccak but it's unclear (to me,
not having read 'em;-) how  relevant those are to k12.

[1] is also used as [KECCAK_CRYPTANALYSIS] in the draft
and is where the authors are pointing us to find
security analysis of k12. I don't think an author-
maintained web page like that is really good enough
as the key reference for an RFC like this.

I totally get why the authors would find that
easier/better, but that won't be true for a reader in
20 years time, so better to put in the precise
references now. That should also clarify the extent to
which those are about k12 (as defined here) and not
about something else.

I think the references really need fixing before this
ought be published. I'm not sure where the right line
ought be drawn in terms of maturity of an algorithm
before CFRG blesses it with an RFC. <4 years does seem
short, even if this is strongly based on keccak. (Hence
me being unsure overall.)

Separately, the draft could benefit from some guidance
as to when this is thought to be useful - presumably
that's when one wants a hash output that's >512 bits.
IIRC, there are other RFCs (forget numbers, sorry),
that describe how to get such outputs using standard
hash functions. If there are such RFCs, it'd be good
to reference those. Either way saying why and when this
is preferable to use of standard hash functions would
be good.

Other than the above, the draft seems clear (though
I didn't try implement) and many thanks for not
defining the usual pile of pointless variants/options:-)

Cheers,
S.

[1] https://keccak.team/third_party.html

> 
> 
> 
> Thank you,
> 
> Alexey, for CFRG chairs.
> 
> 
> 
> _______________________________________________ Cfrg mailing list 
> [email-masked] https://www.irtf.org/mailman/listinfo/cfrg
>

---

From: Benoît Viguier <[email-masked]>
Date: Tue, 18 Feb 2020 15:45:45 +0100

Dear Stephen,

Thank you for your comments on our draft!

Please find below some answers and comments.

> not having read 'em;-) how  relevant those are to k12.

Actually, all cryptanalysis of Keccak/SHA-3 is relevant to K12.
Cryptanalysis resources are scarce, we chose as an explicit design goal
to make K12 rely on cryptanalysis of Keccak/SHA-3.

To be more precise, K12 is made of two layers:

1) The inner function F. This layer relies on cryptanalysis. K12's F
function is exactly Keccak[r=1344, c=256] (as in SHAKE128) reduced to 12
rounds (no tweaks!). Hence, any reduced-round cryptanalysis on Keccak is
also a reduced round cryptanalysis of K12's F (provided the number of
rounds attacked is not higher than 12 of course).

2) The tree hashing over F. This layer is a mode on top of F that does
not introduce any vulnerability thanks to the use of Sakura coding
proven secure in the paper [Bertoni et al., ACNS 2014].

This reasoning is detailed and formalized in the paper [Bertoni et al.,
ACNS 2018], which is peer-reviewed.

> as the key reference for an RFC like this.

Good point indeed!

One option would be that we put all the references in the RFC. We are
not sure this is the right place for it, as we see an RFC more as
implementation guide rather than an analysis paper. For example:
https://tools.ietf.org/html/rfc7748 does not mention anything with
respect to the security of X25519 which is detailed in section 3 of
https://www.iacr.org/cryptodb/archive/2006/PKC/3351/3351.pdf.
Nevertheless, we are open to this option.

Another option would be to refer to [K12, Section 5]. In that section
attacks with the highest number of rounds are discussed and
corresponding paper are referred to. However with the possible
appearance of new cryptanalysis results, this section would become outdated.

> which those are about k12 (as defined here) and not
We agree with this, however Keccak cryptanalysis directly applies to K12.
> me being unsure overall.)
For us the maturity amounts to more than 4 years. Being SHA-3, Keccak is
a high-profile cryptanalysis target. As we did not tweak the round
function, K12 relies on sustained cryptanalysis since 2008.
> is preferable to use of standard hash functions would
The standard hash functions (SHA-1 and SHA-2) are subject to length
extension attacks. And in all cases, K12 will be faster than SHA-3. If
that makes it clearer, we could add a short guidance as to when the user
can benefit the most from K12. We could simply reuse the arguments from
these slides: https://benoit.viguier.nl/files/K12atMontreal.pdf
> defining the usual pile of pointless variants/options:-)

Thanks, yes, that was another design goal for K12.

-- 
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

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 18 Feb 2020 15:18:58 +0000

Hiya,

Coupla follow ups below...

> ACNS 2018], which is peer-reviewed.

Thanks. It sounds like referring to that section
of that paper would help so. (Your explanation there
helped me fwiw.)

> corresponding paper are referred to. 

Yep, that sounds good to me.

> However with the possible

Just to be clear - including the URL as an additional
reference as well seems like a good idea. It's only
depending on that as the main source that seems a bit
iffy.

> function, K12 relies on sustained cryptanalysis since 2008.

Ack. If nobody's gotten near breaking 12 rounds and
since you didn't tweak it, that does sound convincing
to me. Thanks.

> extension attacks.

Yep, I had a quick look and didn't find what I thought
I was remembering;-) It may be that what I was thinking
about was HKDF (RFC 5869), so let me ask it that way:
is there a clear benefit in using k12 instead of using
HKDF to get the output length wanted? If there is, and
it's possible to state that in a short paragraph, that
might be a useful addition. (While HKDF doesn't have
arbitrary output length, it can produce long enough
outputs for many uses I guess.)

Cheers,
S.

> And in all cases, K12 will be faster than SHA-3. If

---

From: Benoît Viguier <[email-masked]>
Date: Thu, 20 Feb 2020 12:37:04 +0100

Hi Stephen,

To answer your question:

-------------------------------------------------------------------------

K12 has the merit of being a simpler construction and can be used in
place of HKDF.

In the scope of IoT or embedded devices, another advantage of K12 when
its input contains a key is that it is easier to protect against DPA
than SHA-1 or SHA-2.

Kind Regards

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 20 Feb 2020 13:26:54 +0000

Hiya,

> outputs for many uses I guess.)

Fair enough. Doesn't seem like a compelling addition to
the document in the end, but happy to leave it to you
and others to figure if adding that is useful or not.

Cheers,
S.

PS: Just to be clear, the discussion has moved me from
an "unsure" state to where I think this is ok to publish
in an RFC.

---

From: "Stanislav V. Smyshlyaev" <[email-masked]>
Date: Sun, 23 Feb 2020 14:13:31 +0300

Dear CFRG,

With my chair's hat off, I support moving forward with the document after
taking into account the considerations provided by Jean-Philippe Aumasson
in his review on behalf of the Crypto Review Panel.

Regards,
Stanislav

On Thu, 20 Feb 2020 at 16:27, Stephen Farrell <[email-masked]>
wrote:

> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg
>

---

From: Dan Brown <[email-masked]>
Date: Mon, 24 Feb 2020 19:42:26 +0000

I have not studied this draft, so I do not oppose it, but I am quite puzzled by the motivation.

It may be too late now to ask for explanations that would unpuzzle (only) me: they were probably discussed during the call for adoption.  If so, please disregard the rest of the message.

***

Background:

My understanding, which I expect is simplistic, is that this (K12) is a fast variable length hash (XOF) which uses fewer rounds than the existing NIST XOF (or similar constructs).

For sake of argument, let us assume K12 is secure, and it has merit of being faster than some alternatives, especially NIST XOF.

General questions, with some details:

1.	CFRG or NIST?

Isn’t NIST also running a lightweight crypto (LWC) project?  Are some algorithms there even faster than Kangaroo12?

But CFRG decided to wait for NIST PQC, so why would CFRG try to race with NIST LWC?

I could guess that an answer is that NIST PQC is a matter of security, but NIST LWC is a matter of efficiency, so is more fair game for CFRG?  But maybe there’s a better answer.

2.	Too many solutions to the same problem?

The more options in a system, meaning solutions to a problem, in this case, variable-length hashing, has some downsides, such as adversaries negotiating the weakest option.

There are mitigation (secure negotiation), and upsides: agility (reacting to attacks) and compounds (defense in depth).

Perhaps, this draft or the CFRG should address this larger issue.

3.	Is this a solution looking for a problem?

Sorry to use the bad cliché above, but is there a real world use case where K12 works, but the alternatives do not?  Or is it just a generic strategy to choose optimal efficiency for a given security?

Dan Brown

BlackBerry

From: Cfrg <[email-masked]> On Behalf Of Alexey Melnikov
Sent: Sunday, February 16, 2020 6:16 AM
To: [email-masked]
Subject: [Cfrg] RGLC on draft-irtf-cfrg-kangarootwelve-01

Dear CFRG participants,

This message is starting 2 weeks RGLC on draft-irtf-cfrg-kangarootwelve-01 ("KangarooTwelve"), that will end on March 1st 2020. If you've read the document and think that it is ready (or not ready) for publication as an RFC, please send a message in reply to this email or directly to CFRG chairs ([email-masked] <mailto:[email-masked]> ). If you have detailed comments, these would also be very helpful at this point.

Thank you,

Alexey, for CFRG chairs.

----------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---

From: Gilles Van Assche <[email-masked]>
Date: Tue, 25 Feb 2020 16:11:10 +0100

Dear Dan,

Thanks for your comments and questions.

About your first question, NIST LWC is about having algorithms that fit
in a very constrained environment. The candidates of the NIST LWC likely
are much slower than K12 on a general purpose processor. So we don't
think there is overlap there.

About your last two questions, we simply think that K12 is a solution
that can benefit to many users. Probably that there are not many
use-cases that, say, SHA-256 cannot handle, but K12 is more optimal in a
number of ways. Specifically, K12 is the only hash function that is at
the same time not broken *and* very fast in software *and* directly
based on such a long record of third-party cryptanalysis. (Other
arguments can be found in Benoît's slides
https://benoit.viguier.nl/files/K12atMontreal.pdf .)

Kind regards,
Gilles, for the K12 authors

On 2/24/20 8:42 PM, Dan Brown wrote:
> It may be too late now to ask for explanations that would unpuzzle
> (only) me: they were probably discussed during the call for adoption. 
> If so, please disregard the rest of the message.
>
>  
>
> ***
>
>  
>
> Background:
>
>  
>
> My understanding, which I expect is simplistic, is that this (K12) is
> a fast variable length hash (XOF) which uses fewer rounds than the
> existing NIST XOF (or similar constructs).
>
>  
>
> For sake of argument, let us assume K12 is secure, and it has merit of
> being faster than some alternatives, especially NIST XOF.
>
>  
>
> Isn’t NIST also running a lightweight crypto (LWC) project?  Are some
> algorithms there even faster than Kangaroo12?
>
>  
>
> I could guess that an answer is that NIST PQC is a matter of security,
> but NIST LWC is a matter of efficiency, so is more fair game for
> CFRG?  But maybe there’s a better answer.
>
>  
>
> The more options in a system, meaning solutions to a problem, in this
> case, variable-length hashing, has some downsides, such as adversaries
> negotiating the weakest option.
>
>  
>
> There are mitigation (secure negotiation), and upsides: agility
> (reacting to attacks) and compounds (defense in depth).
>
>  
>
> Sorry to use the bad cliché above, but is there a real world use case
> where K12 works, but the alternatives do not?  Or is it just a generic
> strategy to choose optimal efficiency for a given security?
>
> 
>
> Dan Brown
>
> BlackBerry
>
>  
>
> *From:* Cfrg <[email-masked]> *On Behalf Of *Alexey Melnikov
> *Sent:* Sunday, February 16, 2020 6:16 AM
> *To:* [email-masked]
> *Subject:* [Cfrg] RGLC on draft-irtf-cfrg-kangarootwelve-01
>
>  
>
> Dear CFRG participants,
>
> draft-irtf-cfrg-kangarootwelve-01 ("KangarooTwelve"), that will end on
> March 1st 2020. If you've read the document and think that it is ready
> (or not ready) for publication as an RFC, please send a message in
> reply to this email or directly to CFRG chairs ([email-masked]
> <mailto:[email-masked]>). If you have detailed comments, these
> would also be very helpful at this point.
>
>
>
> Thank you,
>
> Alexey, for CFRG chairs.
>
> ------------------------------------------------------------------------
> This transmission (including any attachments) may contain confidential
> information, privileged material (including material protected by the
> solicitor-client or other applicable privileges), or constitute
> non-public information. Any use of this information by anyone other
> than the intended recipient is prohibited. If you have received this
> transmission in error, please immediately reply to the sender and
> delete this information from your system. Use, dissemination,
> distribution, or reproduction of this transmission by unintended
> recipients is not authorized and may be unlawful.
>