Re: gpg can't get random/entropy

[Matthew Mondor <mm_lists%pulsar-zone.net@localhost>]

On Tue, 15 May 2012 22:21:13 -0400
Thor Lancelot Simon <tls%panix.com@localhost> wrote:

> On Tue, May 15, 2012 at 09:59:38PM -0400, Matthew Mondor wrote:
> > On Mon, 14 May 2012 21:45:29 -0400
> > Julio Merino <jmmv%NetBSD.org@localhost> wrote:
> > 
> > > On Wed, Mar 21, 2012 at 10:34 PM, Thor Lancelot Simon 
> > > <tls%panix.com@localhost> wrote:
> > > > On Wed, Mar 21, 2012 at 04:49:57PM -0700, Paul Goyette wrote:
> > > >>
> > > >> Not enough random bytes available. ?Please do some other work to give
> > > >> the OS a chance to collect more entropy! (Need 123 more bytes)
> > > >
> > > > I have seen extremely odd behavior of this kind from gpg on other
> > > > platforms, even Linux.
> > > 
> > > Meh, I have just encountered this same problem too :-/
> > 
> > This also affects netbsd-6, unfortunately
> 
> For my part, I can reproduce it with the latest gnupg sources on
> Debian Linux running a Linux 3.1 kernel.  Which is what makes me think
> the problem, in general, isn't exactly my fault.
> 
> I'll try to find some time this weekend to poke at it more.

Sorry for not having included more details in my first message.

It's very possible that gpg be at fault (see the working dd test
below), I didn't check its implementation yet, and the packages I tried
were gnupg2-2.0.18nb2/libgcrypt-1.5.0, which I think were from
pkgsrc-2011Q4 (probably not the latest).


The results of rndctl -l on the netbsd-6/amd64 system I tried gpg on:

Source                 Bits Type      Flags
ums0               13100235 tty  estimate, collect
cd0                12177323 disk estimate, collect
wd2                78996626 disk estimate, collect
wd1                75487784 disk estimate, collect
wd0                    2720 disk estimate, collect
cpu3                1267978 vm   estimate, collect
cpu2                1309832 vm   estimate, collect
cpu1                1269791 vm   estimate, collect
cpu0                1245692 vm   estimate, collect
rtk0                      0 net  
pckbd0              3472887 tty  estimate, collect
system-power              0 power estimate, collect
callout                   0 skew collect

ums0 (the mouse) seems enabled as a collector, but ktrace showed no
activity occurring in the gpg process when I was actively moving it, it
was just polling.  Generating disk activity also didn't help.


However, the following test works:

$ dd if=/dev/random bs=1 | xxd

I got a few pages of random data, after which read blocked.  If I moved
the mouse actively, some more bytes could be read regularily, as
expected.  Also, /dev/urandom always continues to return data using the
RND-seeded PRNG.

I did not yet try with larger reads or polling, though.

Thanks,
-- 
Matt