Re: [PATCH] crypto: don't raise alarm for no ctr(aes*) tests in fipsmode

[Jarod Wilson]

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
jarod@xxxxxxxxxx

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/