I'd like to automate generating at least two GPG keys for testing and demonstration purposes in a virtual machine. Because of this context I want to make sure the key generation is fast, ideally not using or modifying /dev/*random at all. For example, using the system clock as the only random source would be fine:

$ gpg --quick-gen-key 'alice' [options] --random-data $(date +%s)
$ sleep 2
$ gpg --quick-gen-key 'bob' [options] --random-data $(date +%s)

I haven't been able to find any options like this. There's -quick-random and --debug-quick-random which are not in the man page, seem to be supported by gpg, and just don't work. These commands, for example, ran for several minutes before I killed them:

$ gpg --batch --debug-quick-random --passphrase 'alice' --quick-gen-key 'alice@example.org'
$ gpg --batch -quick-random --passphrase 'alice' --quick-gen-key 'alice@example.org'

Using gpg (GnuPG) 2.1.2.

  • Which route did you took in the end? – gf_ Mar 25 '18 at 19:31
  • @gf_ I moved on to something else. – l0b0 Mar 25 '18 at 19:42

You can temporarily have /dev/random pull from /dev/urandom using rng-tools:

# rngd -v -f -r /dev/urandom

More information here: https://madebits.github.io/#blog/2014/2014-05-30-Making-dev-random-Temporary-Faster.md

  • Also related is a daemon called haveged, I seem to recall that RHEL/CentOS have one but not the other. – Ulrich Schwarz Feb 18 '15 at 16:49
  • 1
    How do you revert it back to more safe /dev/urandom? – l0b0 Feb 19 '15 at 19:21

I had the exact same requirement while writing my smartcard setup program. During testing I would not care about entropy, and I needed to generate multiple GPG keys in a row each test.

As I described in my answer here the following script helped me speeding things up:

#!/usr/bin/env python
# For testing purposes only 

import fcntl
import time
import struct


while True:
    random = "3420348024823049823-984230942049832423l4j2l42j"
    t = struct.pack("ii32s", 8, 32, random)
    with open("/dev/random", mode='wb') as fp:
        # as fp has a method fileno(), you can pass it to ioctl
        res = fcntl.ioctl(fp, RNDADDENTROPY, t)
  • Doesn't this have a fairly large chance of resulting in identical keys? (I guess that could be counteracted by adding nano-time to the mix.) – l0b0 Feb 19 '15 at 7:50
  • @l0b0 I haven't noticed that, it could be. But it doesn't have to be as the system still inserts entropy during the time this is running as well. You could use the nano-time or some long cycle random number generator not depending on reading from /dev/random. – Anthon Feb 19 '15 at 9:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.