[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Yd1dK//76455cHdz@gondor.apana.org.au>
Date: Tue, 11 Jan 2022 21:34:19 +1100
From: Herbert Xu <herbert@...dor.apana.org.au>
To: Nicolai Stange <nstange@...e.de>
Cc: Stephan Mueller <smueller@...onox.de>,
"David S. Miller" <davem@...emloft.net>,
Hannes Reinecke <hare@...e.de>, Torsten Duwe <duwe@...e.de>,
Zaibo Xu <xuzaibo@...wei.com>,
Giovanni Cabiddu <giovanni.cabiddu@...el.com>,
David Howells <dhowells@...hat.com>,
Jarkko Sakkinen <jarkko@...nel.org>,
linux-crypto@...r.kernel.org, linux-kernel@...r.kernel.org,
qat-linux@...el.com, keyrings@...r.kernel.org, simo@...hat.com,
Eric Biggers <ebiggers@...nel.org>, Petr Vorel <pvorel@...e.cz>
Subject: Re: [PATCH] crypto: api - Disallow sha1 in FIPS-mode while allowing
hmac(sha1)
On Tue, Jan 11, 2022 at 08:50:18AM +0100, Nicolai Stange wrote:
>
> I haven't tried, but wouldn't this allow the instantiation of e.g.
> hmac(blake2s-256) in FIPS mode?
You're right. The real issue is that any algorithm with no tests
at all is allowed in FIPS mode. That's clearly suboptimal. But we
can't just ban every unknown algorithm because we rely on that
to let things like echainiv through.
Let me figure out a way to differentiate these two cases.
Thanks,
--
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Powered by blists - more mailing lists