How to quickly generate (insecure) GPG keys?

Question

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 '[email protected]'
$ gpg --batch -quick-random --passphrase 'alice' --quick-gen-key '[email protected]'

Using gpg (GnuPG) 2.1.2.

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

score 6 · Answer 1 · edited Feb 18 '15 at 14:55

6

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

edited Feb 18 '15 at 14:55

Michael Mrozek

91,316
38
238
232

answered Feb 18 '15 at 14:31

ppp

61
1

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

score 3 · Answer 2 · answered Feb 18 '15 at 19:29

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 
# DO NOT USE THIS, THIS DOES NOT PROVIDE ENTROPY TO /dev/random, JUST BYTES

import fcntl
import time
import struct

RNDADDENTROPY=0x40085203

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)
    time.sleep(0.001)

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 07: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 09:25

How to quickly generate (insecure) GPG keys?

2 Answers2