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> > -- Thibaud ECAROT
|