[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20251126134222.22083-1-litian@redhat.com>
Date: Wed, 26 Nov 2025 21:42:22 +0800
From: Li Tian <litian@...hat.com>
To: linux-crypto@...r.kernel.org
Cc: linux-kernel@...r.kernel.org,
linux-fscrypt@...r.kernel.org,
Herbert Xu <herbert@...dor.apana.org.au>,
"David S . Miller" <davem@...emloft.net>,
Eric Biggers <ebiggers@...nel.org>,
"Theodore Y . Ts'o" <tytso@....edu>,
Jaegeuk Kim <jaegeuk@...nel.org>
Subject: [PATCH RFC] crypto/hkdf: Fix salt length short issue in FIPS mode
Under FIPS mode, the hkdf test fails because salt is required
to be at least 32 bytes long. Pad salt with 0's.
Signed-off-by: Li Tian <litian@...hat.com>
---
crypto/hkdf.c | 11 ++++++++++-
fs/crypto/hkdf.c | 13 -------------
include/crypto/hkdf.h | 13 +++++++++++++
3 files changed, 23 insertions(+), 14 deletions(-)
diff --git a/crypto/hkdf.c b/crypto/hkdf.c
index 82d1b32ca6ce..9af0ef4dfb35 100644
--- a/crypto/hkdf.c
+++ b/crypto/hkdf.c
@@ -46,6 +46,15 @@ int hkdf_extract(struct crypto_shash *hmac_tfm, const u8 *ikm,
u8 *prk)
{
int err;
+ u8 tmp_salt[HKDF_HASHLEN];
+
+ if (saltlen < HKDF_HASHLEN) {
+ /* Copy salt and pad with zeros to HashLen */
+ memcpy(tmp_salt, salt, saltlen);
+ memset(tmp_salt + saltlen, 0, HKDF_HASHLEN - saltlen);
+ salt = tmp_salt;
+ saltlen = HKDF_HASHLEN;
+ }
err = crypto_shash_setkey(hmac_tfm, salt, saltlen);
if (!err)
@@ -151,7 +160,7 @@ struct hkdf_testvec {
*/
static const struct hkdf_testvec hkdf_sha256_tv[] = {
{
- .test = "basic hdkf test",
+ .test = "basic hkdf test",
.ikm = "\x0b\x0b\x0b\x0b\x0b\x0b\x0b\x0b\x0b\x0b\x0b\x0b\x0b\x0b\x0b\x0b"
"\x0b\x0b\x0b\x0b\x0b\x0b",
.ikm_size = 22,
diff --git a/fs/crypto/hkdf.c b/fs/crypto/hkdf.c
index 706f56d0076e..5e4844c1d3d7 100644
--- a/fs/crypto/hkdf.c
+++ b/fs/crypto/hkdf.c
@@ -13,19 +13,6 @@
#include "fscrypt_private.h"
-/*
- * HKDF supports any unkeyed cryptographic hash algorithm, but fscrypt uses
- * SHA-512 because it is well-established, secure, and reasonably efficient.
- *
- * HKDF-SHA256 was also considered, as its 256-bit security strength would be
- * sufficient here. A 512-bit security strength is "nice to have", though.
- * Also, on 64-bit CPUs, SHA-512 is usually just as fast as SHA-256. In the
- * common case of deriving an AES-256-XTS key (512 bits), that can result in
- * 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:
*
diff --git a/include/crypto/hkdf.h b/include/crypto/hkdf.h
index 6a9678f508f5..7ef55ce875e2 100644
--- a/include/crypto/hkdf.h
+++ b/include/crypto/hkdf.h
@@ -11,6 +11,19 @@
#include <crypto/hash.h>
+/*
+ * HKDF supports any unkeyed cryptographic hash algorithm, but fscrypt uses
+ * SHA-512 because it is well-established, secure, and reasonably efficient.
+ *
+ * HKDF-SHA256 was also considered, as its 256-bit security strength would be
+ * sufficient here. A 512-bit security strength is "nice to have", though.
+ * Also, on 64-bit CPUs, SHA-512 is usually just as fast as SHA-256. In the
+ * common case of deriving an AES-256-XTS key (512 bits), that can result in
+ * 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
+
int hkdf_extract(struct crypto_shash *hmac_tfm, const u8 *ikm,
unsigned int ikmlen, const u8 *salt, unsigned int saltlen,
u8 *prk);
--
2.50.0
Powered by blists - more mailing lists