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

"Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu> Fri, 30 July 2021 21:18 UTC

Return-Path: <prvs=7845065c46=uri@ll.mit.edu>
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 0E9983A1148 for <lake@ietfa.amsl.com>; Fri, 30 Jul 2021 14:18:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=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 UJ_uH0D21CUu for <lake@ietfa.amsl.com>; Fri, 30 Jul 2021 14:18:30 -0700 (PDT)
Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) (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 F0CA33A1146 for <lake@ietf.org>; Fri, 30 Jul 2021 14:18:29 -0700 (PDT)
Received: from LLE2K16-HYBRD02.mitll.ad.local (LLE2K16-HYBRD02.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTPS id 16ULIKxp001342; Fri, 30 Jul 2021 17:18:20 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector5401; d=microsoft.com; cv=none; b=ciCbywcDkQZH64cx5uYd8sj1ndYdYlCoWIVs/g2BW3SRH4MW42/hxbNoypRtfTqX/sYgea12jHVq+XovPVgV9ZpgdvfQuYVRbsTV63SgpfyoWs1jvVwhtlT2Yj/wvBHhco7eD7xWKyBWrOgAJP8E3w2gdZOIGa1whPcxy49JYj9igmjSPXZulhf8EK15nvwW3NXBkdx/HFwC/+Vj/FFjDA0Z1RFXFeB+QJJpOTKhcLw0jeIPP0xKUsmRyfHrXdlR8RM4nqzWTfSlb92mmIOPD9dVEUaC/wN0sjnl3wTyMjDDXLRZMiiIMCpRiGUopd4cMNSnQAk/BehNIUmldBqVxQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector5401; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VtwPyA4AWqYZaiLwD/PgAn22Hb+UqImEEQLEHXEhVT0=; b=e7aW7m6NOkFDc50H6l5CQSjotOf+yG4AXhfEeGBBGdgjEyKlbdPnldvfqFmHMw+PbSvdoS7T8BPrhVz14xoLnj92Wnd1HofMyR842tHECGJYJL2aZIFOzF6bVjQwCjuYgY9luNqKhrtaE6i4IOOwpmYHi0va0TkrCXL5nb6gI1sqn/bDHGqEv/6ia22VYPbfcnhtpN7OliKXbQVlzw9T0sIRbvTVnZvOSpDTDe8lAI9kwVasTOGFV4gp5fcnZkilGbRCXCZg9MxP8KjyZq8xpjtb4YuLPDrXDRlzfGF/xwqclgMIandru8jk1+gWPkaIIuPHHcpIp846FDudpl8zzw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ll.mit.edu; dmarc=pass action=none header.from=ll.mit.edu; dkim=pass header.d=ll.mit.edu; arc=none
From: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
To: Robert Moskowitz <rgm-sec@htt-consult.com>
CC: "lake@ietf.org" <lake@ietf.org>
Thread-Topic: [Lake] Review of KMAC in draft-ietf-lake-edhoc-08
Thread-Index: AQHXhXwZKoJ2zkN6okiHR9r7uXutWqtbua4AgABJloCAAAKSgA==
Date: Fri, 30 Jul 2021 21:18:14 +0000
Message-ID: <1B135ECD-F85D-4D0B-80EB-0B07B13875F0@ll.mit.edu>
References: <3491f565-ae3d-ebd6-0a3b-00b594ea88f1@htt-consult.com>
In-Reply-To: <3491f565-ae3d-ebd6-0a3b-00b594ea88f1@htt-consult.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ll.mit.edu;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 1ff1988c-30eb-496c-975c-08d9539f8b20
x-ms-traffictypediagnostic: SN5P110MB0909:
x-microsoft-antispam-prvs: <SN5P110MB090952FDE21F3B3823EFBC1090EC9@SN5P110MB0909.NAMP110.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 9LzXx/gAvZhRdTN3cXhldGhB31CEDtI8PgfeTn+TYHFdj3PJN/2SuqoG28PYDymHwxYQqczbl2CuQcIuvhu/4CykvsEL8n566I0E9nGp9wiv4kZVutG/hwiI0mnn01z/M2d4qFTLZ8ZDyHknVEK0LkVr+k8qQuLd9QKhbunSEw0NvOgz2iQxDLYHsXurEBhvtzGce60Qt/Zpp3Vc4+rPJkXNqj5+m5n6Dcjp9fWfcRuG2NKQ+UkKWVL1/PsBlB3kCJAy9JHZu8eihRIBiMOSPPTdKU1GjzOOWZYRKZptoFeiKCB6kE9Km+KqonsOePTI1B+7BqwI4M94IraMBZhR7GeNTxWMN/LhAbRY1eCSwSF9cInxgRTQl3Qpg7ZCSlO81KfHPeNZ6hAtzOKkZ9ypEWrpIE/LQhETgN5cHJ5HaRhy8ohh+txm2pwKmi9vAS3DUhqakE8BYq3w13ki/TX4Hay87oLHA4EZyZoN+wnh8vk3xS70GGYOLJpPq+IzgNWt6C5m/TEYuyY22HjbZvZ5sdMJEpTvz/p2/k9XjlnOG72454So0FlqCmgUblkxRULPtHtur77N2aS0sE1jQE+sNIbhDGdmMty+X8iY1TfUAa7BJuGjgBsZRR7dy2JyrX2NvCzIJp7KLNNVBft/k/I6eFAT5VNSu9OVZxDma7sELkhIQy27U8ZGLP/6krXCpBVxZkTdGhu/PCLHmd2Kja9fGYgSdqnHuquzz2ib83IEWI0=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SN5P110MB0560.NAMP110.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(376002)(396003)(346002)(39850400004)(136003)(366004)(71200400001)(6486002)(186003)(8676002)(2906002)(33656002)(8936002)(6512007)(5660300002)(6506007)(4326008)(99936003)(316002)(83380400001)(6916009)(64756008)(66446008)(75432002)(66556008)(53546011)(122000001)(66476007)(86362001)(66616009)(66946007)(2616005)(166002)(478600001)(76116006)(966005)(38070700005)(45980500001); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: 3AW+fpEYT3vCX2Zk79psPXs4xbT2bEBe190E7LZJL1EGBOlYpMwekWyJikfxH+1CMyw79C3s8NXQb+rM0+iO49yBZRdI5NpWo/gVmrMBsMfcNENfBv7MWrXMCK/gXMGEXBIkQig5KmCnkK0uFCeEJsNhTMjBuo1IhhwfXYvt29O+5AEuwB+xCHFl5HwOQoUOyvUCg5j2pDGw6Qad7KVF3IR768Rr0Y92UpINu3xEMOcQSBIUm3HNgZpmoeZC59S1OuV8z4h70Mkz0bHT8XPMAZboqnt7TF9ET8v4hTfB6zKRrKBkNooTCAL6zar1Wh5YjalmmZNCS/1MdgwsDexhhg+WPH6cwJ4LNrqGz6ZtP35uJCVrlcZDwegVYxHuuOEgt2vOIdsVLlo5Wpcrz4e8fxV2grfJ7UDn0gUKdD251qyASpm1vjSwxnXFBLk2Qpa3oytYHOkVrT1GWjrzBBWpYZ1PIV6JYSakC1qTGSKj5/Zd4ZrE8UCDhpWapRiL1ferOI82pnZdD8MnvYFNPWAV5VTLGKFw4pXocJDipjeN5Vq6uU3nYrJTC5ojyvNVXq/3QuSic+BTNQjRWSeq8oCCoAuFfTa9BrMjoYOlsFYMFbQ=
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; boundary="Apple-Mail-F4BEE075-3E81-4CEB-8CC0-77A18C7AA3EF"; protocol="application/pkcs7-signature"; micalg=sha-256
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SN5P110MB0560.NAMP110.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: 1ff1988c-30eb-496c-975c-08d9539f8b20
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jul 2021 21:18:14.8080 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 83d1efe3-698e-4819-911b-0a8fbe79d01c
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN5P110MB0909
X-OriginatorOrg: ll.mit.edu
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-07-30_11:2021-07-30, 2021-07-30 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2103310000 definitions=main-2107300145
Archived-At: <https://mailarchive.ietf.org/arch/msg/lake/5mczNT-OZ9vvw0b52tfgz_Hmppg>
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:18:35 -0000

> 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. ;-)

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

>> 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. :-)

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. 

As for LWC - what's your take on Romulus? I did one can only accept AEAD that's nonce misuse-resistant. 

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