[Cryptography] /dev/random is not robust

Yaron Sheffer yaronf.ietf at gmail.com
Fri Oct 18 07:14:21 EDT 2013


> 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



More information about the cryptography mailing list