[onerng talk] Linux /dev/random changes on the way ...

[Jim Cheetham]

On Fri, Jan 17, 2020 at 10:08 AM bsr wrote:
> I am wondering if there have been any new developments pertaining to this
matter. Correct me if I am wrong, but if I understand correctly, the
changes being implemented(?) will significantly (dare I write 'negatively')
affect how external HWRNG devices such as OneRNG contribute to the kernel
entropy pool.

I'm not sure, but I think what's happening is that the entropy *estimates*
are being used only for startup, and no longer consulted during the normal
lifetime of use.
/dev/random has been behaving in the same way as /dev/urandom for a long
time (i.e. they're both just PRNGs, that reseed periodically) with the
exception that /dev/random was going to block if you had read "too much"
from it compared to the rate of entropy input as estimated.

To go with this, it seems like Ted is now making explicit that /dev/random
is not crypto-suitable. "So if it's just for cryptographers, then let it
all be done in userspace". Seems to be a feeling that 'generating session
keys' is not crypto?

All the existing software mechanisms (like, writing to /dev/random) will
continue to work, because they really dislike removing API features :-)

> To me after reading all the discussion, it seems nearly certain that the
blocking pool will essentially be eliminated. Am I correct that other than
the guarantee that /dev/random will block until seeding the CRNG/DRNG
(ChaCha20) with 256 bits of "true" entropy, it will behave like
/dev/urandom? So now we must trust the DRNG and its implementation, right?
If those bits leak (state extension attack) isn't everything pwnd?

Yes, but I think this has been the case for a long time anyway.

> I understand the problems that arose from blocking behavior under certain
circumstances and the need for a solution, but this is a monumental shift
from my perspective. Depending on what comes to pass, I guess one can
always build a custom kernel but that would probably be a maintinence
nightmare. I realize my tin foil hat is thicker than most so maybe I sound
unreasonable.

Finding sources of entropy across all the different places that Linux can
run is incredibly difficult; this change feels more like the kernel team
have given up completely. I suspect this will cause some future problems
where embedded and virtual machines will have no entropy gathering but will
still have to do crypto, but the developers are not going to notice ...

*But* the disclaimer on all this is that I've never been a Linux kernel
developer of any kind, and nothing changes the whole point of OneRNG - an
entropy source that you can inspect, verify, hack on and therefore start to
trust :-) We're not here to "fix Linux", Theo deRaadt told me that OpenBSD
doesn't need us (although it can't hurt, lol), and Windows is still a
mystery.

-jim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ourshack.com/pipermail/discuss/attachments/20200117/7d48f457/attachment.html>