* fscrypt and FIPS @ 2021-02-10 13:14 Jeff Layton 2021-02-10 17:49 ` Eric Biggers 0 siblings, 1 reply; 8+ messages in thread From: Jeff Layton @ 2021-02-10 13:14 UTC (permalink / raw) To: Eric Biggers; +Cc: linux-fscrypt 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@redhat.com> ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: fscrypt and FIPS 2021-02-10 13:14 fscrypt and FIPS Jeff Layton @ 2021-02-10 17:49 ` Eric Biggers 2021-02-10 19:28 ` Jeff Layton 0 siblings, 1 reply; 8+ messages in thread From: Eric Biggers @ 2021-02-10 17:49 UTC (permalink / raw) To: Jeff Layton; +Cc: linux-fscrypt 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@redhat.com> 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: fscrypt and FIPS 2021-02-10 17:49 ` Eric Biggers @ 2021-02-10 19:28 ` Jeff Layton 2021-02-10 20:07 ` Thibaud Ecarot 0 siblings, 1 reply; 8+ messages in thread From: Jeff Layton @ 2021-02-10 19:28 UTC (permalink / raw) To: Eric Biggers, Simo Sorce; +Cc: linux-fscrypt 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@redhat.com> > > 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@redhat.com> ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: fscrypt and FIPS 2021-02-10 19:28 ` Jeff Layton @ 2021-02-10 20:07 ` Thibaud Ecarot 2021-02-10 20:12 ` Simo Sorce 0 siblings, 1 reply; 8+ messages in thread From: Thibaud Ecarot @ 2021-02-10 20:07 UTC (permalink / raw) To: Jeff Layton; +Cc: Eric Biggers, Simo Sorce, linux-fscrypt 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@redhat.com> 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@redhat.com> > > > > 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@redhat.com> > -- Thibaud ECAROT ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: fscrypt and FIPS 2021-02-10 20:07 ` Thibaud Ecarot @ 2021-02-10 20:12 ` Simo Sorce 2021-02-16 17:47 ` Simo Sorce 0 siblings, 1 reply; 8+ messages in thread From: Simo Sorce @ 2021-02-10 20:12 UTC (permalink / raw) To: Thibaud Ecarot, Jeff Layton; +Cc: Eric Biggers, linux-fscrypt 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@redhat.com> 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@redhat.com> > > > > > > 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@redhat.com> > > > > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: fscrypt and FIPS 2021-02-10 20:12 ` Simo Sorce @ 2021-02-16 17:47 ` Simo Sorce 2021-02-16 19:04 ` Eric Biggers 0 siblings, 1 reply; 8+ messages in thread From: Simo Sorce @ 2021-02-16 17:47 UTC (permalink / raw) To: Thibaud Ecarot, Jeff Layton; +Cc: Eric Biggers, linux-fscrypt 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@redhat.com> 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@redhat.com> > > > > > > > > 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@redhat.com> > > > -- Simo Sorce RHEL Crypto Team Red Hat, Inc ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: fscrypt and FIPS 2021-02-16 17:47 ` Simo Sorce @ 2021-02-16 19:04 ` Eric Biggers 2021-02-16 19:22 ` Simo Sorce 0 siblings, 1 reply; 8+ messages in thread From: Eric Biggers @ 2021-02-16 19:04 UTC (permalink / raw) To: Simo Sorce; +Cc: Thibaud Ecarot, Jeff Layton, linux-fscrypt On Tue, Feb 16, 2021 at 12:47:05PM -0500, Simo Sorce wrote: > 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. > Just getting HKDF properly approved seems like a much better approach than doing a lot of work for nothing. Not just for fscrypt but also for everything else using HKDF. - Eric ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: fscrypt and FIPS 2021-02-16 19:04 ` Eric Biggers @ 2021-02-16 19:22 ` Simo Sorce 0 siblings, 0 replies; 8+ messages in thread From: Simo Sorce @ 2021-02-16 19:22 UTC (permalink / raw) To: Eric Biggers; +Cc: Thibaud Ecarot, Jeff Layton, linux-fscrypt On Tue, 2021-02-16 at 11:04 -0800, Eric Biggers wrote: > On Tue, Feb 16, 2021 at 12:47:05PM -0500, Simo Sorce wrote: > > 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. > > > > Just getting HKDF properly approved seems like a much better approach than doing > a lot of work for nothing. Not just for fscrypt but also for everything else > using HKDF. Yes, this would be the ideal outcome! But I have to figure out the "what if" too .. > - Eric > -- Simo Sorce RHEL Crypto Team Red Hat, Inc ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2021-02-16 19:23 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-02-10 13:14 fscrypt and FIPS Jeff Layton 2021-02-10 17:49 ` Eric Biggers 2021-02-10 19:28 ` Jeff Layton 2021-02-10 20:07 ` Thibaud Ecarot 2021-02-10 20:12 ` Simo Sorce 2021-02-16 17:47 ` Simo Sorce 2021-02-16 19:04 ` Eric Biggers 2021-02-16 19:22 ` Simo Sorce
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).