[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <VI1PR0402MB3485E327703191780AC68BFE98350@VI1PR0402MB3485.eurprd04.prod.outlook.com>
Date: Mon, 13 Jan 2020 14:10:51 +0000
From: Horia Geanta <horia.geanta@....com>
To: Andrey Smirnov <andrew.smirnov@...il.com>,
"linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>
CC: Chris Healy <cphealy@...il.com>,
Lucas Stach <l.stach@...gutronix.de>,
Herbert Xu <herbert@...dor.apana.org.au>,
Iuliana Prodan <iuliana.prodan@....com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
dl-linux-imx <linux-imx@....com>
Subject: Re: [PATCH v6 7/7] crypto: caam - limit single JD RNG output to
maximum of 16 bytes
On 1/8/2020 5:42 PM, Andrey Smirnov wrote:
> In order to follow recommendation in SP800-90C (section "9.4 The
> Oversampling-NRBG Construction") limit the output of "generate" JD
> submitted to CAAM. See
> https://lore.kernel.org/linux-crypto/VI1PR0402MB3485EF10976A4A69F90E5B0F98580@VI1PR0402MB3485.eurprd04.prod.outlook.com/
> for more details.
>
> This change should make CAAM's hwrng driver good enough to have 999
> quality rating.
>
[...]
> @@ -241,6 +241,7 @@ int caam_rng_init(struct device *ctrldev)
> ctx->rng.init = caam_init;
> ctx->rng.cleanup = caam_cleanup;
> ctx->rng.read = caam_read;
> + ctx->rng.quality = 999;
>
AFAICS the maximum value of hwrng.quality is 1024.
Any reason why it's configured to be lower, now that CAAM RNG-based DRBG
is configured to reseed as requested by FIPS spec to behave as a TRNG?
Horia
Powered by blists - more mailing lists