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.
-- urandom(4)
This seems to be the approach openssl is taking. Contrast with gpg,
which seems to read one bit of entropy per bit of the key being
generated.
(Still don't understand why openssl(1) can be intended for debugging
only given the documentation shipped in openssl, or how that would be a
viable excuse at all if it generated bad keys.)
--
see shy jo
signature.asc
Description: Digital signature
