Re: getrandom and getentropy

[Andreas Gustafsson <gson%gson.org@localhost>]

Joerg Sonnenberger wrote:
> On Thu, May 14, 2020 at 05:29:39PM +0300, Andreas Gustafsson wrote:
> > Joerg Sonnenberger wrote:
> > > > > > There's nothing wrong with the general idea of entropy estimation as
> > > > > > implemented in NetBSD-current.  If you run -current on your hypothetical
> > > > > > emulator, it will calculate an entropy estimate of zero, and
> > > > > > /dev/random will block, as it should.  The question we are trying to
> > > > > > decide in this thread is whether getentropy() (and consequently, based
> > > > > > on nia's list, things like openssl) should also block when this
> > > > > > happens, and I'm saying they should.
> > > > > 
> > > > > How should it known that it is not running on real physical hardware
> > > > > with random timing vs a deterministic environment with a programmable
> > > > > timing pattern? Hint: it can't.
> > > > 
> > > > Of course it can't, and I never said it could.
> > > 
> > > But you are arguing that it should be able to do that all the time. 
> > 
> > I don't understand what you are referring to here.  What exactly do
> > you think I'm arguing?
> 
> You are saying that it should do entropy estimation to block until some
> magic point. Which is the old behavior of /dev/random.

It's also the behavior of the -current /dev/random.  Maybe we are just
using the term "entropy estimation" differently?  I'm using it in the
sense of "assigning a numeric entropy estimate to each item mixed into
the entropy pool and keeping track of the total", which -current is
still doing, even though more of the estimates are now zero.  I suspect
you may be using it in a sense more like "attempting to calculate the
entropy estimates at run time based on the observed sample values
rather than through a careful a priori analysis of the system producing
them", which -current is no longer doing.
-- 
Andreas Gustafsson, gson%gson.org@localhost