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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <MDEHLPKNGKAHNMBLJOLKGEHJILAC.davids@webmaster.com>
Date:	Sat, 8 Dec 2007 12:26:27 -0800
From:	"David Schwartz" <davids@...master.com>
To:	"Theodore Tso" <tytso@....edu>,
	"Mike McGrath" <mmcgrath@...hat.com>,
	"Jon Masters" <jonathan@...masters.org>,
	"Matt Mackall" <mpm@...enic.com>,
	"Alan Cox" <alan@...rguk.ukuu.org.uk>,
	"Ray Lee" <ray@...rabbit.org>, "Adrian Bunk" <bunk@...nel.org>,
	"Marc Haber" <mh+linux-kernel@...schlus.de>,
	<linux-kernel@...r.kernel.org>
Subject: RE: Why does reading from /dev/urandom deplete entropy so much?

> 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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/