In message <20021129080106.58016.qmail@mail.com>, skrueger@europe.com writes:
>> My guess is that it doesn't seem to know when it found
>> a good key, and keeps trying more.
>
>Did you read
>http://www.gnupg.org/faq.html#q4.2 ??? You should...

No, missed that one... oops.  But that does not appear to be it.

>The dots indicate that gnupg needs more random numbers. Just move your mouse (
>when you're using X) or press some keys. You can also check available random n
>umbers with rndctl -s.

Except that rndctl -s went from 4096 bits in the pool before starting
--gen-keys to 0 immediately after, then it quickly climbed to, and
stayed at, 4096.  When I saw it low, I started a find / > /dev/null
to fill the pool, but I quickly killed it when the pool was close
to full.

Also, if it was waiting for more random bits, I would expect the
CPU load to be quite low, but top reports it as the most CPU bound
process on the machine. Finally, lsof reports that it is using
/dev/urandom, not /dev/random, and the rndctl manpage says
"/dev/urandom   Always returns data, degenerates to a pseudo-random
generator."

I believe the dots do not signify that it is waiting for more random
bits, but is reporting progress on finding some prime numbers to
use as a key.  I was hoping someone had run into this recently, or
could verify the problem.  (Or even provide a workaround.)  Guess
I'll need to start playing with GCC options and digging into the
GnuPG source code.  (Which I do not feel the most qualified or
comfortable doing.)

Jon