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.