<div dir="ltr"><div>The more existential problem is that it's hard to know that the *kernel* is doing its job.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.<br></div><div><br></div><div>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 :-)<br></div><div><br></div><div>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.<br></div><div><br></div><div>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.</div><div><br></div><div>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!</div><div><br></div><div>-jim<br></div></div>