Re: [Lake] Review of KMAC in draft-ietf-lake-edhoc-08
Robert Moskowitz <rgm-sec@htt-consult.com> Fri, 30 July 2021 21:43 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 316223A125D for <lake@ietfa.amsl.com>; Fri, 30 Jul 2021 14:43:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iIizLH0Joarl for <lake@ietfa.amsl.com>; Fri, 30 Jul 2021 14:43:49 -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 EB15C3A1284 for <lake@ietf.org>; Fri, 30 Jul 2021 14:43:48 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id B384362620; Tue, 5 Jan 2010 05:32:47 -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 5W9Jx4oCPuos; Tue, 5 Jan 2010 05:32:39 -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 A94FE62653; Tue, 5 Jan 2010 05:32:38 -0500 (EST)
To: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
Cc: "lake@ietf.org" <lake@ietf.org>
References: <3491f565-ae3d-ebd6-0a3b-00b594ea88f1@htt-consult.com> <1B135ECD-F85D-4D0B-80EB-0B07B13875F0@ll.mit.edu>
From: Robert Moskowitz <rgm-sec@htt-consult.com>
Message-ID: <e0fba67c-c0a2-8f1e-953a-9a03092b0faf@htt-consult.com>
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: <1B135ECD-F85D-4D0B-80EB-0B07B13875F0@ll.mit.edu>
Content-Type: multipart/alternative; boundary="------------678FFF800D5FA01FA8E0573F"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/lake/_MLfuOVRE7-3u8of-PJjsppo5UA>
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 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 <rgm-sec@htt-consult.com> >> 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"<lake-bounces@ietf.org on behalf of rgm-sec@htt-consult.com> 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 >>> Lake@ietf.org >>> https://www.ietf.org/mailman/listinfo/lake >>> >> >
- [Lake] Review of KMAC in draft-ietf-lake-edhoc-08 Robert Moskowitz
- Re: [Lake] Review of KMAC in draft-ietf-lake-edho… Blumenthal, Uri - 0553 - MITLL
- Re: [Lake] Review of KMAC in draft-ietf-lake-edho… Blumenthal, Uri - 0553 - MITLL
- Re: [Lake] Review of KMAC in draft-ietf-lake-edho… Robert Moskowitz
- Re: [Lake] Review of KMAC in draft-ietf-lake-edho… Robert Moskowitz
- Re: [Lake] Review of KMAC in draft-ietf-lake-edho… Robert Moskowitz
- Re: [Lake] Review of KMAC in draft-ietf-lake-edho… Göran Selander