[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#23605: /dev/urandom not seeded across reboots

From: Taylan Ulrich Bayırlı/Kammer
Subject: bug#23605: /dev/urandom not seeded across reboots
Date: Tue, 24 May 2016 09:05:21 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Leo Famulari <address@hidden> writes:

> I realized that we don't seem to be saving any of the entropy in the
> kernel's random pool [0] across reboots.
> This means that for some period after boot, /dev/urandom may not be safe
> to use. From random(4):
> ---
> If  a seed file is saved across reboots as recommended below (all major
> Linux distributions have done this since 2000 at least),
> [/dev/urandom's] output is cryptographically  secure against  attackers
> without  local  root access as soon as it is reloaded in the boot
> sequence, and perfectly adequate for network encryption session  keys.
> ---
> I interpret that text to mean that, without use of a seed file,
> urandom's output is *not* adequate for network encryption session keys
> (SSH, TLS, etc) until enough entropy has been gathered. I don't know how
> long that takes.
> I've attached my not-yet-working attempt at a urandom-seed-service. I
> tried to get it working on my own but I need the assistance of some more
> experienced Guix hackers :)
> I've also attached a stand-alone Guile script to illustrate what the
> effect of the service should be. This script does seem to work. I'm sure
> the use of shell tools could be replaced by Guile.
> After applying my patch and attempting `guix system vm ...`, I get the
> attached backtrace.
> Does anyone have advice about the service? Am I wrong that we need to
> seed /dev/urandom to make it work properly?
> [0] See the man page for random(4).

Yes, this is necessary under Linux if you want urandom to be random
enough immediately after boot, and all the distros do it as part of
their init.

There's also an interesting implication here about the very first time
you boot the system and don't have a urandom seed file from the last
shutdown yet.  I don't know how this is typically handled, given that
for instance it's quite possible that a user might generate SSH keys
shortly after their first boot of a system.

I heard BSD kernels are smarter: /dev/random and urandom are the same
file and behave as follows: after boot, until there's enough entropy,
they block (behave like Linux /dev/random), and once there's enough
entropy they never block (behave like Linux /dev/urandom).  No idea how
the Hurd does it.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]