3

I'm testing some code that uses python-gnupg to encrypt/sign/decrypt some plaintext, and I'd like to generate a key pair on the fly. GnuPG is (of course) super paranoid in generating the key pair, and it sucks a lot of entropy from my system.

I found this answer on unix.stackexchange.com, but using rngd to have /dev/random pull from /dev/urandom sounds like a bad idea.

Since I'm testing I don't need high security, I just need the key pair to be generated as quickly as possible.

An idea is to pre-generate some keys offline, and use those keys on my tests. Anyway, I'd like to programmatically generate my temporary key pairs while executing the tests.

This is the code I'm using now (that is, again, super slow and not good for testing):

from tempfile import mkdtemp
import gnupg

def temp_identity():
    identity = gnupg.GPG(gnupghome=mkdtemp())
    input_data = gpg.gen_key_input(key_type='RSA', key_length=1024)
    identity.gen_key(input_data)
    return identity
Community
  • 1
  • 1
vrde
  • 937
  • 1
  • 11
  • 25

1 Answers1

4

Using any method to change /dev/random to pull out of /dev/urandom is totally fine once the entropy pool was initiated with a proper random state (which is not a problem on hardware x86 machines, but might require discussion for other devices). I strongly recommend watching The plain simple reality of entropy -- Or how I learned to stop worrying and love urandom, a lecture at 32C3.

If you want to fasten-up on-the-fly key generation, consider going for smaller key sizes like RSA 512 (1k keys aren't really secure, either). THis will render keys insecure, but if that's fine for testing -- go for it. Using another algorithm (for example elliptic curves if you already have GnuPG 2.1) might also speed up key generation.

If you really want to stick with /dev/random and smaller key sizes don't provide adequate performance, you can very well pre-generate keys, export them using gpg --export-secret-keys and import them instead of creating new ones.

gpg-agent also knows the option --debug-quick-random, which seems to fit your use case, but I've never used it before. From man gpg-agent:

--debug-quick-random

This option inhibits the use of the very secure random quality level (Libgcrypt’s GCRY_VERY_STRONG_RANDOM) and degrades all request down to standard random quality. It is only used for testing and shall not be used for any production quality keys. This option is only effective when given on the command line.

Jens Erat
  • 37,523
  • 16
  • 80
  • 96
  • Super interesting video, thanks! I cannot assume the user has root access to the machine, so I cannot use `rngs`. I found something similar to your `--debug-quick-random`. There is an option in `gpg` (v1) that is `--quick-random` and it's much much faster, and it's used in the [`python-gnupg tests suite`](https://bitbucket.org/vinay.sajip/python-gnupg/src/848fcc959c7fcee8631c4a47a0600dc7abd2f6ee/test_gnupg.py?fileviewer=file-view-default#test_gnupg.py-178) – vrde Mar 14 '16 at 14:39