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 <[email protected]> > --- > 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
