LED doesn't dim / OneRNG don't work

[Jim Cheetham]

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

Because both /dev/urandom and /dev/random are fed by a PRNG, and neither of
them need to have any direct ongoing relationship to entropy gathering any
more, the real data we'd want to have from the system is 'how much data
have been output', so we can see how far through its sequence the PRNG has
stepped, and when we *need* to have a reseeding event - that's the moment
we need to have available entropy.

Sadly I don't have the skills to read the kernel sources directly, and I
have to rely on other people's interpretations :-) However I feel that the
current man pages for random(4) do not describe the interfaces
sufficiently. random(7) is better but it still implies that /dev/random
outputs data from a pool of entropy, and I'm pretty sure that isn't
accurate any more.

Every few years I feel like I have to go and put a few weeks worth of
research into this topic. I know that the linux kernel maintainers are
thoughtful people, and I've never worried about the implementation of what
they provide; but I do sometimes worry that the purpose of kernel
randomness doesn't match the use-cases of the rest of the OS, and that they
haven't been clear enough in describing what a given interface should be
used for. Of course Linux has a very very strong mission of
backwards-compatibility and avoiding changes that might break user-space,
so some design choices are unavoidable.

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. It's been a few years since we last talked about it, and I
can only assume it's gotten better since then :-)

And in the Windows world, I think the general answer is that no-one outside
Microsoft knows what's happening, and there are no opportunities for the
owner/sysadmin of the machine to affect the OS's operation anyway. They
probably just use RDRAND directly on Intel, which requires a lot of trust
to be given to a large number of suppliers who over time have not
demonstrated that they are trustworthy in a technical sense.

This fundamentally is why OneRNG is presented as a serial/USB device, so
you can choose to totally ignore whatever OS you have, and collect your own
entropy for use with your own PRNGs; and why we are clear that we do not
deliver 8 bits of entropy per 8 bits of data as a guarantee.

I'll admit that one of my earlier intentions was for OneRNG to 'improve'
the entropy pool on Linux :-) but I know what we currently provide is still
useful even if the OS has changed in the meantime!

-jim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ourshack.com/pipermail/discuss/attachments/20210227/5f68f7d6/attachment.html>