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 <>
To:	Matt Mackall <>
Cc:	Alan Cox <>, Ray Lee <>,
	Adrian Bunk <>,
	Marc Haber <>,
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
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists