This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/15615] Poor quality output from rand_r
- From: "neleai at seznam dot cz" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Thu, 13 Jun 2013 08:26:27 +0000
- Subject: [Bug libc/15615] Poor quality output from rand_r
- Auto-submitted: auto-generated
- References: <bug-15615-131 at http dot sourceware dot org/bugzilla/>
http://sourceware.org/bugzilla/show_bug.cgi?id=15615
--- Comment #1 from Ondrej Bilka <neleai at seznam dot cz> ---
On Wed, Jun 12, 2013 at 11:39:09PM +0000, bugdal at aerifal dot cx wrote:
> http://sourceware.org/bugzilla/show_bug.cgi?id=15615
>
> Bug ID: 15615
> Summary: Poor quality output from rand_r
> Product: glibc
> Version: unspecified
> Status: NEW
> Severity: normal
> Priority: P2
> Component: libc
> Assignee: unassigned at sourceware dot org
> Reporter: bugdal at aerifal dot cx
> CC: drepper.fsp at gmail dot com
>
> Created attachment 7075
> --> http://sourceware.org/bugzilla/attachment.cgi?id=7075&action=edit
> test program to generate data for analysis by dieharder
>
> Implementing a decent rand_r is very tricky because the interface requirement
> forces the full PRNG state to fit in 32 bits; this rules out pretty much all
> good PRNGs. Nonetheless, glibc's rand_r is much worse than it needs to be.
>
> glibc's rand_r is based on the LCG published in the C standard:
>
> next = next * 1103515245 + 12345;
> return next / 65536 % 32768;
>
A problem here is that for many users predictability is much more
important than quality. Developer expects that when he uses rand_r with
state that he controls will not vary. This can cause extra debbuging hastle
when
code mysteriously fails on one machine but not other or desync issues.
> To fully fix rand_r, the approach of concatenating multiple iterations should
> be abandoned in favor of a single-LCG-iteration approach followed by an
> invertable transformation on the output. Obviously a 32-bit cryptographic block
> cipher would give the best statistical properties, but it would be slow. In
This is false, I have a replacement of this with four rounds of AES. On
intel using aesenc I performance is better than current, I did not
propose that due of problems above. I wrote a RFC for random
replacement on libc-alpha, browse archives.
--
You are receiving this mail because:
You are on the CC list for the bug.