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

Robert Moskowitz <rgm-sec@htt-consult.com> Fri, 30 July 2021 19:48 UTC

Return-Path: <rgm-sec@htt-consult.com>
X-Original-To: lake@ietfa.amsl.com
Delivered-To: lake@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 5D0033A0CE8 for <lake@ietfa.amsl.com>; Fri, 30 Jul 2021 12:48:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id ZEqcWAEoExce for <lake@ietfa.amsl.com>; Fri, 30 Jul 2021 12:48:50 -0700 (PDT)
Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14E463A0CDF for <Lake@ietf.org>; Fri, 30 Jul 2021 12:48:47 -0700 (PDT)
Received: from localhost (localhost []) by z9m9z.htt-consult.com (Postfix) with ESMTP id 1D51C62769 for <Lake@ietf.org>; Tue, 5 Jan 2010 03:37:45 -0500 (EST)
X-Virus-Scanned: amavisd-new at htt-consult.com
Received: from z9m9z.htt-consult.com ([]) by localhost (z9m9z.htt-consult.com []) (amavisd-new, port 10024) with LMTP id LWDLzFTebX6f for <Lake@ietf.org>; Tue, 5 Jan 2010 03:37:40 -0500 (EST)
Received: from lx140e.htt-consult.com (unknown []) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id A237562620 for <Lake@ietf.org>; Tue, 5 Jan 2010 03:37:39 -0500 (EST)
To: Lake@ietf.org
From: Robert Moskowitz <rgm-sec@htt-consult.com>
Message-ID: <64717eb2-84db-f5a1-2ad1-9d71d8d4f51c@htt-consult.com>
Date: Fri, 30 Jul 2021 15:48:38 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/lake/56zEoKFYkG3zY9OElm20tIXgEwM>
Subject: [Lake] Review of KMAC in draft-ietf-lake-edhoc-08
X-BeenThere: lake@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Lightweight Authenticated Key Exchange <lake.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lake>, <mailto:lake-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lake/>
List-Post: <mailto:lake@ietf.org>
List-Help: <mailto:lake-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lake>, <mailto:lake-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Jul 2021 19:48:54 -0000

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.