[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

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

[kernel test robot]

Hi Li,

[This is a private test report for your RFC patch.]
kernel test robot noticed the following build errors:

[auto build test ERROR on herbert-cryptodev-2.6/master]
[also build test ERROR on herbert-crypto-2.6/master linus/master v6.18-rc7 next-20251128]
[cannot apply to brauner-vfs/vfs.all]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Li-Tian/crypto-hkdf-Fix-salt-length-short-issue-in-FIPS-mode/20251126-214458
base:   https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master
patch link:    https://lore.kernel.org/r/20251126134222.22083-1-litian%40redhat.com
patch subject: [PATCH RFC] crypto/hkdf: Fix salt length short issue in FIPS mode
config: arm-randconfig-001-20251129 (https://download.01.org/0day-ci/archive/20251129/202511290734.V82ilOWk-lkp@intel.com/config)
compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251129/202511290734.V82ilOWk-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202511290734.V82ilOWk-lkp@intel.com/

All errors (new ones prefixed by >>):

>> fs/crypto/hkdf.c:40:31: error: use of undeclared identifier 'HKDF_HASHLEN'
      40 |         static const u8 default_salt[HKDF_HASHLEN];
         |                                      ^
   fs/crypto/hkdf.c:41:9: error: use of undeclared identifier 'HKDF_HASHLEN'
      41 |         u8 prk[HKDF_HASHLEN];
         |                ^
   fs/crypto/hkdf.c:65:9: error: use of undeclared identifier 'HKDF_HASHLEN'
      65 |         u8 tmp[HKDF_HASHLEN];
         |                ^
   fs/crypto/hkdf.c:67:30: error: use of undeclared identifier 'HKDF_HASHLEN'
      67 |         WARN_ON_ONCE(okmlen > 255 * HKDF_HASHLEN);
         |                                     ^
   fs/crypto/hkdf.c:69:44: error: use of undeclared identifier 'HKDF_HASHLEN'
      69 |         for (unsigned int i = 0; i < okmlen; i += HKDF_HASHLEN) {
         |                                                   ^
   fs/crypto/hkdf.c:72:38: error: use of undeclared identifier 'HKDF_HASHLEN'
      72 |                         hmac_sha512_update(&ctx, &okm[i - HKDF_HASHLEN],
         |                                                           ^
   fs/crypto/hkdf.c:73:9: error: use of undeclared identifier 'HKDF_HASHLEN'
      73 |                                            HKDF_HASHLEN);
         |                                            ^
   fs/crypto/hkdf.c:78:20: error: use of undeclared identifier 'HKDF_HASHLEN'
      78 |                 if (okmlen - i < HKDF_HASHLEN) {
         |                                  ^
   8 errors generated.


vim +/HKDF_HASHLEN +40 fs/crypto/hkdf.c

c1144c9b8ad94d8 Eric Biggers    2019-08-04  15  
c1144c9b8ad94d8 Eric Biggers    2019-08-04  16  /*
c1144c9b8ad94d8 Eric Biggers    2019-08-04  17   * HKDF consists of two steps:
c1144c9b8ad94d8 Eric Biggers    2019-08-04  18   *
c1144c9b8ad94d8 Eric Biggers    2019-08-04  19   * 1. HKDF-Extract: extract a pseudorandom key of length HKDF_HASHLEN bytes from
c1144c9b8ad94d8 Eric Biggers    2019-08-04  20   *    the input keying material and optional salt.
c1144c9b8ad94d8 Eric Biggers    2019-08-04  21   * 2. HKDF-Expand: expand the pseudorandom key into output keying material of
c1144c9b8ad94d8 Eric Biggers    2019-08-04  22   *    any length, parameterized by an application-specific info string.
c1144c9b8ad94d8 Eric Biggers    2019-08-04  23   *
c1144c9b8ad94d8 Eric Biggers    2019-08-04  24   * HKDF-Extract can be skipped if the input is already a pseudorandom key of
c1144c9b8ad94d8 Eric Biggers    2019-08-04  25   * length HKDF_HASHLEN bytes.  However, cipher modes other than AES-256-XTS take
c1144c9b8ad94d8 Eric Biggers    2019-08-04  26   * shorter keys, and we don't want to force users of those modes to provide
c1144c9b8ad94d8 Eric Biggers    2019-08-04  27   * unnecessarily long master keys.  Thus fscrypt still does HKDF-Extract.  No
c1144c9b8ad94d8 Eric Biggers    2019-08-04  28   * salt is used, since fscrypt master keys should already be pseudorandom and
c1144c9b8ad94d8 Eric Biggers    2019-08-04  29   * there's no way to persist a random salt per master key from kernel mode.
c1144c9b8ad94d8 Eric Biggers    2019-08-04  30   */
c1144c9b8ad94d8 Eric Biggers    2019-08-04  31  
c1144c9b8ad94d8 Eric Biggers    2019-08-04  32  /*
19591f7e781fd1e Eric Biggers    2025-09-05  33   * Compute HKDF-Extract using 'master_key' as the input keying material, and
19591f7e781fd1e Eric Biggers    2025-09-05  34   * prepare the resulting HMAC key in 'hkdf'.  Afterwards, 'hkdf' can be used for
19591f7e781fd1e Eric Biggers    2025-09-05  35   * HKDF-Expand many times without having to recompute HKDF-Extract each time.
c1144c9b8ad94d8 Eric Biggers    2019-08-04  36   */
19591f7e781fd1e Eric Biggers    2025-09-05  37  void fscrypt_init_hkdf(struct hmac_sha512_key *hkdf, const u8 *master_key,
c1144c9b8ad94d8 Eric Biggers    2019-08-04  38  		       unsigned int master_key_size)
c1144c9b8ad94d8 Eric Biggers    2019-08-04  39  {
3241cd0c6c17919 Hannes Reinecke 2025-02-24 @40  	static const u8 default_salt[HKDF_HASHLEN];
c1144c9b8ad94d8 Eric Biggers    2019-08-04  41  	u8 prk[HKDF_HASHLEN];
c1144c9b8ad94d8 Eric Biggers    2019-08-04  42  
19591f7e781fd1e Eric Biggers    2025-09-05  43  	hmac_sha512_usingrawkey(default_salt, sizeof(default_salt),
19591f7e781fd1e Eric Biggers    2025-09-05  44  				master_key, master_key_size, prk);
19591f7e781fd1e Eric Biggers    2025-09-05  45  	hmac_sha512_preparekey(hkdf, prk, sizeof(prk));
c1144c9b8ad94d8 Eric Biggers    2019-08-04  46  	memzero_explicit(prk, sizeof(prk));
c1144c9b8ad94d8 Eric Biggers    2019-08-04  47  }
c1144c9b8ad94d8 Eric Biggers    2019-08-04  48  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

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

[kernel test robot]

Hi Li,

[This is a private test report for your RFC patch.]
kernel test robot noticed the following build errors:

[auto build test ERROR on herbert-cryptodev-2.6/master]
[also build test ERROR on herbert-crypto-2.6/master linus/master v6.18-rc7 next-20251128]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Li-Tian/crypto-hkdf-Fix-salt-length-short-issue-in-FIPS-mode/20251126-214458
base:   https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master
patch link:    https://lore.kernel.org/r/20251126134222.22083-1-litian%40redhat.com
patch subject: [PATCH RFC] crypto/hkdf: Fix salt length short issue in FIPS mode
config: arc-randconfig-001-20251129 (https://download.01.org/0day-ci/archive/20251129/202511290809.8Fr4ja5n-lkp@intel.com/config)
compiler: arc-linux-gcc (GCC) 8.5.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251129/202511290809.8Fr4ja5n-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202511290809.8Fr4ja5n-lkp@intel.com/

All error/warnings (new ones prefixed by >>):

   fs/crypto/hkdf.c: In function 'fscrypt_init_hkdf':
>> fs/crypto/hkdf.c:40:31: error: 'HKDF_HASHLEN' undeclared (first use in this function); did you mean 'DT_HASH'?
     static const u8 default_salt[HKDF_HASHLEN];
                                  ^~~~~~~~~~~~
                                  DT_HASH
   fs/crypto/hkdf.c:40:31: note: each undeclared identifier is reported only once for each function it appears in
>> fs/crypto/hkdf.c:41:5: warning: unused variable 'prk' [-Wunused-variable]
     u8 prk[HKDF_HASHLEN];
        ^~~
>> fs/crypto/hkdf.c:40:18: warning: unused variable 'default_salt' [-Wunused-variable]
     static const u8 default_salt[HKDF_HASHLEN];
                     ^~~~~~~~~~~~
   fs/crypto/hkdf.c: In function 'fscrypt_hkdf_expand':
   fs/crypto/hkdf.c:65:9: error: 'HKDF_HASHLEN' undeclared (first use in this function); did you mean 'DT_HASH'?
     u8 tmp[HKDF_HASHLEN];
            ^~~~~~~~~~~~
            DT_HASH
>> fs/crypto/hkdf.c:65:5: warning: unused variable 'tmp' [-Wunused-variable]
     u8 tmp[HKDF_HASHLEN];
        ^~~


vim +40 fs/crypto/hkdf.c

c1144c9b8ad94d Eric Biggers    2019-08-04  15  
c1144c9b8ad94d Eric Biggers    2019-08-04  16  /*
c1144c9b8ad94d Eric Biggers    2019-08-04  17   * HKDF consists of two steps:
c1144c9b8ad94d Eric Biggers    2019-08-04  18   *
c1144c9b8ad94d Eric Biggers    2019-08-04  19   * 1. HKDF-Extract: extract a pseudorandom key of length HKDF_HASHLEN bytes from
c1144c9b8ad94d Eric Biggers    2019-08-04  20   *    the input keying material and optional salt.
c1144c9b8ad94d Eric Biggers    2019-08-04  21   * 2. HKDF-Expand: expand the pseudorandom key into output keying material of
c1144c9b8ad94d Eric Biggers    2019-08-04  22   *    any length, parameterized by an application-specific info string.
c1144c9b8ad94d Eric Biggers    2019-08-04  23   *
c1144c9b8ad94d Eric Biggers    2019-08-04  24   * HKDF-Extract can be skipped if the input is already a pseudorandom key of
c1144c9b8ad94d Eric Biggers    2019-08-04  25   * length HKDF_HASHLEN bytes.  However, cipher modes other than AES-256-XTS take
c1144c9b8ad94d Eric Biggers    2019-08-04  26   * shorter keys, and we don't want to force users of those modes to provide
c1144c9b8ad94d Eric Biggers    2019-08-04  27   * unnecessarily long master keys.  Thus fscrypt still does HKDF-Extract.  No
c1144c9b8ad94d Eric Biggers    2019-08-04  28   * salt is used, since fscrypt master keys should already be pseudorandom and
c1144c9b8ad94d Eric Biggers    2019-08-04  29   * there's no way to persist a random salt per master key from kernel mode.
c1144c9b8ad94d Eric Biggers    2019-08-04  30   */
c1144c9b8ad94d Eric Biggers    2019-08-04  31  
c1144c9b8ad94d Eric Biggers    2019-08-04  32  /*
19591f7e781fd1 Eric Biggers    2025-09-05  33   * Compute HKDF-Extract using 'master_key' as the input keying material, and
19591f7e781fd1 Eric Biggers    2025-09-05  34   * prepare the resulting HMAC key in 'hkdf'.  Afterwards, 'hkdf' can be used for
19591f7e781fd1 Eric Biggers    2025-09-05  35   * HKDF-Expand many times without having to recompute HKDF-Extract each time.
c1144c9b8ad94d Eric Biggers    2019-08-04  36   */
19591f7e781fd1 Eric Biggers    2025-09-05  37  void fscrypt_init_hkdf(struct hmac_sha512_key *hkdf, const u8 *master_key,
c1144c9b8ad94d Eric Biggers    2019-08-04  38  		       unsigned int master_key_size)
c1144c9b8ad94d Eric Biggers    2019-08-04  39  {
3241cd0c6c1791 Hannes Reinecke 2025-02-24 @40  	static const u8 default_salt[HKDF_HASHLEN];
c1144c9b8ad94d Eric Biggers    2019-08-04 @41  	u8 prk[HKDF_HASHLEN];
c1144c9b8ad94d Eric Biggers    2019-08-04  42  
19591f7e781fd1 Eric Biggers    2025-09-05  43  	hmac_sha512_usingrawkey(default_salt, sizeof(default_salt),
19591f7e781fd1 Eric Biggers    2025-09-05  44  				master_key, master_key_size, prk);
19591f7e781fd1 Eric Biggers    2025-09-05  45  	hmac_sha512_preparekey(hkdf, prk, sizeof(prk));
c1144c9b8ad94d Eric Biggers    2019-08-04  46  	memzero_explicit(prk, sizeof(prk));
c1144c9b8ad94d Eric Biggers    2019-08-04  47  }
c1144c9b8ad94d Eric Biggers    2019-08-04  48  
c1144c9b8ad94d Eric Biggers    2019-08-04  49  /*
19591f7e781fd1 Eric Biggers    2025-09-05  50   * HKDF-Expand (RFC 5869 section 2.3).  Expand the HMAC key 'hkdf' into 'okmlen'
c1144c9b8ad94d Eric Biggers    2019-08-04  51   * bytes of output keying material parameterized by the application-specific
c1144c9b8ad94d Eric Biggers    2019-08-04  52   * 'info' of length 'infolen' bytes, prefixed by "fscrypt\0" and the 'context'
c1144c9b8ad94d Eric Biggers    2019-08-04  53   * byte.  This is thread-safe and may be called by multiple threads in parallel.
c1144c9b8ad94d Eric Biggers    2019-08-04  54   *
c1144c9b8ad94d Eric Biggers    2019-08-04  55   * ('context' isn't part of the HKDF specification; it's just a prefix fscrypt
c1144c9b8ad94d Eric Biggers    2019-08-04  56   * adds to its application-specific info strings to guarantee that it doesn't
c1144c9b8ad94d Eric Biggers    2019-08-04  57   * accidentally repeat an info string when using HKDF for different purposes.)
c1144c9b8ad94d Eric Biggers    2019-08-04  58   */
19591f7e781fd1 Eric Biggers    2025-09-05  59  void fscrypt_hkdf_expand(const struct hmac_sha512_key *hkdf, u8 context,
c1144c9b8ad94d Eric Biggers    2019-08-04  60  			 const u8 *info, unsigned int infolen,
c1144c9b8ad94d Eric Biggers    2019-08-04  61  			 u8 *okm, unsigned int okmlen)
c1144c9b8ad94d Eric Biggers    2019-08-04  62  {
19591f7e781fd1 Eric Biggers    2025-09-05  63  	struct hmac_sha512_ctx ctx;
19591f7e781fd1 Eric Biggers    2025-09-05  64  	u8 counter = 1;
19591f7e781fd1 Eric Biggers    2025-09-05 @65  	u8 tmp[HKDF_HASHLEN];

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki