Re: regarding the changes to kernel entropy gathering

[Thor Lancelot Simon <tls%panix.com@localhost>]

On Sun, Apr 04, 2021 at 01:08:20PM -0700, Greg A. Woods wrote:
> 
> I trust the randomness and in-observability and isolation of the
> behaviour of my system's fans far more than I would trust Intel's RDRAND
> or RDSEED instructions.

I do not.  However, I do differ with Taylor in that I believe that system
fans are a very good example of a case where there is a well understood
_physical_ basis -- turbulence -- for the existence of the entropy being
collected, and that we should count it, in a very conservative way.

If your system has an audio device, and you mute all the inputs and turn
the gain all the way up, then feed that in as entropy samples (we do not
currently have a device driver to do this, but you could from userslace)
I'd make the same argument, since if you don't get all-zeroes, you're then
sampling the amplifier noise.

I also think there is a case to be made for skew sources since measuring
independently sourced clocks against one another is a basic technique in
many hardware RNGs; but I am not sure the one we have is good enough.

It's important to note that most hardware RNG designs *do not* come with
a real physics model alleging to _compute_ their underlying entropy; rather
they come with an explanation in physical terms of where the entropy comes
from, an explanation of how it is sampled (since this can impact the degree
to which samples are truly independent of one another), and _empirically
derived_ estimates of the minimum expected output entropy.  These are usually
obtained by taking the output data prior to any hashing or "whitening" stage
and running specialized statistical tests, compressing it, etc.

I would _personally_ support counting the entropy from environmental sources,
certainly fans but possibly also thermal sensors, if someone wanted to do the
work of characterizing it in a way which is as rigorous as what's done for
commercial RNGs (the Hifn 799x paper on this is a relatively simple worked
example) _and_ empirically general across a wide array of systems.  And I
think the audio thing is worth exploring.

There is also Peter Gutmann's view that what matters is not really what
mathematicians call "entropy" but, really, the work required for an adversary
to predict the output.  This line of thought can lead to very different
views of what bits should count, on a per-system basis; and I think it would
not be wrong to let the system administrator override this with rndctl,
source by source, as previously they could - but the problem remains that
nobody knows _when_ to count such samples and it is very hard to know you
are not overcounting.