[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a5c50afa7e11329ea301e64bc03951b38f4e1eda.camel@chronox.de>
Date: Thu, 07 Jan 2021 08:53:15 +0100
From: Stephan Mueller <smueller@...onox.de>
To: Eric Biggers <ebiggers@...nel.org>
Cc: herbert@...dor.apana.org.au, mathew.j.martineau@...ux.intel.com,
dhowells@...hat.com, linux-crypto@...r.kernel.org,
linux-fscrypt@...r.kernel.org, linux-kernel@...r.kernel.org,
keyrings@...r.kernel.org
Subject: Re: [PATCH 3/5] crypto: add RFC5869 HKDF
Am Mittwoch, dem 06.01.2021 um 23:30 -0800 schrieb Eric Biggers:
> On Mon, Jan 04, 2021 at 10:49:13PM +0100, Stephan Müller wrote:
> > RFC5869 specifies an extract and expand two-step key derivation
> > function. The HKDF implementation is provided as a service function that
> > operates on a caller-provided HMAC cipher handle.
>
> HMAC isn't a "cipher".
>
> > The extract function is invoked via the crypto_hkdf_setkey call.
>
> Any reason not to call this crypto_hkdf_extract(), to match the
> specification?
I named it to match the other KDF implementation. But you are right, I will
name it accordingly.
>
> > RFC5869
> > allows two optional parameters to be provided to the extract operation:
> > the salt and additional information. Both are to be provided with the
> > seed parameter where the salt is the first entry of the seed parameter
> > and all subsequent entries are handled as additional information. If
> > the caller intends to invoke the HKDF without salt, it has to provide a
> > NULL/0 entry as first entry in seed.
>
> Where does "additional information" for extract come from? RFC 5869 has:
>
> HKDF-Extract(salt, IKM) -> PRK
>
> Inputs:
> salt optional salt value (a non-secret random value);
> if not provided, it is set to a string of HashLen
> zeros.
> IKM input keying material
>
> There's no "additional information".
I used the terminology from SP800-108. I will update the description
accordingly.
>
> >
> > The expand function is invoked via the crypto_hkdf_generate and can be
> > invoked multiple times. This function allows the caller to provide a
> > context for the key derivation operation. As specified in RFC5869, it is
> > optional. In case such context is not provided, the caller must provide
> > NULL / 0 for the info / info_nvec parameters.
>
> Any reason not to call this crypto_hkdf_expand() to match the specification?
I will update the function name.
Thanks
Stephan
>
> - Eric
Powered by blists - more mailing lists