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

[Robert Moskowitz <[e-mail]>]

On 7/30/21 5:18 PM, Blumenthal, Uri - 0553 - MITLL wrote:
>
>> 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. ;-)

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.

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

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.
>
> My personal recommendation is to bite the bullet and use 1600-but sponge.

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.

>
> As for LWC - what's your take on Romulus? I did one can only accept 
> 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.


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