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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B2B923A10D3 for <>; Fri, 30 Jul 2021 14:09:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 QjNtNVP-3bHV for <>; Fri, 30 Jul 2021 14:09:23 -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 E108F3A09E7 for <>; Fri, 30 Jul 2021 14:09:22 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 33A0A62653; Tue, 5 Jan 2010 04:58:20 -0500 (EST)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with LMTP id 5oVufK5W6tNs; Tue, 5 Jan 2010 04:58:08 -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 C2459624C7; Tue, 5 Jan 2010 04:58:05 -0500 (EST)
To: "Blumenthal, Uri - 0553 - MITLL" <>, "" <>
References: <> <>
From: Robert Moskowitz <>
Message-ID: <>
Date: Fri, 30 Jul 2021 17:09:01 -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="------------C44A2831DFC77F86FF08C3B5"
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:09:28 -0000

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 

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