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
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
> 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
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...
Size: 948 bytes
Desc: not available
More information about the Gnupg-devel