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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090429105035.GC7227@hmsreliant.think-freely.org>
Date:	Wed, 29 Apr 2009 06:50:35 -0400
From:	Neil Horman <nhorman@...driver.com>
To:	Jarod Wilson <jarod@...hat.com>
Cc:	linux-crypto@...r.kernel.org, linux-kernel@...r.kernel.org,
	Herbert Xu <herbert@...dor.apana.org.au>
Subject: 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 <jarod@...hat.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
> 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