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]

Date:	Tue, 4 Dec 2007 14:50:21 -0500
From:	Theodore Tso <tytso@....edu>
To:	Matt Mackall <mpm@...enic.com>
Cc:	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?

On Tue, Dec 04, 2007 at 12:02:37PM -0600, Matt Mackall wrote:
> On Tue, Dec 04, 2007 at 04:55:02PM +0000, Alan Cox wrote:
> > > cryptographically strong stream it'll provide when /dev/random is
> > > tapped? In principle, this'd leave more entropy available for
> > > applications that really need it, especially on platforms that don't
> > > generate a lot of entropy in the first place (servers).
> > 
> > 
> > As reported about a month ago, the evidence is that the /dev/random
> > stream is not cryptographically strong. Collecting uuids generated from
> > the kernel uuid random generator from the random generator in the kernel
> > shows abnormal patterns of duplicates.
> 
> Pointer, please.

Alan, are you sure you're not talking about Helge Deller's attempt to
push a Time-based UUID generator into the kernel because you can get
duplicates from the current userspace library?

I've not heard of *any* claim where the kernel uuid random generator
has been returning duplicates.

						- Ted

P.S.  Probably the right approach for Helge is to create a daemon
started at boot time with privileges to write the appropriate state
file to prevent duplicates across reboots, and then to change the uuid
library to use the daemon if it is available (accessed via a Unix
domain socket), or to use its existing algorithm (which is fine unless
you have multiple threads wanting to generate large numbers of UUIDs
per second in parallel), and you want to use time-based UUID's because
they have better b-tree characteristics when you use them as indexes
into a database.
--
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/