[onerng talk] LED doesn't dim / OneRNG don't work

[bsr]

On 2/26/21 5:52 PM, Jim Cheetham wrote:

> The more existential problem is that it's hard to know that the *kernel* is
> doing its job.

agreed.

> Over in the OpenBSD world on the other hand, we have a very extensive
> infrastructure for per-process random provision, there basically isn't a
> central pool to worry about and while Theo *might* one day be convinced
> about the value of a hardware source of entropy at boot time, once the
> system is initialised he's pretty confident that one doesn't actually
> assist at all.

Strictly from a mathematics perspective, he might be correct, but 
context matters.  Only if one trusts their hardware and a bunch of 
sketchy associated binaries can his assertion be true.  Not many people 
run nearly/truly open systems that can be trusted such as ibm power or 
old RE'd hardware.

> I'll admit that one of my earlier intentions was for OneRNG to 'improve'
> the entropy pool on Linux

OneRNG accomplishes that goal.  How does one define 'improve'?  To me 
the notion of equating the method by which the highest measured entropy 
is achieved to be the best result is short sighted.

I'm not claiming the following is true, but suppose hypothetically on an 
OS that testing shows 7.998 bits of entropy per byte without a OneRNG 
plugged in but 7.997 with OneRNG.  Has OneRNG improved entropy?  I still 
emphatically argue yes because the resulting entropy was generated in 
part from OSHW device that can be inspected/verified.  Plus, testing is 
flawed as adversarial examples show and thus, results yield imperfect 
comparisons.  The process used to generate entropy matters just as much 
as the result.  I'll remain unconvinced by anyone claiming improved 
entropy based on test results on closed systems.  That is tantamount to 
chasing unicorns.

I hope my comments in some of my posts don't get interpreted as a claim 
that OneRNG's value is diminished because of the changes made to the 
linux kernel.  From the mailing lists it seems Linux kernel random.c was 
abandoned around the same time the entropy pool changes were made and I 
don't think it has a maintainer yet.  Also seems that some kernel devs 
admit the current state of the linux rng is a bit of a mess so it will 
be interesting to see how this plays out.  It has been a while since I 
looked at it but it seems Stephan Müller's patchset (now on v38) looked 
interesting and would solve old and new problems.

https://www.chronox.de/lrng.html