Re: [CFRG] Extract-and-expand with KMAC

[John Mattsson <[e-mail]>]

Thanks Ilari!

-----Original Message-----
From: <[e-mail]> on behalf of Ilari Liusvaara <[e-mail]>
Date: Sunday, 15 November 2020 at 17:35
To: John Mattsson <[e-mail]>
Cc: CFRG <[e-mail]>
Subject: Re: [CFRG] Extract-and-expand with KMAC

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