Key generation: is it possible to fail fast?

Werner Koch wk at
Fri Feb 17 20:45:19 CET 2017

On Fri, 17 Feb 2017 15:59, justus at said:

> At our last hackathon we briefly pondered an idea to make key generation
> appear fast without compromising on key strength: When the frontend
> starts a new key generation wizard, start collecting entropy in the

I doubt that this solves the problem.  From my experience you either
have a good entropy source or you don't.  Without one it takes really
looooong and this means looonger than the user needs to go thru a

Using a hardware RNG is very good idea in all cases, next best is to use
a CPU with RDRAND or Padlock.  What I do for my test is

  rngd -r /dev/urandom

which basically maps /dev/urandom to /dev/random and makes things really
fast.  That is of course ONLY FOR TESTING.

Libgcrypt and gpg are pretty conservative in these things which might be
a good or bad thing.  Right now we require /dev/random for long term key
generation.  Given that on Linux the kernel RNG should be good enough,
we could imagine an option to never use /dev/random (so basically doing
the above trick).



Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: </pipermail/attachments/20170217/10c3a3e0/attachment.sig>

More information about the Gnupg-devel mailing list