Re: [CFRG] Extract-and-expand with KMAC
Ilari Liusvaara <ilariliusvaara@welho.com> Sun, 15 November 2020 16:35 UTC
Return-Path: <ilariliusvaara@welho.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 755C93A0844 for <cfrg@ietfa.amsl.com>; Sun, 15 Nov 2020 08:35:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.622
X-Spam-Level:
X-Spam-Status: No, score=-1.622 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.276, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no 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 uHsGufAAH-JL for <cfrg@ietfa.amsl.com>; Sun, 15 Nov 2020 08:35:42 -0800 (PST)
Received: from welho-filter2.welho.com (welho-filter2b.welho.com [83.102.41.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D22D3A083F for <cfrg@irtf.org>; Sun, 15 Nov 2020 08:35:41 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 39A9AC3F74; Sun, 15 Nov 2020 18:35:38 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id wmkFNkkTEFBm; Sun, 15 Nov 2020 18:35:38 +0200 (EET)
Received: from LK-Perkele-VII (78-27-99-170.bb.dnainternet.fi [78.27.99.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id C291D2308; Sun, 15 Nov 2020 18:35:35 +0200 (EET)
Date: Sun, 15 Nov 2020 18:35:35 +0200
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: John Mattsson <john.mattsson@ericsson.com>
Cc: CFRG <cfrg@irtf.org>
Message-ID: <20201115163535.GA3384456@LK-Perkele-VII>
References: <467DD0FC-FF7F-453F-98B2-ADC7F0F976B1@ericsson.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <467DD0FC-FF7F-453F-98B2-ADC7F0F976B1@ericsson.com>
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/v9RecLMOB2Vh52SwKPNgTA4Lvx4>
Subject: Re: [CFRG] Extract-and-expand with KMAC
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Sun, 15 Nov 2020 16:35:43 -0000
On Sun, Nov 15, 2020 at 01:47:42PM +0000, John Mattsson wrote: > Hi, > > HMAC is needed to mitigate the length extension weakness of SHA-2. > SHAKE does not have this weakness and NIST has therefore > standardized the simple and efficient KMAC mode. What I do not like about KMAC is that the spec is somewhat difficult to understand (even if it is not quite as bad as FIPS202), and seemingly lacks any usable test vectors (where usable means everything is multiple of octet; I have not found unofficial ones either). (KMAC is closely related to cSHAKE, and I did find some unofficial(?) test vectors for cSHAKE. Those test vectors were very useful when writing implementation of cSHAKE.) > LAKE WG is discussing using KMAC in a extract-and-expand fashion > similar to HKDF. However, there are several options when mapping the > KDF Extract and Expand interfaces to KMAC(K, X, L, S). > > Would the following be reasonable for KMAC128, or would CFRG suggest > something else? > > PRK = Extract(salt, IKM) = KMAC128(salt, IKM, 256, “”) > OKM = Expand(PRK, L, info) = KMAC128(PRK, “”, L, info) The S parameter is contextualization and processed before K, so one should not stick arbitrary and/or possibly attacker-controlled things in S. If one just did raw substitution inside HKDF and eliminated the redundant counter octet (since first block is always enough), one would obtain: PRK = Extract(salt, IKM) = KMAC128(salt, IKM, 256, "") OKM = Expand(PRK, L, info) = KMAC128(PRK, info, L, "") One might want to contextualize those two, to obtain something like: PRK = Extract(salt, IKM) = KMAC128(salt, IKM, 256, "KDF extraction") OKM = Expand(PRK, L, info) = KMAC128(PRK, info, L, "KDF expansion") No further contextualization is possible without going beyond present KDF interface. For 256-bit level, just replace KMAC128 by KMAC256, and 256 with 512. This also has the property that if multiple expansions are computed from the same PRK, one can precompute the first two Keccak-F invocations and share those among the different expansions of the PRK. > Or should maybe the Extract and Expand intefaces be updated with more parameters? Wouldn't that cause serious API issues? Adding parameters to interfaces can cause serious issues, especially when the parameters are sometimes available and sometimes not. -Ilari
- [CFRG] Extract-and-expand with KMAC John Mattsson
- Re: [CFRG] Extract-and-expand with KMAC John Mattsson
- Re: [CFRG] Extract-and-expand with KMAC Ilari Liusvaara
- Re: [CFRG] Extract-and-expand with KMAC Jonathan Hammell
- Re: [CFRG] Extract-and-expand with KMAC Ruggero SUSELLA
- Re: [CFRG] Extract-and-expand with KMAC Gilles VAN ASSCHE
- Re: [CFRG] Extract-and-expand with KMAC rsw
- Re: [CFRG] Extract-and-expand with KMAC Dang, Quynh H. (Fed)
- Re: [CFRG] Extract-and-expand with KMAC rsw@jfet.org
- Re: [CFRG] Extract-and-expand with KMAC Gilles VAN ASSCHE