RE: Why does reading from /dev/urandom deplete entropy so much?

From: "David Schwartz" <davids@webmaster.com>
To: "Theodore Tso" <tytso@mit.edu>,
	"Mike McGrath" <mmcgrath@redhat.com>,
	"Jon Masters" <jonathan@jonmasters.org>,
	"Matt Mackall" <mpm@selenic.com>,
	"Alan Cox" <alan@lxorguk.ukuu.org.uk>,
	"Ray Lee" <ray@madrabbit.org>, "Adrian Bunk" <bunk@kernel.org>,
	"Marc Haber" <mh+linux-kernel@zugschlus.de>,
	<linux-kernel@vger.kernel.org>
Subject: RE: Why does reading from /dev/urandom deplete entropy so much?
Date: Sat, 8 Dec 2007 12:26:27 -0800	[thread overview]
Message-ID: <MDEHLPKNGKAHNMBLJOLKGEHJILAC.davids@webmaster.com> (raw)
In-Reply-To: <475AE2ED.3050700@garzik.org>

> heh, along those lines you could also do
>
> 	dmesg > /dev/random
>
> <grin>
>
> dmesg often has machine-unique identifiers of all sorts (including the
> MAC address, if you have an ethernet driver loaded)
>
> 	Jeff

A good three-part solution would be:

1) Encourage distributions to do "dmesg > /dev/random" in their startup
scripts. This could even be added to the kernel (as a one-time dump of the
kernel message buffer just before init is started).

2) Encourage drivers to output any unique information to the kernel log. I
believe all/most Ethernet drivers already do this with MAC addresses.
Perhaps we can get the kernel to include CPU serial numbers and we can get
the IDE/SATA drivers to include hard drive serial numbers. We can also use
the TSC, where available, in early bootup, which measures exactly how long
it took to get the kernel going, which should have some entropy in it.

3) Add more entropy to the kernel's pool at early startup, even if the
quality of that entropy is low. Track it appropriately, of course.

This should be enough to get cryptographically-strong random numbers that
would hold up against anyone who didn't have access to the 'dmesg' output.

DS