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

"Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu> Fri, 30 July 2021 20:45 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 6A21F3A1012 for <lake@ietfa.amsl.com>; Fri, 30 Jul 2021 13:45:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.195
X-Spam-Level:
X-Spam-Status: No, score=-4.195 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 A6o7NGDsql9R for <lake@ietfa.amsl.com>; Fri, 30 Jul 2021 13:45:46 -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 936513A0FE3 for <Lake@ietf.org>; Fri, 30 Jul 2021 13:45:45 -0700 (PDT)
Received: from LLE2K16-HYBRD01.mitll.ad.local (LLE2K16-HYBRD01.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTPS id 16UKjf7q027228; Fri, 30 Jul 2021 16:45:41 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector5401; d=microsoft.com; cv=none; b=hXXcFLRJAmmhdHu81rScXsN3jIrRtvQogtzMMaTyt7EwQ3awBuzWcN1vMIivJOUJsd+VhNuT0KYexYEoVAe9I5xy0TmvNR1lrUrUQtYXIGsYIJCr1mqq3Ub+oTh4fiwLyqpSTCZnC6w5n8n6Wj+US5ZtSIZ0ljYGgA0ZYTwLp3c7WtBr6Svick7JErXoIKYmfnAvIycY0S8TKa0b3AJPvEiNFCRvvEbtoxSinDR3n7indK2o7jbxyoOPebe+IDxFf4wLeaxM0U6lSqvffziYRaaZGgeNu4L8WHwOhp2+j+CV6rvoPTDhm2YJYnArqrqg3Hiv/IjBxinoo55YM3hgRg==
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=xsZLNgvlCEM0HnzjldLr2jK5snCTEWLyYqil73UK1hE=; b=X3Br/mi9bq3oq+ft3uU0VcOVx7rk2e1NxB+tsKRg0owkvSv4/zF7M6kgyUpztOJTWDvonIk3sUv0TyCUs86hsWZ8zoGH3USjkHQE6NYoINK16xu686/Tza9pUucVAnuuSIICr610nTJGRVD0jWHVxmkTzNbIwlVagSyDi6pTNNyONKLXMglLqMwA83/0vAK1LZ7TjajqJWQ7whIsSUnW9qHsmL6beLpN3mY4F7+9xSpf1+Jpau7ksNBq0TPeCrOW27hiLZgerxy7z5o8Dcpf46NuvswizWPtr50oHVDnQVVNP5nKqFGcxZvzi/wXCaer5OUL91cq70wV+loHWXtqyA==
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>, "Lake@ietf.org" <Lake@ietf.org>
Thread-Topic: [Lake] Review of KMAC in draft-ietf-lake-edhoc-08
Thread-Index: AQHXhXwZKoJ2zkN6okiHR9r7uXutWqtbua4A
Date: Fri, 30 Jul 2021 20:45:39 +0000
Message-ID: <8DA1AB98-2204-460D-A56F-FD23099FB9F5@ll.mit.edu>
References: <64717eb2-84db-f5a1-2ad1-9d71d8d4f51c@htt-consult.com>
In-Reply-To: <64717eb2-84db-f5a1-2ad1-9d71d8d4f51c@htt-consult.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.50.21061301
authentication-results: htt-consult.com; dkim=none (message not signed) header.d=none; htt-consult.com; dmarc=none action=none header.from=ll.mit.edu;
x-originating-ip: [129.55.200.20]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: a9e2f492-d542-445a-eaee-08d9539afda6
x-ms-traffictypediagnostic: SN5P110MB0382:
x-microsoft-antispam-prvs: <SN5P110MB0382589BBE76B556A8A652F490EC9@SN5P110MB0382.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: uyrYj92TcfxJBK6kRmPmMgFqKlGXWBCIHhLK1FbQSQi82S0BdpVfGuObYCt9PufMjbkLQuZnDSlGQnq5DJl7a4Bp4NIfZ7SszDtwrs1ADaOuSefFVursQHcpJmrdTVgf6RG/5A2vgFIryGHUHubcK2pmapTPyC8Bvi5rRhjf1psySIxVhtxHJpf4zb7jWBNG1yHjwskiEzmAhXDdHM7GvR68OfjxsRZeI1T2BjVLvVls+Fw/SaUYs+ux7GA72PJiIbpflFUVKzB+EvdyQrw1j7LGlGRqL1oyly4ZEzpEimDH9STbd1glNe8yOgICjaMbjfXu6c6Jb+HWjUSgpk72dKifllAVd4plWaRooLaFaducKfrPKQ9M6wMjshhFus+U93oeGMPWBlzVvnU9corh5oBRm9Qr0HB0cKj2YCA/dWxw1GDekfjqruPjWVK/isPem4qkor2ojuMVOISuRwvwisBePCJjoDWmX3bYhkCyA/PbGhB0IENMkND/aDg2U+/9I7HhG+vU6Sij0o7Mb6sAVaaeojeAQirK/YA8Rmq5G+DoWxCHOUvO1phqS4veGSlTvj8/KMMnz8Zb1NKUzerZL600BdMW1uXyyTQu+BQvx45Z1JDRMLMXD6VlHezW9MNpC3kO2jA2cdoVlEPJiCAakaDpe+1GZiPh2ArpQ45ppB1T0zLL3zm1JA5GCOBBoHTuVm9LfLIMCeSySg/hj0TNMMAa5XT8vUesAZk5xSX0iEs=
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)(366004)(136003)(346002)(396003)(39850400004)(8676002)(66446008)(6506007)(316002)(75432002)(38070700005)(64756008)(66946007)(66556008)(66476007)(2906002)(66616009)(5660300002)(2616005)(6512007)(38100700002)(26005)(966005)(86362001)(8936002)(6486002)(71200400001)(99936003)(83380400001)(76116006)(110136005)(122000001)(478600001)(186003)(33656002)(45980500001); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: B8hsszg/IHnQ3XJt7vqkG6Y/yGGjsn3WMNO41J8bSRNvSyDM2KynOnK6bNIe/orDzc6QI71Qef6SF/SZ2ijpyFR11jQBn6ozcRrL4tCRzMWQqrnydug58dbJ9TL0Ky4rgj+rawn1JRrnYTjK59BgSpYCwbYkDEqcG7rHwkVnpMet1DHtSb/L1kLNwZHSPYMsG/IaMb/0xaZpMjI/tn7DSObvSmqIsuAE4VOwJo7UI9QBirW4NHDzeThZdq+caWNHHSPPXt1Z7ZfopRRXeQg5EEdhUabyM7z/sLYCRjXCi1Azcg8QihL64bN7LhIEcs3Yii5qoj/PMmkj/xkpbBIuAN07JRWBbt3V9P7SsH/3uzsHBADMLvbzTr1h1siHb0Js9Yk1EwC3ZVzLV0JNyc542SpjuTfYvZUV/YzBuo36+20/yn3Puw9fZXaV/aE0+SNrloY0Cp/HcM+iOPI6dewhd1lQi5FRJ8JtWUz4DLu1Qo8iqOimk3ZgdIAwQpy7zLz/O/PboIrQPTWzL3uAoAETRF9fMkh0YcTtLYiDkZxeUc37kRu5wSCTvwUmoZ3XGUYmo/qGv3G1CQYjJ9G+KXlfgTwqggRInOixuFbLUnOehtxAZd3Eqtw3XSlchOaGLOBOiSgwZUrAjn2M4HFAPL7pVoRnQi1q0P2cxdFyhyfzQn15fs4JYZJsBkT9ep2xK2H96lfSpjKRIzIevRkNk6bmKg==
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3710508339_1998189172"
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: a9e2f492-d542-445a-eaee-08d9539afda6
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jul 2021 20:45:39.4070 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 83d1efe3-698e-4819-911b-0a8fbe79d01c
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN5P110MB0382
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-2107300142
Archived-At: <https://mailarchive.ietf.org/arch/msg/lake/WtUF7JLNgh7_w5OE4EM_KF0dS7A>
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 20:45:59 -0000

A complete newcomer here, most likely lacking the context.

But all that aside - doesn't KMAC require AES-128, as opposed to AES-256? Is it a concern, and if not - why not?
--
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
 

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