* authenc methods vs FIPS in light of unencrypted associated data @ 2016-06-02 16:01 Marcus Meissner 2016-06-03 6:42 ` Stephan Mueller 0 siblings, 1 reply; 3+ messages in thread From: Marcus Meissner @ 2016-06-02 16:01 UTC (permalink / raw) To: herbert, davem, linux-crypto, linux-kernel, smueller Hi, In February I already tagged some authenc ciphers for FIPS compatibility. I currently revisit this to get testmgr running all the tests in strict FIPS mode. The authenc() class is troublesome. There is a HASH + ENC part of this method, but you can also add associated data, which is not encrypted. (using the ctx->null cipher in crypto/authenc.c) But in FIPS mode the crypto_authenc_init_tfm does: null = crypto_get_default_null_skcipher(); which results in error, as the crypto_alloc_blkcipher("ecb(cipher_null)", 0, 0); results in failure due to "ecb(cipher_null)" not FIPS compliant. How to handle this? I think GCM also does not encrypt, just hashes, the associated data, it just does copy the content itself and does not use a virtual cipher. Ciao, Marcus ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: authenc methods vs FIPS in light of unencrypted associated data 2016-06-02 16:01 authenc methods vs FIPS in light of unencrypted associated data Marcus Meissner @ 2016-06-03 6:42 ` Stephan Mueller 2016-06-03 10:12 ` Herbert Xu 0 siblings, 1 reply; 3+ messages in thread From: Stephan Mueller @ 2016-06-03 6:42 UTC (permalink / raw) To: Marcus Meissner; +Cc: herbert, davem, linux-crypto, linux-kernel Am Donnerstag, 2. Juni 2016, 18:01:04 schrieb Marcus Meissner: Hi Marcus, Herbert > Hi, > > In February I already tagged some authenc ciphers for FIPS compatibility. > > I currently revisit this to get testmgr running all the tests in strict FIPS > mode. > > The authenc() class is troublesome. > > There is a HASH + ENC part of this method, but you can also add associated > data, which is not encrypted. (using the ctx->null cipher in > crypto/authenc.c) > > But in FIPS mode the crypto_authenc_init_tfm does: > > null = crypto_get_default_null_skcipher(); > > which results in error, as the crypto_alloc_blkcipher("ecb(cipher_null)", 0, > 0); results in failure due to "ecb(cipher_null)" not FIPS compliant. > > How to handle this? > > I think GCM also does not encrypt, just hashes, the associated data, it just > does copy the content itself and does not use a virtual cipher. This issue points to a more pervasive issue in how the fips_allowed flag is handled. In combined ciphers, the use of individual components separately from the combined cipher may not be allowed in FIPS mode. However, the use of the combined cipher is allowed. For example, GCM is an allowed cipher, but ghash is not. To make GCM usable, the fips_allowed flag is set for ghash which would allow a user to use ghash directly outside GCM, which is not allowed. Therefore, the fips_allowed flag should only be evaluated for the cipher the user invokes. If that cipher employs sub-ordinate ciphers, the fips_allowed flag is not enforced any more. The idea would be that when fips_allowed is set for a cipher, it implies that this cipher with all its sub-ordinate ciphers is allowed even when those individual ciphers would be allowed. Herbert, when using crypto_spawn_*, is there a flag set by the crypto API that the to-be-instantiated cipher is invoked by the kernel crypto API instead of by a user? I would assume that the INTERNAL flag could be of relevance here. If that INTERNAL flag is set, I think that the function alg_test could be changed such that if the INTERNAL flag is set, the fips_allowed flag is not enforced. Ciao Stephan ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: authenc methods vs FIPS in light of unencrypted associated data 2016-06-03 6:42 ` Stephan Mueller @ 2016-06-03 10:12 ` Herbert Xu 0 siblings, 0 replies; 3+ messages in thread From: Herbert Xu @ 2016-06-03 10:12 UTC (permalink / raw) To: Stephan Mueller; +Cc: Marcus Meissner, davem, linux-crypto, linux-kernel On Fri, Jun 03, 2016 at 08:42:31AM +0200, Stephan Mueller wrote: > > Herbert, when using crypto_spawn_*, is there a flag set by the crypto API that > the to-be-instantiated cipher is invoked by the kernel crypto API instead of > by a user? I would assume that the INTERNAL flag could be of relevance here. > If that INTERNAL flag is set, I think that the function alg_test could be > changed such that if the INTERNAL flag is set, the fips_allowed flag is not > enforced. Yes we can certainly set INTERNAL for this case. Thanks, -- Email: Herbert Xu <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2016-06-03 10:12 UTC | newest] Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-06-02 16:01 authenc methods vs FIPS in light of unencrypted associated data Marcus Meissner 2016-06-03 6:42 ` Stephan Mueller 2016-06-03 10:12 ` Herbert Xu
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).