excessive usage of /dev/random?

[Werner Koch]

On Thu, 30 Apr 2015 16:48, dkg at fifthhorseman.net said:

> 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

That is easy to see for a 256 bit ECC key.

> reasonable", but going from 32 bytes to 300 bytes is a rather large
> safety margin.

300 bytes are only 2400 bit which is sufficient for a 2048 bit RSA key.
For a 4096 bit RSA key, which many people started to use, this is not
sufficient.  Right the full 4800 bits collected in the pool would be
sufficient here but maintaining this pool is pretty costly and thus we
keep it over the invocation of gpg/gpg-agent by means of the random_seed
file.

Requiring 300 fresh bytes before generating the first long term key by
gpg-agent (or gpg < 2.1) guarantees that we don't decrease the security
of a new 2048 bit RSA key in case the random_seed somehow leaked or or
was overwritten with known data.

For ECC keys, which are generated by gpg-agent, it would be possible to
tell the RNG that it should only make sure that there are 32 fresh
random bytes in the pool.  This could be done with a new API for getting
N bytes of random with the promise that this is all the random required
for the object.  The current API allows to put RNG in chunks into a
buffer.  The RNG has no knowledge on whether these requests for random
are for one object or are independent.  Sure, such a new API can be done
but it also increases the code complexity in the RNG thus I won't do
this without a very good reason.

> is "way too fast" really an issue?  If we had excellent entropy, we
> wouldn't care about it showing up speedily, right?

I consider this a bug in the kernel or maybe it is due to the use of
RDRAND.  Might not be an issue with current kernels anymore, though.

> outside.  I'm asking about whether we really need 300 bytes (2400 bits)
> of a seed, which random(4) suggests is overkill.

  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.

This is the common assumption when comparing asymmetric keys to
symmetric keys.  Here we are talking about the generation of asymmetric
keys and I do not know whether the same relation can be applied.


Salam-Shalom,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.