[147850] in cryptography@c2.net mail archive
Re: [Cryptography] provisioning a seed for /dev/urandom
daemon@ATHENA.MIT.EDU (David Mercer)
Sat Oct 26 01:35:15 2013
X-Original-To: cryptography@metzdowd.com
In-Reply-To: <52697FA1.4070005@av8n.com>
Date: Sat, 26 Oct 2013 03:49:15 +0800
From: David Mercer <radix42@gmail.com>
To: Cryptography Mailing List <cryptography@metzdowd.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
--===============6827493403851394177==
Content-Type: multipart/alternative; boundary=089e0163548c8f301204e9960b5d
--089e0163548c8f301204e9960b5d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Fri, Oct 25, 2013 at 4:14 AM, John Denker <jsd@av8n.com> wrote:
> On 10/17/2013 12:43 PM, David Mercer wrote:
>
> > Sometime in the last two months I described the somewhat widespread iss=
ue
> > 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 t=
o
> > 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=E2=84=A2 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
--089e0163548c8f301204e9960b5d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Fri, Oct 25, 2013 at 4:14 AM, John Denker <span dir=3D"=
ltr"><<a href=3D"mailto:jsd@av8n.com" target=3D"_blank">jsd@av8n.com</a>=
></span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex">
On 10/17/2013 12:43 PM, David Mercer wrote:<br>
<br>
> Sometime in the last two months I described the somewhat widespread is=
sue<br>
> at VM hosting/cloud providers of provisioning VM's with the same<b=
r>
> /dev/urandom seed from the image template. firstboot scripts typically=
only<br>
> get run at image generation, and then the urandom seed is frozen in am=
ber,<br>
> as it were, in the VM image template file. It is a fairly trivial fix =
to<br>
> re-seed it from /dev/random (one line in the right place).<br>
<br>
I reckon that in most cases, it would be better to obtain the<br>
seed from the host's /dev/urandom (rather than /dev/random) to<br>
avoid problems with blocking, as discussed below.<br></blockquote><div><br>=
</div><div>Unfortunately access to the host hypervisor's /dev/urandom i=
sn't normally available.</div><div>=C2=A0</div><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex">
=C2=A0 The exception is in cases where you know you have a copious<br>
=C2=A0 supply of high-quality randomness available via /dev/random,<br>
=C2=A0 so that blocking is not an issue. =C2=A0Hint: turbid.<br></blockquot=
e><div><br></div><div>You aren't going to have lots high quality random=
ness available via /dev/random on the hypervisor in currently deployed VM h=
osting environments.</div>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex">
> The obvious place to do that, when the VM is actually provisioned, end=
s up<br>
> hurting deployment time due to sometimes blocking on /dev/random reads=
to<br>
> re-seed /dev/urandom.<br>
<br>
I'm mystified by that. =C2=A0We're talking about Linux /dev/urandom=
<br>
aren't we? =C2=A0That never blocks, not for reseeding or for anything<b=
r>
else. =C2=A0There have been proposals to change this, but that would<br>
be a Bad Idea=E2=84=A2 and I've never seen any blocking urandom device<=
br>
actually get distributed ... although perhaps I have overlooked<br>
something.<br>
<br></blockquote><div><br></div><div>I was talking about re-seeding /dev/ur=
andom when the on-disk seed file that is read at boot is identical across v=
irtual machine images. We're talking about the large VM hosting provide=
r use case. Lots of VM instances can be spun up at once on a hypervisor, an=
d re-seeding /dev/urandom from /dev/random can and will often block.</div>
<div><br></div><div>Note that on many (most?) data center grade rackmount s=
ervers you don't HAVE an audio port at all to run something like turbid=
against.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> =C2=A0This has led people to toss up their hands and do the<br>
> Wrong Thing of just provisioning, sometimes thousands, of VM's wit=
h the<br>
> same ... seed.<br>
<br>
That's a bizarre overreaction.<br>
=C2=A0++ It would make sense to switch from /dev/random to /dev/urandom,<br=
>
=C2=A0 since the latter never blocks.<br>
=C2=A0-- It makes no sense to switch from /dev/random to a constant.<br></b=
lockquote><div><br></div><div>Again, I appear to have been unclear, I'm=
talking about seeding /dev/urandom from /dev/random upon first boot of a V=
M that has a /dev/urandom seed stored on disk from when the parent VM that =
was imaged was last shutdown.</div>
<div>=C2=A0</div><div>-David Mercer</div><div><br></div></div></div></div>
--089e0163548c8f301204e9960b5d--
--===============6827493403851394177==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
--===============6827493403851394177==--
