>> On Dec 26, 2019, at 10:04 PM, Theodore Y. Ts'o <tytso@xxxxxxx> wrote: >> >> On Thu, Dec 26, 2019 at 01:03:34PM +0100, Stephan Mueller wrote: >> Agreed. I was just trying to outline that the removal of the blocking_pool is >> a good thing. Even when we decide that random.c should receive a TRNG, we do >> not need to re-add a blocking pool, but can easily use the existing ChaCha20 >> DRNG (most likely with its own instance). > > Well, it depends on what you mean by "TRNG" --- the ChaCha20 DRNG only > has a state of 256 bits. So if you want to only depend on "true > entropy" you can't extract more than 256 bits without violating that > assumption, at least if you're using a very strict definition of TRNG. > > By getting rid of the blocking pool, and making /dev/random work like > getrandom with flags set to 0, we're effectively abandoning any kind > of assertion that /dev/random is some kind of TRNG. This is not > insane; this is what the *BSD's have always done. > > But once we do this, and /dev/random takes on the semantics of "block > until the CRNG has been initialized, and then it won't block after > that", if we change it so that it now has some different semantics, > such as "one you extract a 256-bit key, the read from /dev/random will > block until we can refill it, which might take seconds, minutes or > hours", will be considered a regression, and we can't do that. I don’t think Stephan was proposing that. He was proposing a way to implement a new interface that blocks. > > Of course, we can hope that people will be using getrandom() and there > will be very few new users of the /dev/random pathname. But nothing > is ever guaranteed.. > > - Ted
