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

[Paul Campbell]

On Friday, 17 January 2020 10:08:53 AM NZDT 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.
> 
> Someone raises a question about ChaosKey here
> https://lwn.net/Articles/808854/
> 
> I'm not sure the answer because I remember reading Linus Torvalds referring
> to the second law of thermodynamics somewhere in the discussion and that
> implies an isolated system, hence, maybe no mixing of external HWRNG
> entropy in the future.  Plus there are grumblings elsewhere questioning the
> usefulness of such devices and thus the need to support them.
> 
> 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?

this is my understanding (and worry) too - I'm in this biz because we know 
that the NSA has previously hacked RNG algorithms

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

I think there are people with reasonable paranoia :-)

One issue I've had with recent kernels (prior to this) is that the parameter:

/proc/sys/kernel/random/urandom_min_reseed_secs

has been broken - before the unified kernel entropy pool was implemented this 
used to trigger copying new entopy into the kernel - setting it to 0 caused 
data to be fetched from OneRNG every second (you would see the LED blink at 
that rate) - maybe the solution is to provide a patch to Linus that 
reimplements this. 

I haven't looked at the new driver yet - is /dev/random still writeable? 
(adding entropy into the CSPRNG) if the existing mechanism that provides back 
pressure and fetches more entropy through RNGD when the kernel entropy 
estimate drops is now borked then we can probably stop using RNGD and just 
start writing data to /dev/random at a fixed rate (essentially equivalent to 
urandom_min_reseed_secs but for everything) 

	Paul