Re: [PATCH] crypto: don't raise alarm for no ctr(aes*) tests in fips mode
On Tuesday 05 May 2009 01:29:05 Herbert Xu wrote: On Mon, May 04, 2009 at 11:45:08PM -0400, Jarod Wilson wrote: Can't keep all the RFCs and SPs and whatnot straight in my head, and they aren't in front of me, but I thought I read that the basic counter increment routine wasn't mandated to be any specific way, the only mandate was to ensure unique values. Suggestions for how to do so were made though. It doesn't matter what is or isn't specified for CTR, the thing that we call ctr is the one that's used for RFC 3686, CCM, and GCM. It is completely pinned down and can be tested. There are two different can be tested contexts here. I completely agree that ctr(aes) is testable within the tcrypt/testmgr context, and sent a patch for such in this thread yesterday. The other context is FIPS CAVS testing, which NIST is saying can't be done, and I was attempting to understand why, which probably only served to muddy the waters. We can definitely do self-tests for ctr(aes). -- Jarod Wilson ja...@redhat.com -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] crypto: don't raise alarm for no ctr(aes*) tests in fips mode
On Tue, Apr 28, 2009 at 09:18:22PM -0400, Jarod Wilson wrote:
Per the NIST AESAVS document, Appendix A[1], it isn't possible to
have automated self-tests for counter-mode AES, but people are
misled to believe something is wrong by the message that says there
is no test for ctr(aes). Simply suppress all 'no test for ctr(aes*'
messages if fips_enabled is set to avoid confusion.
This is not true at all. In our implementation the counter is
set through the IV so it definitely is possible to test counter
mode algorithms in Linux.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} herb...@gondor.apana.org.au
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] crypto: don't raise alarm for no ctr(aes*) tests in fips mode
On Monday 04 May 2009 07:10:10 Herbert Xu wrote: On Tue, Apr 28, 2009 at 09:18:22PM -0400, Jarod Wilson wrote: Per the NIST AESAVS document, Appendix A[1], it isn't possible to have automated self-tests for counter-mode AES, but people are misled to believe something is wrong by the message that says there is no test for ctr(aes). Simply suppress all 'no test for ctr(aes*' messages if fips_enabled is set to avoid confusion. This is not true at all. In our implementation the counter is set through the IV so it definitely is possible to test counter mode algorithms in Linux. Ah... Now I think I see... We can provide an initial counter w/o a problem, but counter incrementation is implementation-specific, so we can't have automated tests that cover multiple enc/dec ops, but if we limit ourselves to just one op, self-tests should be perfectly doable, and NIST SP 800-38A, Appendix F.5 has vectors we could make use of (using just the block #1 values). At least, spot-checking the vectors, I'm getting the expected results for the 1st block. Okay, I'll whip something up in a sec. -- Jarod Wilson ja...@redhat.com -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] crypto: don't raise alarm for no ctr(aes*) tests in fips mode
On 05/04/2009 09:08 PM, Herbert Xu wrote: On Mon, May 04, 2009 at 02:56:58PM -0400, Jarod Wilson wrote: Ah... Now I think I see... We can provide an initial counter w/o a problem, but counter incrementation is implementation-specific, so Not in Linux. If you're going to provide ctr you'd better increment in the way the current implementation does it. Otherwise anything that wraps around it, such as RFC3686 will fail. Another way to put it, only the counter mode as used in RFC 3686, CCM and GCM is what we call ctr. Yeah, no, I didn't mean within Linux we'd have different implementations, I meant e.g. Linux vs. Windows vs. a Cisco router or what have you as far as the base counter increment routine being implementation-specific. Can't keep all the RFCs and SPs and whatnot straight in my head, and they aren't in front of me, but I thought I read that the basic counter increment routine wasn't mandated to be any specific way, the only mandate was to ensure unique values. Suggestions for how to do so were made though. That all seems to coincide with the AESAVS's assertion that automated testing of ctr(aes) isn't possible, if one considers that Monte Carlo tests are typically a standard part of all the other ciphers/modes full validation test suites. I just initially read that to mean that self-tests weren't possible, while I now believe its only referring to exhaustive CAVS testing (i.e. w/MCT) not being possible, due to potential differences from one counter inc routine to another. Its also possible I'm losing my mind though. -- Jarod Wilson ja...@redhat.com -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] crypto: don't raise alarm for no ctr(aes*) tests in fips mode
On Mon, May 04, 2009 at 11:45:08PM -0400, Jarod Wilson wrote:
Can't keep all the RFCs and SPs and whatnot straight in my head, and they
aren't in front of me, but I thought I read that the basic counter increment
routine wasn't mandated to be any specific way, the only mandate was to
ensure unique values. Suggestions for how to do so were made though.
It doesn't matter what is or isn't specified for CTR, the thing
that we call ctr is the one that's used for RFC 3686, CCM, and
GCM. It is completely pinned down and can be tested.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} herb...@gondor.apana.org.au
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] crypto: don't raise alarm for no ctr(aes*) tests in fips mode
On Tue, Apr 28, 2009 at 09:18:22PM -0400, Jarod Wilson wrote: Per the NIST AESAVS document, Appendix A[1], it isn't possible to have automated self-tests for counter-mode AES, but people are misled to believe something is wrong by the message that says there is no test for ctr(aes). Simply suppress all 'no test for ctr(aes*' messages if fips_enabled is set to avoid confusion. Dependent on earlier patch 'crypto: catch base cipher self-test failures in fips mode', which adds the test_done label. [1] http://csrc.nist.gov/groups/STM/cavp/documents/aes/AESAVS.pdf Signed-off-by: Jarod Wilson ja...@redhat.com --- crypto/testmgr.c | 11 +++ 1 files changed, 11 insertions(+), 0 deletions(-) diff --git a/crypto/testmgr.c b/crypto/testmgr.c index 5a50416..39ffa69 100644 --- a/crypto/testmgr.c +++ b/crypto/testmgr.c @@ -2134,6 +2134,17 @@ int alg_test(const char *driver, const char *alg, u32 type, u32 mask) type, mask); goto test_done; notest: + /* + * Per NIST AESAVS[1], it isn't possible to have automated self-tests + * for counter mode aes vectors, they have to be covered by ecb mode + * and code inspection. The ecb mode tests are trigger above in the + * CRYPTO_ALG_TYPE_CIPHER section. Suppress warnings about missing + * ctr tests if we're in fips mode to avoid confusion. + * + * [1] http://csrc.nist.gov/groups/STM/cavp/documents/aes/AESAVS.pdf + */ + if (fips_enabled !strncmp(alg, ctr(aes, 7)) + goto test_done; printk(KERN_INFO alg: No test for %s (%s)\n, alg, driver); test_done: if (fips_enabled rc) From the way I read the document, anything operating in a counter mode will have an unpredictable output (given the counter operation isn't specified). While the above works, I'm not sure that it fully covers the various ccm modes available (ccm_base and rfc4309). Perhaps instead it would be better to add a TFM mask flag indicating that the selected transform included a unpredictable component or counter input (marking the alg as being unsuitable for automatic testing without knoweldge of the inner workings of that counter. Then you could just test for that flag? Neil -- Jarod Wilson ja...@redhat.com -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] crypto: don't raise alarm for no ctr(aes*) tests in fips mode
On Wednesday 29 April 2009 06:50:35 Neil Horman wrote: On Tue, Apr 28, 2009 at 09:18:22PM -0400, Jarod Wilson wrote: Per the NIST AESAVS document, Appendix A[1], it isn't possible to have automated self-tests for counter-mode AES, but people are misled to believe something is wrong by the message that says there is no test for ctr(aes). Simply suppress all 'no test for ctr(aes*' messages if fips_enabled is set to avoid confusion. Dependent on earlier patch 'crypto: catch base cipher self-test failures in fips mode', which adds the test_done label. [1] http://csrc.nist.gov/groups/STM/cavp/documents/aes/AESAVS.pdf Signed-off-by: Jarod Wilson ja...@redhat.com --- crypto/testmgr.c | 11 +++ 1 files changed, 11 insertions(+), 0 deletions(-) diff --git a/crypto/testmgr.c b/crypto/testmgr.c index 5a50416..39ffa69 100644 --- a/crypto/testmgr.c +++ b/crypto/testmgr.c @@ -2134,6 +2134,17 @@ int alg_test(const char *driver, const char *alg, u32 type, u32 mask) type, mask); goto test_done; notest: + /* +* Per NIST AESAVS[1], it isn't possible to have automated self-tests +* for counter mode aes vectors, they have to be covered by ecb mode +* and code inspection. The ecb mode tests are trigger above in the +* CRYPTO_ALG_TYPE_CIPHER section. Suppress warnings about missing +* ctr tests if we're in fips mode to avoid confusion. +* +* [1] http://csrc.nist.gov/groups/STM/cavp/documents/aes/AESAVS.pdf +*/ + if (fips_enabled !strncmp(alg, ctr(aes, 7)) + goto test_done; printk(KERN_INFO alg: No test for %s (%s)\n, alg, driver); test_done: if (fips_enabled rc) From the way I read the document, anything operating in a counter mode will have an unpredictable output (given the counter operation isn't specified). While the above works, I'm not sure that it fully covers the various ccm modes available (ccm_base and rfc4309). I believe Appendix A only applies for straight up counter-mode aes, ccm_base and rfc4309 actually have well-defined counter operations. We've already got self-tests for ccm(aes) and a pending patch for rfc4309(ccm(aes), and since they don't start w/'ctr(aes', they wouldn't be caught by that (admittedly hacky) check even if we didn't have test vectors for them. Perhaps instead it would be better to add a TFM mask flag indicating that the selected transform included a unpredictable component or counter input (marking the alg as being unsuitable for automatic testing without knoweldge of the inner workings of that counter. Then you could just test for that flag? Yeah, I thought about a flag too, but it seemed potentially a lot of overhead for what might well be restricted to ctr(aes*). It might've been relevant for ctr(des3_ede) or ctr(des), but they're not on the fips approved algo/mode list, so I took the easy way out. I'm game to go the flag route if need be though. -- Jarod Wilson ja...@redhat.com -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] crypto: don't raise alarm for no ctr(aes*) tests in fips mode
Per the NIST AESAVS document, Appendix A[1], it isn't possible to have automated self-tests for counter-mode AES, but people are misled to believe something is wrong by the message that says there is no test for ctr(aes). Simply suppress all 'no test for ctr(aes*' messages if fips_enabled is set to avoid confusion. Dependent on earlier patch 'crypto: catch base cipher self-test failures in fips mode', which adds the test_done label. [1] http://csrc.nist.gov/groups/STM/cavp/documents/aes/AESAVS.pdf Signed-off-by: Jarod Wilson ja...@redhat.com --- crypto/testmgr.c | 11 +++ 1 files changed, 11 insertions(+), 0 deletions(-) diff --git a/crypto/testmgr.c b/crypto/testmgr.c index 5a50416..39ffa69 100644 --- a/crypto/testmgr.c +++ b/crypto/testmgr.c @@ -2134,6 +2134,17 @@ int alg_test(const char *driver, const char *alg, u32 type, u32 mask) type, mask); goto test_done; notest: + /* +* Per NIST AESAVS[1], it isn't possible to have automated self-tests +* for counter mode aes vectors, they have to be covered by ecb mode +* and code inspection. The ecb mode tests are trigger above in the +* CRYPTO_ALG_TYPE_CIPHER section. Suppress warnings about missing +* ctr tests if we're in fips mode to avoid confusion. +* +* [1] http://csrc.nist.gov/groups/STM/cavp/documents/aes/AESAVS.pdf +*/ + if (fips_enabled !strncmp(alg, ctr(aes, 7)) + goto test_done; printk(KERN_INFO alg: No test for %s (%s)\n, alg, driver); test_done: if (fips_enabled rc) -- Jarod Wilson ja...@redhat.com -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
