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.
Regards,
--dkg
-------------- 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