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