excessive usage of /dev/random?
Daniel Kahn Gillmor
dkg at fifthhorseman.net
Wed Apr 29 20:20:31 CEST 2015
over on the bettercrypto mailing list , 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.
 applied crypto hardening <ach at lists.cert.at>
More information about the Gnupg-devel