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