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

On 7/30/21 4:45 PM, Blumenthal, Uri - 0553 - MITLL wrote:
> 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.

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

Amen to that!

>   
>
> On 7/30/21, 15:50, "Lake on behalf of Robert Moskowitz" <lake-bounces@ietf.org on behalf of rgm-sec@htt-consult.com> 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.
>
>      --
>      Lake mailing list
>      Lake@ietf.org
>      https://www.ietf.org/mailman/listinfo/lake
>