AW: AW: Key generation with GPGME and GnuPG hangs at gpgme_op_genkey

[Sandra Schreiner]

Von: Daniel Kahn Gillmor [dkg at fifthhorseman.net]
Gesendet: Dienstag, 26. Januar 2016 19:30
An: Sandra Schreiner; Robert J. Hansen; gnupg-users at gnupg.org
Betreff: Re: AW: Key generation with GPGME and GnuPG hangs at gpgme_op_genkey

On Tue 2016-01-26 06:02:09 -0500, Sandra Schreiner wrote:
 [ Robert J. Hansen wrote: ]
>> Are you getting periodic messages about "Not enough random bytes
>> available.  Please do some other work to give the OS a chance to
>> collect more entropy! (Need 167 more bytes)" or something like that?
>
> Yes. You are right. These messages appear often.

You said that you are running in a Jessie VM.  Depending on the type of
VM, it's possible that there are few events that are feeding the
kernel's entropy pool (no virtualized hardware or software or anything
similar).  GnuPG relies on the kernel's entropy to initialize the key
generation process, and it consumes rather a lot of it.

I don't know what kind of virtualization you're using, so i have no
concrete suggestions for how you could increase the entropy in the VM
you're using, other than the usual tricks of typing into keyboard and
wiggling the mouse.

you can see the state of the Linux kernel's entropy by looking at the
contents of the file /proc/sys/kernel/random/entropy_avail -- if that is
staying close to 0, it's likely that this is the problem.

For testing purposes only, you might be interested in using the
--debug-quick-random flag, which would avoid waiting on the kernel's
blocking RNG.


I note that you're passing the root of the filesystem as your preferred
CONFIG_DIR:

      const char * CONFIG_DIR = "/";

This might be a mistake, because it's unlikely that a normal user can
write to the root directory, and you almost certainly don't *want* to
use the root directory as your gpg config dir.

gpgme_set_engine_info() accepts NULL as the HOME_DIR parameter, which
asks for the engine' default homedir to be used.

> Moreover I noticed that GPGME 1.5 may be outdated. I saw that e.g. the
> mode GPGME_EXPORT_MODE_SECRET is missing for exporting private
> keys. Therefore I would like to update GnuPG and GPGME together. Sadly
> there is no new version of them available in the debian package
> manager. How can I manage to update them? I found the tarball of GPGME
> 1.6 but don't know which version of GnuPG would match this GPGME
> version.

gpgme and gnupg are not intentionally tightly coupled.  I wouldn't try
to update them until you've figured out what's going on here.

If the delay is still happening for you even with a system with entropy
available, you might also try looking at the process table to see what
is going on -- if there's a backgrounded gpg or gpg2 process, you could
try attaching to it with strace ("strace -p $PID", where $PID is the
process ID of the gpg process) to see what it's doing.

hth,

        --dkg

________________________________________

> you can see the state of the Linux kernel's entropy by looking at the
> contents of the file /proc/sys/kernel/random/entropy_avail -- if that is
> staying close to 0, it's likely that this is the problem.

This file is empty. So entropie problems might be the reason. I'm using
a 64 bit Debian Image (Jesse) provided by Virtual Box inside Virtual Box
VM Manager.

> For testing purposes only, you might be interested in using the
> --debug-quick-random flag, which would avoid waiting on the kernel's
> blocking RNG.

I don't know how and where I should use this flag. I tried to generate a
new key using GnuPG command line tool, but it doesn't recognize it:

user at PC-ID-0050a-vm:~$ gpg --gen-key --debug-quick-random
gpg: Invalid option "--debug-quick-random"

Also I can't pass it as a compiler flag in my c++ project. My compiler 
doesn't know the flag either. Where does this flag belong?

> I note that you're passing the root of the filesystem as your preferred
> CONFIG_DIR:

I removed the specific path of the directory, because it contains the
project and user name. Sorry, I didn't mentioned that earlier. 
However I also tried to use the default path and didn't get any
results from the key generation in the c++ application.

I would really like to test if I could generate a key with the 
--debug-quick-random flag and see if entropie is the only show-stopper here.
Could this entropie issue also stop the application from generating
a key on a freshly booted system, say a mobile phone or a  'normal' 
(not VM) pc system?