Re: regarding the changes to kernel entropy gathering

["Koning, Paul" <Paul.Koning%dell.com@localhost>]

> On Apr 6, 2021, at 1:54 PM, Greg A. Woods <woods%planix.ca@localhost> wrote:
> 
> At Mon, 5 Apr 2021 23:18:55 -0400, Thor Lancelot Simon <tls%panix.com@localhost> wrote:
> Subject: Re: regarding the changes to kernel entropy gathering
>> 
>>> 	dd if=/dev/urandom of=/dev/random bs=32 count=1
>> 
>> It's no better.
> 
> So then I would say that in fact using some less trustworthy source of
> randomness (e.g. environmental sensors (including audio), clock skew,
> disk rotational latency, etc., even network jitter if there is no other
> source) as the initial seed entropy _is_ better, for most situations,
> and perhaps for _ALL_ situations where no hardware-RNG is available or
> possible.  Better in part because it prevents the brain-dead way of
> seeding, but also because it mixes real-world data in an algorithmically
> sound way.

I've pointed out in the past that mixing in more external stuff can't make the RNG any worse, assuming it was correctly designed to begin with.  So if you still in various external inputs, the worst that can happen is that you get no useful added entropy.

In my way of thinking, externals events timestamped with a high resolution (microsecond or better) system clock are likely to have at least a small amount of entropy.  It's certainly true that external inputs may be observable, but the nanosecond timestamp the system puts on the packet isn't predictable from the outside (the low order couple of bits, that is).  

	paul