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-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
