[147841] in cryptography@c2.net mail archive
Re: [Cryptography] provisioning a seed for /dev/urandom
daemon@ATHENA.MIT.EDU (John Denker)
Fri Oct 25 14:55:52 2013
X-Original-To: cryptography@metzdowd.com
Date: Thu, 24 Oct 2013 13:14:25 -0700
From: John Denker <jsd@av8n.com>
To: cryptography@metzdowd.com
In-Reply-To: <loom.20131024T065916-402@post.gmane.org>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
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 on=
ly
> 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.
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.
> 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=99 and I've never seen any blocking urandom device
actually get distributed ... although perhaps I have overlooked =
something.
> 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.
Note that the seed in question is being used to initialize the =
guest's PRNG, so there is no reason to go overboard with the quality =
of the seed. If the guest wanted hard-core industrial-strength =
entropy, it wouldn't be using its PRNG for that anyway.
If you are provisioning large numbers of VMs and/or hardware
devices, the per-unit cost of provisioning a proper seed is =
essentially zero.
=3D=3D=3D=3D=3D=3D
Tangential remark: /dev/urandom never blocks. Occasionally I see
proposals to make it "better" by allowing it to block under some
conditions, but IMHO this is a terrible idea, for reasons that should
be clear from the story related above. If given a source that blocks,
users will just not use it. They will do something else instead, and =
the results will almost certainly be worse, not better.
The key is to make sure that /dev/urandom is always sufficiently
well seeded, so that it is always ready to use (for the appropriate
class of purposes).
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Theodore Ts'o <tytso <at> mit.edu> wrote:
>>> The major problem which could be considered a "Linux distribution
>>> issue" is ssh host key generation, which is done by the boot scripts
>>> if the ssh host keys do not exist. It would be much better if this
>>> was done on the first TCP connection to the ssh server, but that would
>>> require changes to sshd.
On 10/23/2013 10:06 PM, Alon Ziv asked:
>> Can't this be solved (in some distros at least...) by switching SSHD to =
use =
>> on-demand activation (a la inetd / systemd)? [I know the SSHD manpage cl=
aims =
>> this is inadvisable, but I suspect the reason - response "may take tens =
of =
>> seconds" - is decades out of date even for small devices...]
ssh is built on openssl which prefers to initialize itself from
/dev/urandom (although it "can" use other sources).
So once again the key to making the problem go away is to make =
sure that /dev/urandom is properly seeded and ready to use.
When provisioning VMs or anything else, this should not be hard
to do. It is already necessary to provision things like the
hostname and MAC address, and it is not rocket science to provision =
the seed-file at the same time.
There are additional issues that arise when booting from a genuinely
read-only system image, such as a CDROM, but there are other ways of
addressing these issues. Options include:
-- mounting a second disk containing the seed file ... and teaching
the guest system to find this and use it properly.
-- passing a seed on the kernel cmdline.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Constructive suggestion:
It would help to have sort of best-practices document that explains =
to VM providers and device manufacturers the importance of provisioning =
a unique seed ... and tells them how to do it properly.
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
