Very quickly, our current assessment is that HKDF is approved to be used only within the protocols explicitly approved in FIPS 140-3 IG and 800-135r1, which include TLS 1.3 but not generally. I will come back with more info an pointers asap. Simo. On Wed, 2021-02-10 at 15:07 -0500, Thibaud Ecarot wrote: > Hi folks, > > HKDF is widely used in various HSM so this is necessarily compliant > with FIPS 140-3 or 140-2. I have in mind Thales Luna HSM. I am curious > why this statement was made on your side. > > Thanks Jeff. > > Thibaud > > > Le mer. 10 févr. 2021, à 14 h 30, Jeff Layton <jlayton@xxxxxxxxxx> a écrit : > > On Wed, 2021-02-10 at 09:49 -0800, Eric Biggers wrote: > > > On Wed, Feb 10, 2021 at 08:14:08AM -0500, Jeff Layton wrote: > > > > Hi Eric, > > > > > > > > I'm still working on the ceph+fscrypt patches (it's been slow going, but > > > > I am making progress). Eventually RH would like to ship this as a > > > > feature, but there is one potential snag that -- a lot of our customers > > > > need their boxes to be FIPS-enabled [1]. > > > > > > > > Most of the algorithms and implementations that fscrypt use are OK, but > > > > HKDF is not approved outside of TLS 1.3. The quote from our lab folks > > > > is: > > > > > > > > "HKDF is not approved as a general-purpose KDF, but only for SP800-56C > > > > rev2 compliant use. That means that HKDF is only to be used to derive a > > > > key from a ECDH/DH or RSA-wrapped shared secret. This includes TLS 1.3." > > > > > > > > Would you be amenable to allowing the KDF to be pluggable in some > > > > fashion, like the filename and content encryption algorithms are? It > > > > would be nice if we didn't have to disable this feature on FIPS-enabled > > > > boxes. > > > > > > > > [1]: https://www.nist.gov/itl/fips-general-information > > > > > > > > Thanks! > > > > -- > > > > Jeff Layton <jlayton@xxxxxxxxxx> > > > > > > Can you elaborate on why you think that HKDF isn't FIPS approved? It's been > > > recommended by NIST 800-56C since 2011, and almost any cryptographic application > > > developed within the last 10 years is likely to be using HKDF, if it needs a > > > non-passphrase based KDF. > > > > > > In fact one of the reasons for switching from the weird AES-ECB-based KDF used > > > in v1 encryption policies to HKDF-SHA512 is that HKDF is much more standard. > > > > > > Are you sure you're looking at the latest version of FIPS? > > > > > > And if HKDF isn't approved, what *is* approved, exactly? > > > > > > As far as supporting a new KDF if it were necessary, one of the reserved fields > > > in fscrypt_add_key_arg, fscrypt_policy_v2, fscrypt_context_v2, and > > > fscrypt_provisioning_key_payload could be used to specify the KDF. This would > > > the first time someone has done so, so there would also be work required to add > > > a '--kdf' parameter to the userspace tools, and make the kernel keep track of > > > the keys for each KDF version separately. Plus maybe some other things too. > > > > > > I did figure that a new KDF might have to be supported eventually, but not to > > > replace the HKDF construction (which is provably secure), but rather if someone > > > wants to use something other than SHA-512 (which isn't provably secure). I'm > > > not too enthusiastic about adding another KDF that uses the same underlying hash > > > function, as there would be no technical reason for this. > > > > > > Note that the fscrypt userspace tool (https://github.com/google/fscrypt) also > > > uses HKDF for a key derivation step in userspace, separately from the kernel. > > > I suppose you'd want to change that too? > > > > > > > > > > Bah, I meant to cc Simo on this since he's the one who brought it up. I > > know just enough to be dangerous. > > > > Simo, can you answer Eric's questions, or loop in someone who can? > > > > Thanks, > > -- > > Jeff Layton <jlayton@xxxxxxxxxx> > > > >
|