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

Robert Moskowitz <rgm-sec@htt-consult.com> Fri, 30 July 2021 22:33 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA61C3A1400 for <lake@ietfa.amsl.com>; Fri, 30 Jul 2021 15:33:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NEQnc3NnJ-Al for <lake@ietfa.amsl.com>; Fri, 30 Jul 2021 15:33:30 -0700 (PDT)
Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (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 250683A13FE for <Lake@ietf.org>; Fri, 30 Jul 2021 15:33:30 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 65B3F62653 for <Lake@ietf.org>; Tue, 5 Jan 2010 06:22:28 -0500 (EST)
X-Virus-Scanned: amavisd-new at htt-consult.com
Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id JxGgaxmXFKtX for <Lake@ietf.org>; Tue, 5 Jan 2010 06:22:24 -0500 (EST)
Received: from lx140e.htt-consult.com (unknown [192.168.160.29]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 3FA1562620 for <Lake@ietf.org>; Tue, 5 Jan 2010 06:22:23 -0500 (EST)
From: Robert Moskowitz <rgm-sec@htt-consult.com>
To: Lake@ietf.org
References: <64717eb2-84db-f5a1-2ad1-9d71d8d4f51c@htt-consult.com>
Message-ID: <544e923d-e00d-f572-6865-5cc87f1201a2@htt-consult.com>
Date: Fri, 30 Jul 2021 18:33:19 -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: <64717eb2-84db-f5a1-2ad1-9d71d8d4f51c@htt-consult.com>
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/Zg-Ma1BpkzTDP7BJRnU-2B0I0E4>
Subject: Re: [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 22:33:35 -0000

Also you should probably add references for NIST FIPS-202, SP800-185, 
and SP800-56Cr1.  I can provide xml2RFC stuff for that as I have them in 
my draft (or just grab my xml from drafts repo).

On 7/30/21 3:48 PM, Robert Moskowitz 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.
>