All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: Hannes Reinecke <hare@kernel.org>
Cc: Christoph Hellwig <hch@lst.de>, Keith Busch <kbusch@kernel.org>,
	Sagi Grimberg <sagi@grimberg.me>,
	linux-crypto@vger.kernel.org, linux-nvme@lists.infradead.org
Subject: Re: [PATCH 1/9] crypto,fs: Separate out hkdf_extract() and hkdf_expand()
Date: Tue, 23 Jul 2024 01:36:02 +0000	[thread overview]
Message-ID: <20240723013602.GA2319848@google.com> (raw)
In-Reply-To: <20240722142122.128258-2-hare@kernel.org>

On Mon, Jul 22, 2024 at 04:21:14PM +0200, Hannes Reinecke wrote:
> diff --git a/crypto/Makefile b/crypto/Makefile
> index edbbaa3ffef5..b77fc360f0ff 100644
> --- a/crypto/Makefile
> +++ b/crypto/Makefile
> @@ -29,6 +29,7 @@ obj-$(CONFIG_CRYPTO_ECHAINIV) += echainiv.o
>  
>  crypto_hash-y += ahash.o
>  crypto_hash-y += shash.o
> +crypto_hash-y += hkdf.o
>  obj-$(CONFIG_CRYPTO_HASH2) += crypto_hash.o

This should go under a kconfig option CONFIG_CRYPTO_HKDF that is selected by the
users that need it.  That way the code will be built only when needed.

Including a self-test would also be desirable.

