[147728] in cryptography@c2.net mail archive
Re: [Cryptography] /dev/random is not robust
daemon@ATHENA.MIT.EDU (Yaron Sheffer)
Fri Oct 18 12:38:05 2013
X-Original-To: cryptography@metzdowd.com
Date: Fri, 18 Oct 2013 14:14:21 +0300
From: Yaron Sheffer <yaronf.ietf@gmail.com>
To: David Mercer <radix42@gmail.com>
In-Reply-To: <CADpjbE2UZPp9=boxoSNhN2E3Dn71CgWJvJ=NPFcOWP9+mSGkxg@mail.gmail.com>
Cc: Cryptography Mailing List <cryptography@metzdowd.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
> 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).
>
> 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. 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 /dev/urandom seed.
>
> Quequeing up pre-provisioned system images with the one liner to re-seed
> /dev/urandom from outside the image itself (other per-system security
> related config can happen here, too) takes care of it, but then you get
> people whining about shuffling around image files rather than quick copy on
> write delployments of VM images.
>
> Then someone at that provider has to realize you just do the queueing
> per-storage system used by each hypervisor host against copy-on-write
> images. This chain of logic and refinements thereto have not, to my
> knowledge, been written up in any widely known best practices document. I'd
> love to be shown somewhere they have to point people at if it exists.
>
> -David Mercer
>
Hi David,
IIRC there was talk of a new version of RFC 4086 (Randomness
Recommendations) being worked on. You might want to contact the authors,
particularly Donald Eastlake, and contribute some text.
Thanks,
Yaron
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
