excessive usage of /dev/random?

Daniel Kahn Gillmor dkg at fifthhorseman.net
Thu Apr 30 16:48:11 CEST 2015

On Thu 2015-04-30 02:50:00 -0400, Werner Koch wrote:
> On Wed, 29 Apr 2015 20:20, dkg at fifthhorseman.net said:
>> however, i noticed that using 2.1.3, the following command reads 300
>> bytes from /dev/random:
> All GnuPG versions do this.  GnuPG has always used its own CSPRNG where
> /dev/random is used only as a seed.  A pool of 600 bytes is used and
> pre-seeded from the ~/.gnupg/random_seed state file is available.  Now
> for key generation we do not want to rely on too much existing state and
> thus require that 50% fresh entropy is mixed into the pool.  Thus the
> need for 300 bytes from /dev/random or whatever is used for the entropy
> gatherer.

The argument that the man page makes (and that djb makes in
http://blog.cr.yp.to/20140205-entropy.html) is that for a proper CSPRNG,
you shouldn't really need more than 256 bits of true entropy to get a
properly unbreakable seed.  "some safety margin above that minimum is
reasonable", but going from 32 bytes to 300 bytes is a rather large
safety margin.

> The Linux entropy collectors and thus the quality of /dev/random is
> highly depending on the kernel version, hardware, and OS.  Sometimes
> /dev/random is very slow but sometimes way too fast on similar
> hardware.

is "way too fast" really an issue?  If we had excellent entropy, we
wouldn't care about it showing up speedily, right?

> Thus /dev/random is never used directly; better safe than sorry.

FWIW, I am *not* complaining about not using /dev/random directly -- i
agree with the architecture of an internal CSPRNG seeded from the
outside.  I'm asking about whether we really need 300 bytes (2400 bits)
of a seed, which random(4) suggests is overkill.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 948 bytes
Desc: not available
URL: </pipermail/attachments/20150430/971cc4f3/attachment.sig>

More information about the Gnupg-devel mailing list