[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: getrandom and getentropy
Joerg Sonnenberger wrote:
> On Tue, May 12, 2020 at 04:59:52PM +0300, Andreas Gustafsson wrote:
> > I don't particularly care if we require 100 or 384 bits of estimated
> > entropy, nor do I particularly care if the entropy estimate of a
> > keystroke timestamp is 0 or 1 bit. But I do very much care that if I
> > accidentally try to generate an ssh key on a system that has no
> > entropy at all, it must not succeed.
> Once more and alone and maybe it will sink in:
> There is no reasonable way to estimate system entropy.
> Please think what that statement means. Consider for fun emulating a 20
> year old computer with a deterministic high precision model keeping all
> storage in memory. There is no source of entropy in such a system and no
> way for the emulation to tell.
What exactly are you objecting to here - the general idea of calculating
an entropy estimate and comparing it against a "full entropy" threshold,
or my willingness to consider a 1-bit estimate for a keystroke timestamp?
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.
The 1-bit estimate for a keystroke timestamp, on the other hand, is
open to debate. There, I don't see how the computer being emulated is
relevant; if there's an actual human at the keyboard, estimation will
work as well or as badly on the emulator as on real hardware; the
problematic case is when the human is being emulated, not the
computer. But that debate belongs in a different thread.
Andreas Gustafsson, gson%gson.org@localhost
Main Index |
Thread Index |