Hi Graham,
On Tue, Apr 26, 2016 at 05:09:50PM +0100, Graham Bleach wrote:
On Fri, Mar 18, 2016 at 5:46 PM, Andy Smith
<andy(a)bitfolk.com> 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
[…]
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.
(I know you know this but just to make the general point…) Best
practice of course would be to never generate a long-lived key like
a PGP key on networked hardware belonging to someone else, as the
risk of some lower level of infrastructure being compromised is too
great for a key that is expected to be in use for years.
Anyway, from what I understand, urandom is fine forever as long as
the PRNG has been initially seeded with entropy. "Initially" being
"on first boot", since every modern Linux distro saves the PRNG
state to a file on shut down and loads it back on boot.
I don't know what Docker would be doing here. Presumably the
container just has (u)random devices that make use of the host's
PRNG so as long as Docker isn't doing this shortly after the first
ever boot of the host then it would be fine. But not fine soon after
first boot, and sadly no way to tell if it is safe yet other than
first reading from /dev/random and then switching to urandom
afterwards.
From my reading of
http://www.2uo.de/myths-about-urandom/ the ideal
solution would be for gpg to use getrandom(2) for this.
I agree; according to
https://lwn.net/Articles/605828/ it will block
(or return EAGAIN) during the problematic initial early first boot
period.
Cheers,
Andy
--
http://bitfolk.com/ -- No-nonsense VPS hosting