[Pkg-gnutls-maint] Bug#475168: Bug#475168: certtool --generate-dh-params is ridiculously wasteful of entropy

[Matt Mackall]

On Fri, 2008-04-11 at 16:03 +0200, Simon Josefsson wrote:
> sacrificial-spam-address at horizon.com writes:
> 
> > Simon Josefsson <simon at josefsson.org> wrote:
> >> sacrificial-spam-address at horizon.com writes:
> >>> That paper deserves a longer reply, but even granting every claim it
> >>> makes, the only things it complains about are forward secrecy (is it
> >>> feasible to reproduce earlier /dev/*random outputs after capturing the
> >>> internal state of the pool from kernel memory?) and entropy estimation
> >>> (is there really as much seed entropy as /dev/random estimates?).
> >>>
> >>> The latter is only relevant to /dev/random.
> >>
> >> Why's that?  If the entropy estimation are wrong, you may have too
> >> little or no entropy.  /dev/urandom can't give you more entropy than
> >> /dev/random in that case.
> >
> > The quality or lack thereof of the kernel's entropy estimation is relevant
> > only to /dev/random because /dev/urandom's operation doesn't depend on
> > the entropy estimates.  If you're using /dev/urandom, it doesn't matter
> > if the kernel's entropy estimation is right, wrong, or commented out of
> > the source code.
> 
> My point is that I believe that the quality of /dev/urandom depends on
> the quality of /dev/random.  If you have found a problem in /dev/random,
> I believe it would affect /dev/urandom as well.

Again, the /dev/random entropy estimate is irrelevant to /dev/urandom
because it degrades to a conventional PRNG.

> > Well, he calls /dev/random "blindingly fast" in that thread, which appears
> > to differ from your opinion. :-)
> 
> It was /dev/urandom, but well, you are right.  On my machine, I get
> about 3.9MB/s from /dev/urandom sustained.  That is slow.  /dev/zero
> yields around 1.4GB/s.  I'm not sure David had understood this.  The
> real problem is that reading a lot of data from /dev/urandom makes the
> /dev/random unusable, so any process that reads a lot of data from
> /dev/urandom will receive complaints from applications that reads data
> from /dev/random.  I would instead consider this a design problem in the
> kernel.

..one that's long since been fixed. Reading from /dev/urandom always
leaves enough entropy for /dev/random to reseed. If you have a steady
input of environmental entropy, /dev/random will not be starved.

-- 
Mathematics is the supreme nostalgia of our time.