Linux /dev/random changes on the way ...

[bsr]

On 2020-01-16 5:43 pm, Jim Cheetham wrote:

> /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.

I would argue that they behave quite differently in some circumstances.

/dev/random is a discrete pool that blocks upon entropy exhaustion and must then wait to gather sufficient new entropy from hardware interrupts, OneRNG's, etc. to begin replenishing the pool.  The entropy gathered in "seeding" the pool pre-exhaustion is different than the entropy gathered for the pool post-exhaustion.

/dev/urandom won't block, so upon entropy exhaustion under continuous load, it must rely solely on the PRNG.  Yes it will reseed eventually, but even on a desktop it can take a while generating enough entropy and may take a very long time on embedded devices or virtualized server. If doing crypto operations such as generating multiple gnupg key pairs it seems very possible that what should be distinct keys could now be based off of the same deterministic PRNG stream :(  That won't happen with a blocking pool.

As a related side note, I don't understand the hostility towards GnuPG's use of the blocking pool and being referred to as a "stupid program" for doing so.   Are there problems in doing so, yes.  But those amount to a DoS issue.  What it won't do is cause a potential cryptographic weakness.

> 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 ...

I agree.  This is basically the point I am making above but that isn't the only reason to be concerned.

> *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 :-)

Yep, OneRNG is great.  Though certainly not exhaustive, I have been through a fair portion of the fw src, bash and python scripts, etc. with lots of questions for Paul that he always answered.  I've gone down to the hardware level to do things like inspect the noise signal directly off the T3 collecter of several units with a scope and compare the waveform to a homebuilt rng circuit built to OneRNG specs.  I swear I'm not nuts, lol.  I actually have a good reason for doing all this.  Basically I've tinkered with it quite a lot and it's all pretty reassuring and confidence inspiring.

I'm confident enough to trust that feeding the kernel with entropy generated from OneRNG to mix into the pool is a wise decision.

>  We're not here to "fix Linux"

I understand that.  I worry maybe all of this isn't a step in the right direction but I'll wait for more info and probably look at some kernel src because that is the only true way to know how this stuff is operating.