[Cryptography] provisioning a seed for /dev/urandom

[David Mercer]

On Fri, Oct 25, 2013 at 4:14 AM, John Denker <jsd at av8n.com> wrote:

> On 10/17/2013 12:43 PM, David Mercer wrote:
>
> > Sometime in the last two months I described the somewhat widespread issue
> > at VM hosting/cloud providers of provisioning VM's with the same
> > /dev/urandom seed from the image template. firstboot scripts typically
> only
> > get run at image generation, and then the urandom seed is frozen in
> amber,
> > as it were, in the VM image template file. It is a fairly trivial fix to
> > re-seed it from /dev/random (one line in the right place).
>
> I reckon that in most cases, it would be better to obtain the
> seed from the host's /dev/urandom (rather than /dev/random) to
> avoid problems with blocking, as discussed below.
>

Unfortunately access to the host hypervisor's /dev/urandom isn't normally
available.


>   The exception is in cases where you know you have a copious
>   supply of high-quality randomness available via /dev/random,
>   so that blocking is not an issue.  Hint: turbid.
>

You aren't going to have lots high quality randomness available via
/dev/random on the hypervisor in currently deployed VM hosting environments.


> > The obvious place to do that, when the VM is actually provisioned, ends
> up
> > hurting deployment time due to sometimes blocking on /dev/random reads to
> > re-seed /dev/urandom.
>
> I'm mystified by that.  We're talking about Linux /dev/urandom
> aren't we?  That never blocks, not for reseeding or for anything
> else.  There have been proposals to change this, but that would
> be a Bad Idea™ and I've never seen any blocking urandom device
> actually get distributed ... although perhaps I have overlooked
> something.
>
>
I was talking about re-seeding /dev/urandom when the on-disk seed file that
is read at boot is identical across virtual machine images. We're talking
about the large VM hosting provider use case. Lots of VM instances can be
spun up at once on a hypervisor, and re-seeding /dev/urandom from
/dev/random can and will often block.

Note that on many (most?) data center grade rackmount servers you don't
HAVE an audio port at all to run something like turbid against.


> >  This has led people to toss up their hands and do the
> > Wrong Thing of just provisioning, sometimes thousands, of VM's with the
> > same ... seed.
>
> That's a bizarre overreaction.
>  ++ It would make sense to switch from /dev/random to /dev/urandom,
>   since the latter never blocks.
>  -- It makes no sense to switch from /dev/random to a constant.
>

Again, I appear to have been unclear, I'm talking about seeding
/dev/urandom from /dev/random upon first boot of a VM that has a
/dev/urandom seed stored on disk from when the parent VM that was imaged
was last shutdown.

-David Mercer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20131026/17d2a99a/attachment.html>