Linux cryptographic layer development
 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-nvme@lists.infradead.org, linux-crypto@vger.kernel.org
Subject: Re: [PATCH 1/9] crypto,fs: Separate out hkdf_extract() and hkdf_expand()
Date: Mon, 14 Oct 2024 12:38:14 -0700	[thread overview]
Message-ID: <20241014193814.GB1137@sol.localdomain> (raw)
In-Reply-To: <20241011155430.43450-2-hare@kernel.org>

On Fri, Oct 11, 2024 at 05:54:22PM +0200, Hannes Reinecke wrote:
> Separate out the HKDF functions into a separate module to
> to make them available to other callers.
> And add a testsuite to the module with test vectors
> from RFC 5869 to ensure the integrity of the algorithm.

integrity => correctness

> +config CRYPTO_HKDF
> +	tristate
> +	select CRYPTO_SHA1 if !CONFIG_CRYPTO_MANAGER_DISABLE_TESTS
> +	select CRYPTO_SHA256 if !CONFIG_CRYPTO_MANAGER_DISABLE_TESTS
> +	select CRYPTO_HASH2

Any thoughts on including SHA512 tests instead of SHA1, given that SHA1 is
obsolete and should not be used?

> +int hkdf_expand(struct crypto_shash *hmac_tfm,
> +		const u8 *info, unsigned int infolen,
> +		u8 *okm, unsigned int okmlen)
> +{
> +	SHASH_DESC_ON_STACK(desc, hmac_tfm);
> +	unsigned int i, hashlen = crypto_shash_digestsize(hmac_tfm);
> +	int err;
> +	const u8 *prev = NULL;
> +	u8 counter = 1;
> +	u8 tmp[HASH_MAX_DIGESTSIZE];
> +
> +	if (WARN_ON(okmlen > 255 * hashlen ||
> +		    hashlen > HASH_MAX_DIGESTSIZE))
> +		return -EINVAL;

The crypto API guarantees HASH_MAX_DIGESTSIZE, so checking that again is not
very useful.

> +
> +	memzero_explicit(tmp, HASH_MAX_DIGESTSIZE);

The zeroization above is unnecessary.  If it's done anyway, it is just an
initialization, so it should use an initializer '= {}' instead of
memzero_explicit() which is intended for "destruction".

> +MODULE_ALIAS_CRYPTO("hkdf");

This alias does not make sense and is unnecessary.  These are library functions
that are not exposed by name through the crypto API, so there is no need to wire
them up to the module autoloading accordingly.

> diff --git a/include/crypto/hkdf.h b/include/crypto/hkdf.h
> new file mode 100644
> index 000000000000..c1f23a32a6b6
> --- /dev/null
> +++ b/include/crypto/hkdf.h
> @@ -0,0 +1,18 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * HKDF: HMAC-based Key Derivation Function (HKDF), RFC 5869
> + *
> + * Extracted from fs/crypto/hkdf.c, which has
> + * Copyright 2019 Google LLC
> + */
> +
> +#ifndef _CRYPTO_HKDF_H
> +#define _CRYPTO_HKDF_H
> +
> +int hkdf_extract(struct crypto_shash *hmac_tfm, const u8 *ikm,
> +		 unsigned int ikmlen, const u8 *salt, unsigned int saltlen,
> +		 u8 *prk);
> +int hkdf_expand(struct crypto_shash *hmac_tfm,
> +		const u8 *info, unsigned int infolen,
> +		u8 *okm, unsigned int okmlen);
> +#endif

This needs to include <crypto/hash.h>.

Otherwise there will be errors if someone includes this as their first header.

- Eric

  reply	other threads:[~2024-10-14 19:38 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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-11 15:54 ` [PATCH 2/9] nvme: add nvme_auth_generate_psk() Hannes Reinecke
2024-10-11 15:54 ` [PATCH 3/9] nvme: add nvme_auth_generate_digest() Hannes Reinecke
2024-10-11 15:54 ` [PATCH 4/9] nvme: add nvme_auth_derive_tls_psk() Hannes Reinecke
2024-10-11 15:54 ` [PATCH 5/9] nvme-keyring: add nvme_tls_psk_refresh() Hannes Reinecke
2024-10-11 15:54 ` [PATCH 6/9] nvme-tcp: request secure channel concatenation Hannes Reinecke
2024-10-11 15:54 ` [PATCH 7/9] nvme-fabrics: reset admin connection for secure concatenation Hannes Reinecke
2024-10-11 15:54 ` [PATCH 8/9] nvmet-tcp: support secure channel concatenation Hannes Reinecke
2024-10-11 15:54 ` [PATCH 9/9] nvmet: add tls_concat and tls_key debugfs entries Hannes Reinecke
  -- strict thread matches above, loose matches on Subject: below --
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
2024-08-13 11:15 [PATCHv9 0/9] nvme: implement secure concatenation 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-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
2024-07-23  6:24     ` 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=20241014193814.GB1137@sol.localdomain \
    --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