all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: taylanbayirli@gmail.com (Taylan Ulrich Bayırlı/Kammer)
To: Leo Famulari <leo@famulari.name>
Cc: 23605@debbugs.gnu.org
Subject: bug#23605: /dev/urandom not seeded across reboots
Date: Tue, 24 May 2016 09:05:21 +0200	[thread overview]
Message-ID: <87shx8j5qm.fsf@T420.taylan> (raw)
In-Reply-To: <20160523175832.GA10646@jasmine> (Leo Famulari's message of "Mon, 23 May 2016 13:58:32 -0400")

Leo Famulari <leo@famulari.name> 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.

Taylan

  reply	other threads:[~2016-05-24  7:06 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-23 17:58 bug#23605: /dev/urandom not seeded across reboots Leo Famulari
2016-05-24  7:05 ` Taylan Ulrich Bayırlı/Kammer [this message]
2016-05-24 16:16   ` Leo Famulari
2016-05-24 16:26     ` Thompson, David
2016-05-24 17:23       ` Leo Famulari
2016-05-24 17:29         ` Thompson, David
2016-05-25 21:53       ` Ludovic Courtès
2016-05-24 12:24 ` Ludovic Courtès
2016-05-25 16:38   ` Leo Famulari
2016-05-25 16:54     ` Ludovic Courtès
2016-05-26 16:47       ` Leo Famulari
2016-05-28 13:57         ` Ludovic Courtès
2016-05-28 18:05           ` Leo Famulari
2016-05-28 18:10             ` Leo Famulari
2016-05-28 18:26             ` Leo Famulari
2016-05-28 20:41               ` Leo Famulari
2016-05-28 20:53             ` Ludovic Courtès
2016-05-29  0:00               ` Leo Famulari
2016-05-29  0:04                 ` Leo Famulari
2016-05-29 20:23                 ` Ludovic Courtès
2016-05-28  1:12   ` Leo Famulari
2016-05-28 13:51     ` Ludovic Courtès
2016-05-28  1:05 ` Leo Famulari
2016-05-28  1:11   ` Ben Woodcroft
2016-05-28  1:45     ` Leo Famulari
2016-05-28  9:40       ` Ben Woodcroft

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87shx8j5qm.fsf@T420.taylan \
    --to=taylanbayirli@gmail.com \
    --cc=23605@debbugs.gnu.org \
    --cc=leo@famulari.name \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.