Re: jitterentropy vs. simulation

[Johannes Berg <johannes@sipsolutions.net>]

Hi Stephan,

> The reason for the Jitter RNG to be dragged in is the Kconfig select in 
> CRYPTO_DRBG.

Yes, but you can't get rid of DRBG either. That'd require getting rid of
CRYPTO_RNG_DEFAULT, which means you cannot even have CRYPTO_GENIV?

Hmm. Maybe it _is_ possible to get rid of all these.

> Why does the DRBG require it?
> 
> The DRBG seeds from get_random_bytes || jitter rng output. It pulls an equal 
> amount of data from each source where each source alone is able to provide all 
> entropy that the DRBG needs. That said, the Jitter RNG can be designated as 
> optional, because the code already can handle the situation where this Jitter 
> RNG is not available. However, in FIPS mode, we must have the Jitter RNG 
> source.
> 
> That said, I could fathom to change CRYPTO_DRBG to remove the select 
> CRYPTO_JITTERENTROPY. But instead, add the select to CRYPTO_FIPS.

Well, CRYPTO_FIPS also would break our testing, since we still have to
support WEP/TKIP (RC4-based) ...

> This change would entail a new log entry when a DRBG instance initializes:
> 
> pr_info("DRBG: Continuing without Jitter RNG\n");
> 
> I would assume that this change could help you to deselect the Jitter RNG in 
> your environment.
> 
> Side note: do you have an idea how that Jitter RNG perhaps could still be 
> selected by default when the DRBG is enabled, but allows it being deselected 
> following the aforementioned suggestion?

Well it _looks_ like it might be possible to get rid of it (see above),
however, what I was really thinking is that jitter RNG might detect that
it doesn't actually get any reasonable data and eventually give up,
rather than looping indefinitely? It seems that might be useful more
generally too?

johannes