Re: [PATCH] crypto: Allow ecb(cipher_null) in FIPS mode

[Herbert Xu]

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

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH] crypto: Allow ecb(cipher_null) in FIPS mode

[Stephan Müller]

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

Re: [PATCH] crypto: Allow ecb(cipher_null) in FIPS mode

[Sandy Harris]

On Sat, Apr 22, 2017 at 3:54 PM, Sandy Harris  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

Re: [PATCH] crypto: Allow ecb(cipher_null) in FIPS mode

[Sandy Harris]

On Sat, Apr 22, 2017 at 2:56 AM, Stephan Müller  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.

Re: [PATCH] crypto: Allow ecb(cipher_null) in FIPS mode

[Stephan Müller]

Am Freitag, 21. April 2017, 17:25:41 CEST schrieb Stephan Müller:

Hi,

> 
> Acked-by: 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.

Ciao
Stephan

Re: [PATCH] crypto: Allow ecb(cipher_null) in FIPS mode

[Stephan Müller]

Am Freitag, 21. April 2017, 14:18:20 CEST schrieb Herbert Xu:

Hi Herbert,

> Milan Broz  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 
> 
> Stephan?

Acked-by: Stephan Müller 

Ciao
Stephan

Re: [PATCH] crypto: Allow ecb(cipher_null) in FIPS mode

[Herbert Xu]

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

Stephan?
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt