[PATCH RFC] crypto/hkdf: Fix salt length short issue in FIPS mode

[PATCH RFC] crypto/hkdf: Fix salt length short issue in FIPS mode

[Li Tian]

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@redhat.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

Re: [PATCH RFC] crypto/hkdf: Fix salt length short issue in FIPS mode

[Eric Biggers]

On Wed, Nov 26, 2025 at 09:42:22PM +0800, Li Tian wrote:
> 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@redhat.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);

It seems you're trying to pad all the salts to 64 bytes?  That doesn't
make sense.  Just skip the salt_size == 0 test vector when fips_enabled.  

And either way, no need to mess with the code in fs/crypto/.

- Eric

Re: [PATCH RFC] crypto/hkdf: Fix salt length short issue in FIPS mode

[Eric Biggers]

On Thu, Nov 27, 2025 at 09:10:45AM +0800, Li Tian wrote:
> Eric,
> 
> Thanks for reviewing. Not just the salt_size=0 case, but several cases with
> salt < 32 from my tests.
> So simply skip those then?
> 
> BR,
> Li Tian

Why do you think the salt needs to be at least 32 bytes?

- Eric

Re: [PATCH RFC] crypto/hkdf: Fix salt length short issue in FIPS mode

[Eric Biggers]

On Thu, Nov 27, 2025 at 09:24:43AM +0800, Li Tian wrote:
> > Why do you think the salt needs to be at least 32 bytes?
> 
> Forgive my inaccuracy. Under FIPS, salt needs to be at least the hash length
> (32bytes for sha256 and 64bytes for sha512) because NIST requires that the
> HMAC key used in Extract has *full security strength*. 32 is just the
> number I
> tested with.
> 
> Li Tian

It seems that you're confusing the salt with the input keying material.
The entropy for the key comes from the input keying material.  The salt
is a non-secret value that usually is just set to all-zeroes.  In fact,
both users of HKDF in the kernel just set it to all-zeroes.

- Eric

Re: [PATCH RFC] crypto/hkdf: Fix salt length short issue in FIPS mode

[Eric Biggers]

On Thu, Nov 27, 2025 at 11:11:29AM +0800, Li Tian wrote:
> The error message I saw is `basic hdkf test(hmac(sha256-ni)): hkdf_extract
> failed with -22`.
> And I was looking at hmac.c that has `if (fips_enabled && (keylen < 112 /
> 8))...` So I got the impression `crypto_shash_setkey(hmac_tfm, salt,
> saltlen)` in hkdf_extract reached this failure.

112 / 8 is 14, not 32.

Also since v6.17, "hmac(sha256)" no longer uses crypto/hmac.c.  I forgot
to put the keylen < 14 check in the new version in crypto/sha256.c.
That means the test failure you're reporting was already fixed.

If you'd prefer that it be broken again, we can add the key length check
back in.  But this whole thing is just more evidence that it's incorrect
anyway, and it needs to be up to the caller to do a check if it needs
to.  In HKDF the secret is in the input keying material, not the salt.

- Eric