Re: getrandom and getentropy

[Joerg Sonnenberger <joerg%bec.de@localhost>]

On Thu, May 14, 2020 at 08:11:32PM +0300, Andreas Gustafsson wrote:
> 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.

Yes, it is the behavior of /dev/random, but it is as I said before at
best security voodoo unless you have an actual slow hardware RNG. The
model used for entropy estimation for any other source is useless at
best. It doesn't even qualify as educated guess, because it is
fundamentally something that can't be done in this form. So the blocking
behavior of /dev/random doesn't really have anything to do with the
(real) entropy of the kernel RNG. It just gives you a nice warm fuzzy
feeling. So what's the point of extending it to another interface beyond
nice warm fuzzy feelings? IMO it is more like the 100ml bottle rule air
travellers have been subjected too for years than actually sound
security engineering.

Joerg