Inability to export and then import my secret key

Werner Koch wk at
Wed Aug 12 15:59:07 CEST 2015

On Wed, 12 Aug 2015 13:01, peter at said:

> Anyway, on-topic: don't copy random_seed though. And be aware that some options

It would not be a catastrophically failure, though.  Here is a comment
from the function reading random_seed:

   Note: Multiple instances of applications sharing the same random
   seed file can be started in parallel, in which case they will read
   out the same pool and then race for updating it (the last update
   overwrites earlier updates).  They will differentiate only by the
   weak entropy that is added in read_seed_file based on the PID and
   clock, and up to 16 bytes of weak random non-blockingly.  The
   consequence is that the output of these different instances is
   correlated to some extent.  In the perfect scenario, the attacker
   can control (or at least guess) the PID and clock of the
   application, and drain the system's entropy pool to reduce the "up
   to 16 bytes" above to 0.  Then the dependencies of the initial
   states of the pools are completely known.  */

The above is for the general case of asking for random, for example
session keys.  When generating a new public key pair gpg (and Libgcrypt)
takes an extra step by making sure that at least 128 bit of fresh
entropy (e.g. from /dev/random) have been inserted into the pool.



Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

More information about the Gnupg-users mailing list