Some more info, sorry for the delay. Currently, as epxlained eralier, the HKDF is approved only in specific cases (from SP.800-56C rev 2), which is why I asked Jeff to inquire if KDF agility was possible for fscrypt. That said, we are also trying to get NIST to approve HKDF for use in SP800-133 covered scenarios (Symmetric Keys Derived from Pre-Existing Key), which is the case applicable to fscrypt (afaict). SP.800-133 currently only allows KDFs as defined in SP.800-108, but there is hope that SP.800-56C rev 2 KDFs can be alloed also, after all they are already allowed for key-agreement schemes. Hope this clears a bit why we inquired, it is just in case, for whatever reason, NIST decided not to approve or delays a decision; to be clear, there is nothing wrong in HKDF itself that we know of. HTH, Simo. On Wed, 2021-02-10 at 15:12 -0500, Simo Sorce wrote: > 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> > > > -- Simo Sorce RHEL Crypto Team Red Hat, Inc
|