lkml.org 
[lkml]   [2009]   [Apr]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH] crypto: don't raise alarm for no ctr(aes*) tests in fips mode
Date
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 <jarod@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
jarod@redhat.com


\
 
 \ /
  Last update: 2009-04-29 14:51    [W:0.131 / U:0.224 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site