On Fri, Mar 18, 2016 at 5:46 PM, Andy Smith <andy@???> wrote:
> So far it seems we are not finding anything now that uses
> /dev/random, although I suspect that gpg may well still do so when
> generating a new key. I haven't tested that yet.
I happened to need to test this today. It seems to open both
/dev/urandom and /dev/random, but block on /dev/random
$ strace -e file,select gpg --gen-key
...
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, use the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
open("/home/graham/.gnupg/random_seed", O_RDONLY) = 4
open("/dev/urandom", O_RDONLY) = 4
select(5, [4], NULL, NULL, {3, 0}) = 1 (in [4], left {2, 999994})
open("/dev/random", O_RDONLY) = 5
select(6, [5], NULL, NULL, {3, 0}) = 1 (in [5], left {2, 999995})
select(6, [5], NULL, NULL, {3, 0}) = 0 (Timeout)
This isn't something I need to run on bitfolk. However, if anyone does
know how to persuade gpg to use /dev/urandom and/or whether it's safe
to do so in a docker container shortly after startup, I'd be curious
to hear the answer.
>From my reading of http://www.2uo.de/myths-about-urandom/ the ideal
solution would be for gpg to use getrandom(2) for this.
