lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 04 May 2009 23:45:08 -0400
From:	Jarod Wilson <jarod@...hat.com>
To:	Herbert Xu <herbert@...dor.apana.org.au>
CC:	linux-crypto@...r.kernel.org, linux-kernel@...r.kernel.org,
	Neil Horman <nhorman@...driver.com>
Subject: 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
jarod@...hat.com

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