excessive usage of /dev/random?

[Daniel Kahn Gillmor]

Hi folks--

over on the bettercrypto mailing list [0], my attention was drawn to the
man page for random(4), which says:

       The kernel random-number generator  is  designed  to  produce  a  small
       amount  of  high-quality  seed material to seed a cryptographic pseudo-
       random number generator (CPRNG).  It  is  designed  for  security,  not
       speed, and is poorly suited to generating large amounts of random data.
       Users should be very economical in the amount  of  seed  material  that
       they  read  from  /dev/urandom (and /dev/random); unnecessarily reading
       large quantities of data from this device will have a  negative  impact
       on other users of the device.

       The  amount  of  seed material required to generate a cryptographic key
       equals the effective key size of the key.  For example, a 3072-bit  RSA
       or Diffie-Hellman private key has an effective key size of 128 bits (it
       requires about 2^128 operations to break) so a key generator only needs
       128 bits (16 bytes) of seed material from /dev/random.

       While  some  safety margin above that minimum is reasonable, as a guard
       against flaws in the CPRNG algorithm, no cryptographic primitive avail‐
       able  today  can  hope to promise more than 256 bits of security, so if
       any program reads more than 256 bits (32 bytes) from the kernel  random
       pool  per  invocation, or per reasonable reseed interval (not less than
       one minute), that should be taken as a sign that  its  cryptography  is
       not skillfully implemented.

however, i noticed that using 2.1.3, the following command reads 300
bytes from /dev/random:

 gpg --quick-gen-key 'test <test at example.org>'

Should GnuPG be more sparing in its use of this blocking resource?

The full thread covers other good insights around system entropy as well.

       --dkg

[0] applied crypto hardening <ach at lists.cert.at>
    https://lists.cert.at/pipermail/ach/2015-April/001884.html