Subject: [Lake] Review of KMAC in draft-ietf-lake-edhoc-08

From: Robert Moskowitz <[email-masked]>
Date: Fri, 30 Jul 2021 15:48:38 -0400

Greetings Lakers.  ;)

 From a Great Lakes person (only one I have not swum in is Ontario and 
let me tell you, Superior is COLD!).

I have looked at your use of KMAC and it is a good start, but not as 
good as can be done with KMAC.  Please see my draft:

https://datatracker.ietf.org/doc/draft-moskowitz-hip-new-crypto/

Not only do I use KMAC for HMAC replacement, but also as the KDF.  I 
also include Xoodyak, one of the NIST LWC finalists of which only 4 
include hashing.

This draft has been implemented in openHIP and reviewed by Team Keccak.

WRT to use as a KDF.  In my discussions with NIST and Team Keccak 
(including F2F at IACR RWC Jan '20) KMAC directly does the 
extract-and-expand.  You do not need to invoke KMAC twice.

In SP800-56Cr1 sec 8.3, KMAC is not included in a 2-step KDF as it is 
waiting SP800-108 update.  But in my research I see KMAC doing exactly 
what it takes the two HMAC steps to accomplish.  Team Keccak has 
confirmed this revaluation.  NIST has hedged its position, as one would 
expect, but they have not said no (again F2F discussions in Dec '19).

Further you should point out that HMAC needs 2 hash operations to KMAC's 
single sponge invocation.  This is an important performance 
consideration in constrained devices.  Even if SHA-256 is marginally 
faster than KMAC-128 (same strength), it is not twice as good.

On top of that KMAC as a KDF replaces two or more HMACs (depending on 
how many key bits needed).  Again a performance gain.

I would be happy to work with the draft authors on changes in KMAC usage.

Also NIST is stating that the LWC will conclude by end of 2021.  It 
behoves Lake to look hard at the LWC finalists that do hashing. This 
could be saved for a separate draft, depending on expected completion 
and last call of lake-edhoc.

thank you for consideration.

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Fri, 30 Jul 2021 20:45:39 +0000

A complete newcomer here, most likely lacking the context.

But all that aside - doesn't KMAC require AES-128, as opposed to AES-256? Is it a concern, and if not - why not?
--
Regards,
Uri
 
There are two ways to design a system. One is to make is so simple there are obviously no deficiencies.
The other is to make it so complex there are no obvious deficiencies.
                                                                                                                                     -  C. A. R. Hoare

On 7/30/21, 15:50, "Lake on behalf of Robert Moskowitz" <[email-masked] on behalf of [email-masked]> wrote:

    Greetings Lakers.  ;)

    -- 
    Lake mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/lake

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 30 Jul 2021 17:09:01 -0400

> A complete newcomer here, most likely lacking the context.

Of course a newcomer to Lake.  And I am interested in the context as I 
have been looking at switching to SHAKE/cSHAKE/KMAC where changes are 
occuring.

> But all that aside - doesn't KMAC require AES-128, as opposed to AES-256? Is it a concern, and if not - why not?

No.  KMAC does not use AES at all.  It is a specific SHAKE invocation 
described in SP800-185.  One argument against NIST Keccak use is the 
size of the sponge.  A smaller sponge would work just fine to deliver 
128 bit strength with resulting memory and performance gains.  A 800 bit 
sponge does the job, but then you are not NIST compliant and probably 
won't find the code base (1600 bit sponge is what is in openSSL).

Instead of pushing for a smaller sponge for SHAKE, I have been advised 
to work with LWC, which I have in the form of Xoodyak.  Of course 
Xoodyak is a type of placeholder in how to use a good LWC hash until 
NIST finishes...

And if your point is hash strength, KMAC-256 is there.  It does not use 
AES at all, but DOES require a 1600 bit sponge.  And none of the LWC 
that I have looked at provide 256 bit strength.  All there in FIPS-202 
and SP800-185.

Amen to that!

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Fri, 30 Jul 2021 21:18:14 +0000

> On Jul 30, 2021, at 17:10, Robert Moskowitz <[email-masked]> wrote:
> 
>  
> 
> Of course a newcomer to Lake. 

I meant myself, and my comments. ;-)

