Page MenuHome GnuPG

gpg --import pauses for entropy
Closed, ResolvedPublic

Description

When importing a secret key without a passphrase, I notice that gnupg 2.1.16 is
much slower than previous versions. The attached test script demonstrates the
problem, which I bisected to commit 4473db1ef24031ff4e26c9a9de95dbe898ed2b97.
When run with versions before that commit, gpg --import completes more or less
instantly. After that version, it takes ~12 seconds.

Running with --debug-level guru shows that most of the time is spent on:

    gpg: DBG: chan_4 <- S PROGRESS need_entropy X 120 120

It looks like 4473db1ef added a 100ms pause when we ask for entropy. I wonder if
this is triggering more often than it should, as we otherwise seem to get enough
entropy instantly.

Details

Version
2.1.16

Event Timeline

peff set Version to 2.1.16.
peff added a subscriber: peff.

The initial motivation for looking into this is that Git's test suite, which
uses gpg --import to set up some test vectors, was taking longer to run.
There's some additional analysis on the Git list, especially:

http://public-inbox.org/git/20161228160520.dsybuqljzkzsik2d@thunk.org/

Are you using libgpg-error 1.25 ?

I'm using libgpg-error 1.26, though I'm sure it also happened with 1.25 (I get
libgpg-error from Debian unstable, which went to 1.25 on Nov 16th, and then 1.26
on Dec 24th, and I saw the symptoms at both of those times). I'm happy to
experiment with another version if you have suggestions.

werner raised the priority of this task from Low to Normal.Jan 2 2017, 2:14 PM

1.25 or 1.26 does not matter. In 1.25 we improved the nPth support and made the
mutex used by Libgcrypt's RNG actual work as expected.

However, this seems to reveal another problem and thus I upgraded this to a real
bug.

According to the link above, the reason we need entropy on import is the KEYWRAP between gpg and gpg-agent. The reason we are stalling is that we use getrandom() and the urandom pool is apparently not initialized on that system.

werner claimed this task.

We can't do anything about thisfor the oldversions. You may use libgcrypt 1.8.0 which has a faster entropy collector and also allows to map /dev/random to /dev/urandom using the new /etc/gcrypt/random.conf

With the libgcrypt 1.7.8 you should not experience severe problems. Thus I will mark this bug as resolved.