| Message ID | 20170421110306.3343-1-gmazyland@gmail.com (mailing list archive) |
|---|---|
| State | Accepted |
| Delegated to: | Herbert Xu |
| Headers | show |
Milan Broz <gmazyland@gmail.com> wrote: > The cipher_null is not a real cipher, FIPS mode should not restrict its use. > > It is used for several tests (for example in cryptsetup testsuite) and also > temporarily for reencryption of not yet encrypted device in cryptsetup-reencrypt tool. > > Problem is easily reproducible with > cryptsetup benchmark -c null > > Signed-off-by: Milan Broz <gmazyland@gmail.com> Stephan?
Am Freitag, 21. April 2017, 14:18:20 CEST schrieb Herbert Xu: Hi Herbert, > Milan Broz <gmazyland@gmail.com> wrote: > > The cipher_null is not a real cipher, FIPS mode should not restrict its > > use. > > > > It is used for several tests (for example in cryptsetup testsuite) and > > also > > temporarily for reencryption of not yet encrypted device in > > cryptsetup-reencrypt tool. > > > > Problem is easily reproducible with > > > > cryptsetup benchmark -c null > > > > Signed-off-by: Milan Broz <gmazyland@gmail.com> > > Stephan? Acked-by: Stephan Müller <smueller@chronox.de> Ciao Stephan
Am Freitag, 21. April 2017, 17:25:41 CEST schrieb Stephan Müller: Hi, > > Acked-by: Stephan Müller <smueller@chronox.de> Just for the records: for FIPS 140-2 rules, cipher_null is to be interpreted as a memcpy on SGLs. Thus it is no cipher even though it sounds like one. cipher_null is also needed for seqiv which is required for rfc4106(gcm(aes)), which is an approved cipher. Also, it is needed for authenc() which uses it for copying the AAD from src to dst. That said, cipher_null must not be used for "encryption" operation but rather for handling data that is not subjected to FIPS 140-2 rules. Ciao Stephan
On Sat, Apr 22, 2017 at 2:56 AM, Stephan Müller <smueller@chronox.de> wrote: > Am Freitag, 21. April 2017, 17:25:41 CEST schrieb Stephan Müller: > Just for the records: for FIPS 140-2 rules, cipher_null is to be interpreted > as a memcpy on SGLs. Thus it is no cipher even though it sounds like one. > > cipher_null is also needed for seqiv which is required for rfc4106(gcm(aes)), > which is an approved cipher. Also, it is needed for authenc() which uses it > for copying the AAD from src to dst. > > That said, cipher_null must not be used for "encryption" operation but rather > for handling data that is not subjected to FIPS 140-2 rules. In the FreeS/WAN project, back around the turn of the century, we refused to implement several things required by the RFCs because we thought they were insecure: null cipher, single DES & 768-bit DH Group 1. At that time, not having DES did cause some problems in interoperating with other IPsec implementations, but I doubt it would today. Neither of the other dropped items caused any problems at all. Today I'd say drop all of those plus the 1024-bit Group 2, and then look at whether others should go as well. As of 2001 or so, the 1536-bit Group 5 was very widely used, so dropping it might well be problematic, but I am not certain if it is either secure or widely used now.
On Sat, Apr 22, 2017 at 3:54 PM, Sandy Harris <sandyinchina@gmail.com> wrote: > In the FreeS/WAN project, back around the turn of the century, > we refused to implement several things required by the RFCs Link to documentation: http://www.freeswan.org/freeswan_trees/freeswan-2.06/doc/compat.html#dropped
Am Samstag, 22. April 2017, 09:54:08 CEST schrieb Sandy Harris: Hi Sandy, > In the FreeS/WAN project, back around the turn of the century, > we refused to implement several things required by the RFCs > because we thought they were insecure: null cipher, single > DES & 768-bit DH Group 1. > > At that time, not having DES did cause some problems in > interoperating with other IPsec implementations, but I > doubt it would today. Neither of the other dropped items > caused any problems at all. > > Today I'd say drop all of those plus the 1024-bit Group 2, > and then look at whether others should go as well. As of > 2001 or so, the 1536-bit Group 5 was very widely used, > so dropping it might well be problematic, but I am not > certain if it is either secure or widely used now. This approach is fully appropriate and I strongly support that. However, the kernel crypto API has a need of a memcpy over SGLs, because the entire crypto API operates on SGLs. There are valid use cases. The one I am currently working on are AEAD ciphers where we want to copy the AAD from the src SGL to the dst SGL. Instead of walking through the SGLs in my code and invoke the memcpy, I simply use the null cipher. What I would like to say is that there are valid use cases of the null cipher which do not impair security constraints. For those use cases, the null cipher should and must be allowed. For all other use cases, including the "encryption operation" in IPSEC or dm- crypt, it should never be used. Ciao Stephan
Milan Broz <gmazyland@gmail.com> wrote: > The cipher_null is not a real cipher, FIPS mode should not restrict its use. > > It is used for several tests (for example in cryptsetup testsuite) and also > temporarily for reencryption of not yet encrypted device in cryptsetup-reencrypt tool. > > Problem is easily reproducible with > cryptsetup benchmark -c null > > Signed-off-by: Milan Broz <gmazyland@gmail.com> Patch applied. Thanks.
diff --git a/crypto/testmgr.c b/crypto/testmgr.c index f9c378af3907..5075e4d982ee 100644 --- a/crypto/testmgr.c +++ b/crypto/testmgr.c @@ -2875,6 +2875,7 @@ static const struct alg_test_desc alg_test_descs[] = { }, { .alg = "ecb(cipher_null)", .test = alg_test_null, + .fips_allowed = 1, }, { .alg = "ecb(des)", .test = alg_test_skcipher,
The cipher_null is not a real cipher, FIPS mode should not restrict its use. It is used for several tests (for example in cryptsetup testsuite) and also temporarily for reencryption of not yet encrypted device in cryptsetup-reencrypt tool. Problem is easily reproducible with cryptsetup benchmark -c null Signed-off-by: Milan Broz <gmazyland@gmail.com> --- crypto/testmgr.c | 1 + 1 file changed, 1 insertion(+)