> And I am interested in the context as I have been looking at switching to SHAKE/cSHAKE/KMAC where changes are occuring.

Personally, my only concern with SHAKE would be its performance, as there isn't much HW acceleration yet, nor a push for it.

> No.  KMAC does not use AES at all.  It is a specific SHAKE invocation described in SP800-185.  One argument against NIST Keccak use is the size of the sponge.  A smaller sponge would work just fine to deliver 128 bit strength with resulting memory and performance gains.  A 800 bit sponge does the job, but then you are not NIST compliant and probably won't find the code base (1600 bit sponge is what is in openSSL).

Darn... I should work less, or lay off stiff drinks. :-)

Of course - CMAC is AES-based. 

> Instead of pushing for a smaller sponge for SHAKE, I have been advised to work with LWC, which I have in the form of Xoodyak.  Of course Xoodyak is a type of placeholder in how to use a good LWC hash until NIST finishes...
> 
> And if your point is hash strength, KMAC-256 is there.  It does not use AES at all, but DOES require a 1600 bit sponge.  And none of the LWC that I have looked at provide 256 bit strength.  All there in FIPS-202 and SP800-185.

My personal recommendation is to bite the bullet and use 1600-but sponge. 

As for LWC - what's your take on Romulus? I did one can only accept AEAD that's nonce misuse-resistant. 

Thnx
--

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 30 Jul 2021 17:43:37 -0400

> I meant myself, and my comments. ;-)

There will hopefully be a number of newcomers reviewing this.  That is 
the way the security area works.

>
>> And I am interested in the context as I have been looking at 
>> switching to SHAKE/cSHAKE/KMAC where changes are occuring.
>
> Personally, my only concern with SHAKE would be its performance, as 
> there isn't much HW acceleration yet, nor a push for it.

If specified for IoT, it will come as the HW designs are there. Also for 
LWC.

>> 128 bit strength with resulting memory and performance gains.  A 800 
>> bit sponge does the job, but then you are not NIST compliant and 
>> probably won't find the code base (1600 bit sponge is what is in 
>> openSSL).
>

Uri, your heritage is showing.  :)

>
> Of course - *CMAC* is AES-based.
>
>> Instead of pushing for a smaller sponge for SHAKE, I have been 
>> advised to work with LWC, which I have in the form of Xoodyak.  Of 
>> course Xoodyak is a type of placeholder in how to use a good LWC hash 
>> until NIST finishes...
>>
>> And if your point is hash strength, KMAC-256 is there.  It does not 
>> use AES at all, but DOES require a 1600 bit sponge.  And none of the 
>> LWC that I have looked at provide 256 bit strength.  All there in 
>> FIPS-202 and SP800-185.
>

Have to or write your own code.  This is NOT a parameter in the 
software; too much changes when you change the sponge size.  Also a 
KMAC-128 with a 1600 bit sponge gets a different answer than it would 
with a 800 bit sponge.  You would have to include the sponge size in 
your algorthim negotiation.

I looked at it hard back in '19.  After talks with NIST and Team Keccak, 
I drew back from playing with sponge size and have focused on LWC.

> AEAD that's nonce misuse-resistant.

I need to go through the Xoodyak doc.  There are at least 2 ways to do 
the nonce; Gilles pointed out how each works and said that what I am 
doing is fine.  But I don't recall all the text around the nonce reuse 
and need to go back to the doc.  Next week, I will respond on this point.

>>> On 7/30/21, 15:50, "Lake on behalf of Robert Moskowitz"<[email-masked] on behalf of [email-masked]>  wrote:
>>>
>>>      Greetings Lakers.  ;)
>>>

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 30 Jul 2021 18:33:19 -0400

Also you should probably add references for NIST FIPS-202, SP800-185, 
and SP800-56Cr1.  I can provide xml2RFC stuff for that as I have them in 
my draft (or just grab my xml from drafts repo).

On 7/30/21 3:48 PM, Robert Moskowitz wrote:
> confirmed this revaluation.  NIST has hedged its position, as one 
> would expect, but they have not said no (again F2F discussions in Dec 
> '19).
>
>
> Further you should point out that HMAC needs 2 hash operations to 
> KMAC's single sponge invocation.  This is an important performance