excessive usage of /dev/random?

[Werner Koch]

On Sat,  2 May 2015 03:13, pgut001 at cs.auckland.ac.nz said:
> Yup.  Now that doesn't mean don't use 2048 bits (or whatever) if it's
> available, but you don't need 2048 bits of pure entropy, anything over... well
> lets round it up to a nice 128 bits, should be OK.

Libgcrypt (and GnuPG 1.4) RNG has always been pretty conservative given
that the random numbers are the weakest part of our cryptography and
the worst attscks we have seen are on the random numbers.  I fact most
real world attacks are based breaking the RNG, for example:

  There’s no evidence of a “wow” cryptanalysis; it was key theft, or an
  implant, or a predicted RNG or supply-chain interference.  [1]

The attack model implemented in Libgcrypt might not be realistic,
though: We keep state in a file and assume that for long term key
generation the content of this file is not trustworthy.  Thus we re-seed
it with 2400 bits from our slow entropy gatherer (/dev/random on most
platforms) and only the start to use it.  Now for the actual key
generation even this is not enough and the requested number of random
bits are mixed into the pool again (again from /dev/random).

If we don't trust that this file (random_seed) for long term keys why
should we assume that reading /dev/random improves the situation.  An
attacker able to modify random_seed will also be able to find a local
exploit and tamper with /dev/random.  The only left reason will be a
misbehaving backup/restore or syncing of ~/.gnupg/.  Recipes on how to
backup ~/.gnupg explicitly require not to restore random_seed.  Thus the
chance that this a an avenue for an attack is very small.

And on top of everything we always re-seed our pool before extracting
random for long term keys.  For session keys we don't go into such
length and only require a somehow filled pool.

Having said this, I agree that a change is due.  What about the attached
change?  Should this we done for master or also for stable (1.6)?


Shalom-Salam,

   Werner



p.s.
Note that in my use the acronym CSPRNG stands for "Continuously Seeded
PseudoRandom Number Generator" as used in Peter's implementation of the
paper and not only for "Cryptographically Secure PseudoRandom Number
Generator".

[1]
https://www.lightbluetouchpaper.org/2015/05/02/meeting-snowden-in-princeton/

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-random-Change-initial-extra-seeding-from-2400-bits-t.patch
Type: text/x-diff
Size: 1081 bytes
Desc: not available
URL: </pipermail/attachments/20150504/150abd01/attachment.patch>