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

["Blumenthal, Uri - 0553 - MITLL" <[e-mail]>]

> On Jul 30, 2021, at 17:10, Robert Moskowitz <[e-mail]> wrote:
> 
>  
> 
> 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. 

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.

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

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
--
>> 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" <[e-mail] on behalf of [e-mail]> 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
>>     [e-mail]
>>     https://www.ietf.org/mailman/listinfo/lake
>> 
>> 
>