> diff --git a/crypto/hkdf.c b/crypto/hkdf.c
> new file mode 100644
> index 000000000000..22e343851c0b
> --- /dev/null
> +++ b/crypto/hkdf.c
> @@ -0,0 +1,112 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Implementation of HKDF ("HMAC-based Extract-and-Expand Key Derivation
> + * Function"), aka RFC 5869.  See also the original paper (Krawczyk 2010):
> + * "Cryptographic Extraction and Key Derivation: The HKDF Scheme".
> + *
> + * This is used to derive keys from the fscrypt master keys.

This is no longer in fs/crypto/, so the part about fscrypt should be removed.

> +/*
> + * HKDF consists of two steps:
> + *
> + * 1. HKDF-Extract: extract a pseudorandom key of length HKDF_HASHLEN bytes from
> + *    the input keying material and optional salt.

It doesn't make sense to refer to HKDF_HASHLEN here since it is specific to
fs/crypto/.

> +/* HKDF-Extract (RFC 5869 section 2.2), unsalted */
> +int hkdf_extract(struct crypto_shash *hmac_tfm, const u8 *ikm,
> +		 unsigned int ikmlen, u8 *prk)

Needs kerneldoc now that this is a library interface.

> +{
> +	unsigned int prklen = crypto_shash_digestsize(hmac_tfm);
> +	u8 *default_salt;
> +	int err;
> +
> +	default_salt = kzalloc(prklen, GFP_KERNEL);
> +	if (!default_salt)
> +		return -ENOMEM;

Now that this is a library interface, it should take the salt as a parameter,
and the users who want the default salt should explicitly specify that.  If we
only provide support for unsalted use, that might inadventently discourage the
use of a salt in future code.  As the function is named hkdf_extract(), people
might also overlook that it's unsalted and doesn't actually match the RFC's
definition of HKDF-Extract.

The use of kzalloc here is also inefficient, as the maximum length of a digest
is known (HKDF_HASHLEN in fs/crypto/ case, HASH_MAX_DIGESTSIZE in general).

> +	err = crypto_shash_setkey(hmac_tfm, default_salt, prklen);
> +	if (!err)
> +		err = crypto_shash_tfm_digest(hmac_tfm, ikm, ikmlen, prk);
> +
> +	kfree(default_salt);
> +	return err;
> +}
> +EXPORT_SYMBOL_GPL(hkdf_extract);
> +
> +/*
> + * HKDF-Expand (RFC 5869 section 2.3).
> + * This expands the pseudorandom key, which was already keyed into @hmac_tfm,
> + * into @okmlen bytes of output keying material parameterized by the
> + * application-specific @info of length @infolen bytes.
> + * This is thread-safe and may be called by multiple threads in parallel.
> + */
> +int hkdf_expand(struct crypto_shash *hmac_tfm,
> +		const u8 *info, unsigned int infolen,
> +		u8 *okm, unsigned int okmlen)

Needs kerneldoc now that this is a library interface.

> diff --git a/fs/crypto/hkdf.c b/fs/crypto/hkdf.c
> index 5a384dad2c72..9c2f9aca9412 100644
> --- a/fs/crypto/hkdf.c
> +++ b/fs/crypto/hkdf.c
>// SPDX-License-Identifier: GPL-2.0
>/*
> * Implementation of HKDF ("HMAC-based Extract-and-Expand Key Derivation
> * Function"), aka RFC 5869.  See also the original paper (Krawczyk 2010):
> * "Cryptographic Extraction and Key Derivation: The HKDF Scheme".
> *
> * This is used to derive keys from the fscrypt master keys.
> *
> * Copyright 2019 Google LLC
> */

The above file comment should be adjusted now that this file doesn't contain the
actual HKDF implementation.

> @@ -118,61 +105,24 @@ int fscrypt_hkdf_expand(const struct fscrypt_hkdf *hkdf, u8 context,
>  			u8 *okm, unsigned int okmlen)
>  {
>  	SHASH_DESC_ON_STACK(desc, hkdf->hmac_tfm);
> -	u8 prefix[9];
> -	unsigned int i;
> +	u8 *prefix;
>  	int err;
> -	const u8 *prev = NULL;
> -	u8 counter = 1;
> -	u8 tmp[HKDF_HASHLEN];
>  
>  	if (WARN_ON_ONCE(okmlen > 255 * HKDF_HASHLEN))
>  		return -EINVAL;
>  
> +	prefix = kzalloc(okmlen + 9, GFP_KERNEL);
> +	if (!prefix)
> +		return -ENOMEM;
>  	desc->tfm = hkdf->hmac_tfm;
>  
>  	memcpy(prefix, "fscrypt\0", 8);
>  	prefix[8] = context;
> +	memcpy(prefix + 9, info, infolen);

This makes the variable called 'prefix' no longer be the prefix, but rather the
full info string.  A better name for it would be 'full_info'.

Also, it's being allocated with the wrong length.  It should be 9 + infolen.

> +	err = hkdf_expand(hkdf->hmac_tfm, prefix, infolen + 8,
> +			  okm, okmlen);
> +	kfree(prefix);

kfree_sensitive()

> diff --git a/include/crypto/hkdf.h b/include/crypto/hkdf.h
> new file mode 100644
> index 000000000000..bf06c080d7ed
> --- /dev/null
> +++ b/include/crypto/hkdf.h
> @@ -0,0 +1,18 @@
> +/* SPDX-License-Identifier: GPL-2.0-or-later */
> +/*
> + * HKDF: HMAC-based Key Derivation Function (HKDF), RFC 5869
> + *
> + * Extracted from fs/crypto/hkdf.c, which has
> + * Copyright 2019 Google LLC
> + */

If this is keeping the copyright of fs/crypto/hkdf.c, the license needs to stay
the same (GPL-2.0, not GPL-2.0-or-later).

- Eric

  reply	other threads:[~2024-07-23  1:36 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-22 14:21 [PATCHv8 0/9] nvme: implement secure concatenation Hannes Reinecke
2024-07-22 14:21 ` [PATCH 1/9] crypto,fs: Separate out hkdf_extract() and hkdf_expand() Hannes Reinecke
2024-07-23  1:36   ` Eric Biggers [this message]
2024-07-23  6:24     ` Hannes Reinecke
2024-07-22 14:21 ` [PATCH 2/9] nvme: add nvme_auth_generate_psk() Hannes Reinecke
2024-07-22 14:21 ` [PATCH 3/9] nvme: add nvme_auth_generate_digest() Hannes Reinecke
2024-07-22 14:21 ` [PATCH 4/9] nvme: add nvme_auth_derive_tls_psk() Hannes Reinecke
2024-07-23  1:47   ` Eric Biggers
2024-07-23  6:26     ` Hannes Reinecke
2024-07-22 14:21 ` [PATCH 5/9] nvme-keyring: add nvme_tls_psk_refresh() Hannes Reinecke
2024-07-23  1:54   ` Eric Biggers
2024-07-22 14:21 ` [PATCH 6/9] nvme-tcp: request secure channel concatenation Hannes Reinecke
2024-07-22 14:21 ` [PATCH 7/9] nvme-fabrics: reset admin connection for secure concatenation Hannes Reinecke
2024-07-22 14:21 ` [PATCH 8/9] nvmet-tcp: support secure channel concatenation Hannes Reinecke
2024-07-23  1:48   ` Eric Biggers
2024-07-25 11:50     ` Hannes Reinecke
2024-07-25 17:21       ` Eric Biggers
2024-07-26  6:17         ` Hannes Reinecke
2024-07-22 14:21 ` [PATCH 9/9] nvmet: add tls_concat and tls_key debugfs entries Hannes Reinecke
2024-07-22 22:28 ` [PATCHv8 0/9] nvme: implement secure concatenation Eric Biggers
2024-07-23  6:16   ` Hannes Reinecke
  -- strict thread matches above, loose matches on Subject: below --
2024-08-13 11:15 [PATCHv9 " Hannes Reinecke
2024-08-13 11:15 ` [PATCH 1/9] crypto,fs: Separate out hkdf_extract() and hkdf_expand() Hannes Reinecke
2024-08-27 17:52   ` Eric Biggers
2024-08-29 10:39     ` Hannes Reinecke
2024-08-29 21:54       ` Eric Biggers
2024-08-30  6:13         ` Hannes Reinecke
2024-10-11 15:54 [PATCHv10 0/9] nvme: implement secure concatenation Hannes Reinecke
2024-10-11 15:54 ` [PATCH 1/9] crypto,fs: Separate out hkdf_extract() and hkdf_expand() Hannes Reinecke
2024-10-14 19:38   ` Eric Biggers
2024-10-15 15:05     ` Hannes Reinecke
2024-10-15 15:41       ` Eric Biggers
2024-10-16  6:40         ` Hannes Reinecke
2024-10-16 16:27           ` Eric Biggers
2024-10-18  6:33 [PATCHv11 0/9] nvme: implement secure concatenaion Hannes Reinecke
2024-10-18  6:33 ` [PATCH 1/9] crypto,fs: Separate out hkdf_extract() and hkdf_expand() Hannes Reinecke

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240723013602.GA2319848@google.com \
    --to=ebiggers@kernel.org \
    --cc=hare@kernel.org \
    --cc=hch@lst.de \
    --cc=kbusch@kernel.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=sagi@grimberg.me \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.