[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: gpg can't get random/entropy
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
I did not yet try with larger reads or polling, though.
Main Index |
Thread Index |