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

[Robert Moskowitz <[e-mail]>]

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