From: Marco Baffo <marco@mandelbit.com>
To: linux-crypto@vger.kernel.org
Cc: herbert@gondor.apana.org.au, davem@davemloft.net,
ebiggers@kernel.org, Jason@zx2c4.com, ardb@kernel.org,
tytso@mit.edu, jaegeuk@kernel.org, linux-fscrypt@vger.kernel.org,
kbusch@kernel.org, axboe@kernel.dk, hch@lst.de, sagi@grimberg.me,
hare@suse.de, linux-nvme@lists.infradead.org,
andrew+netdev@lunn.ch, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, antonio@openvpn.net, sd@queasysnail.net,
linux-kernel@vger.kernel.org, Marco Baffo <marco@mandelbit.com>
Subject: [PATCH 3/5] fscrypt: use HKDF library functions
Date: Tue, 21 Jul 2026 16:06:42 +0200 [thread overview]
Message-ID: <20260721140644.780006-4-marco@mandelbit.com> (raw)
In-Reply-To: <20260721140644.780006-1-marco@mandelbit.com>
Convert fscrypt to the common HKDF-SHA512 helpers without changing its
derived keys. The info bytes are processed in the same order as before.
An empty salt is equivalent to the previous 64-byte all-zero salt after
HMAC key padding.
Signed-off-by: Marco Baffo <marco@mandelbit.com>
---
fs/crypto/hkdf.c | 56 +++++++++++-------------------------------------
1 file changed, 13 insertions(+), 43 deletions(-)
diff --git a/fs/crypto/hkdf.c b/fs/crypto/hkdf.c
index 706f56d0076e..7df7d466a3e4 100644
--- a/fs/crypto/hkdf.c
+++ b/fs/crypto/hkdf.c
@@ -1,8 +1,6 @@
// 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".
+ * Key derivation using HKDF-SHA512.
*
* This is used to derive keys from the fscrypt master keys (or from the
* "software secrets" which hardware derives from the fscrypt master keys, in
@@ -11,6 +9,8 @@
* Copyright 2019 Google LLC
*/
+#include <crypto/hkdf.h>
+
#include "fscrypt_private.h"
/*
@@ -24,19 +24,11 @@
* HKDF-SHA512 being much faster than HKDF-SHA256, as the longer digest size of
* SHA-512 causes HKDF-Expand to only need to do one iteration rather than two.
*/
-#define HKDF_HASHLEN SHA512_DIGEST_SIZE
/*
- * 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.
- * 2. HKDF-Expand: expand the pseudorandom key into output keying material of
- * any length, parameterized by an application-specific info string.
- *
* HKDF-Extract can be skipped if the input is already a pseudorandom key of
- * length HKDF_HASHLEN bytes. However, cipher modes other than AES-256-XTS take
- * shorter keys, and we don't want to force users of those modes to provide
+ * length SHA512_DIGEST_SIZE bytes. However, cipher modes other than AES-256-XTS
+ * take shorter keys, and we don't want to force users of those modes to provide
* unnecessarily long master keys. Thus fscrypt still does HKDF-Extract. No
* salt is used, since fscrypt master keys should already be pseudorandom and
* there's no way to persist a random salt per master key from kernel mode.
@@ -50,13 +42,7 @@
void fscrypt_init_hkdf(struct hmac_sha512_key *hkdf, const u8 *master_key,
unsigned int master_key_size)
{
- static const u8 default_salt[HKDF_HASHLEN];
- u8 prk[HKDF_HASHLEN];
-
- hmac_sha512_usingrawkey(default_salt, sizeof(default_salt),
- master_key, master_key_size, prk);
- hmac_sha512_preparekey(hkdf, prk, sizeof(prk));
- memzero_explicit(prk, sizeof(prk));
+ hkdf_sha512_extract(hkdf, NULL, 0, master_key, master_key_size);
}
/*
@@ -73,28 +59,12 @@ void fscrypt_hkdf_expand(const struct hmac_sha512_key *hkdf, u8 context,
const u8 *info, unsigned int infolen,
u8 *okm, unsigned int okmlen)
{
- struct hmac_sha512_ctx ctx;
- u8 counter = 1;
- u8 tmp[HKDF_HASHLEN];
-
- WARN_ON_ONCE(okmlen > 255 * HKDF_HASHLEN);
+ const struct hkdf_seg info_segs[] = {
+ { .data = "fscrypt\0", .len = 8 },
+ { .data = &context, .len = 1 },
+ { .data = info, .len = infolen },
+ };
- for (unsigned int i = 0; i < okmlen; i += HKDF_HASHLEN) {
- hmac_sha512_init(&ctx, hkdf);
- if (i != 0)
- hmac_sha512_update(&ctx, &okm[i - HKDF_HASHLEN],
- HKDF_HASHLEN);
- hmac_sha512_update(&ctx, "fscrypt\0", 8);
- hmac_sha512_update(&ctx, &context, 1);
- hmac_sha512_update(&ctx, info, infolen);
- hmac_sha512_update(&ctx, &counter, 1);
- if (okmlen - i < HKDF_HASHLEN) {
- hmac_sha512_final(&ctx, tmp);
- memcpy(&okm[i], tmp, okmlen - i);
- memzero_explicit(tmp, sizeof(tmp));
- } else {
- hmac_sha512_final(&ctx, &okm[i]);
- }
- counter++;
- }
+ hkdf_sha512_expand(hkdf, info_segs, ARRAY_SIZE(info_segs),
+ okm, okmlen);
}
--
2.43.0
next prev parent reply other threads:[~2026-07-21 14:08 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-21 14:06 [PATCH 0/5] lib/crypto: add HKDF and convert fscrypt and NVMe Marco Baffo
2026-07-21 14:06 ` [PATCH 1/5] lib/crypto: add HKDF-SHA{256,384,512} Marco Baffo
2026-07-21 14:06 ` [PATCH 2/5] lib/crypto: tests: add HKDF KUnit tests Marco Baffo
2026-07-21 14:06 ` Marco Baffo [this message]
2026-07-21 14:06 ` [PATCH 4/5] nvme-auth: use HKDF library functions for TLS PSK derivation Marco Baffo
2026-07-21 14:06 ` [RFC PATCH 5/5] ovpn: use HKDF library functions for epoch key derivation Marco Baffo
2026-07-21 15:06 ` [PATCH 0/5] lib/crypto: add HKDF and convert fscrypt and NVMe Eric Biggers
2026-08-04 9:16 ` Marco Baffo
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=20260721140644.780006-4-marco@mandelbit.com \
--to=marco@mandelbit.com \
--cc=Jason@zx2c4.com \
--cc=andrew+netdev@lunn.ch \
--cc=antonio@openvpn.net \
--cc=ardb@kernel.org \
--cc=axboe@kernel.dk \
--cc=davem@davemloft.net \
--cc=ebiggers@kernel.org \
--cc=edumazet@google.com \
--cc=hare@suse.de \
--cc=hch@lst.de \
--cc=herbert@gondor.apana.org.au \
--cc=jaegeuk@kernel.org \
--cc=kbusch@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-fscrypt@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=pabeni@redhat.com \
--cc=sagi@grimberg.me \
--cc=sd@queasysnail.net \
--cc=tytso@mit.edu \
/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.