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

[Robert Moskowitz <[e-mail]>]

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.