[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: getrandom and getentropy
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
Main Index |
Thread Index |