[lkml]   [2019]   [Dec]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v3 0/8] Rework random blocking

>> On Dec 26, 2019, at 10:04 PM, Theodore Y. Ts'o <> 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

 \ /
  Last update: 2019-12-27 00:30    [W:0.062 / U:0.788 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site