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
next prev parent 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).