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

Robert Moskowitz <> Fri, 30 July 2021 21:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 316223A125D for <>; Fri, 30 Jul 2021 14:43:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iIizLH0Joarl for <>; Fri, 30 Jul 2021 14:43:49 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EB15C3A1284 for <>; Fri, 30 Jul 2021 14:43:48 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id B384362620; Tue, 5 Jan 2010 05:32:47 -0500 (EST)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with LMTP id 5W9Jx4oCPuos; Tue, 5 Jan 2010 05:32:39 -0500 (EST)
Received: from (unknown []) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id A94FE62653; Tue, 5 Jan 2010 05:32:38 -0500 (EST)
To: "Blumenthal, Uri - 0553 - MITLL" <>
Cc: "" <>
References: <> <>
From: Robert Moskowitz <>
Message-ID: <>
Date: Fri, 30 Jul 2021 17:43:37 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------678FFF800D5FA01FA8E0573F"
Content-Language: en-US
Archived-At: <>
Subject: Re: [Lake] Review of KMAC in draft-ietf-lake-edhoc-08
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Lightweight Authenticated Key Exchange <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 30 Jul 2021 21:44:02 -0000

On 7/30/21 5:18 PM, Blumenthal, Uri - 0553 - MITLL wrote:
>> On Jul 30, 2021, at 17:10, Robert Moskowitz <> 
>> 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 

>>> 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"< on behalf of>  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:
>>>      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