[Bug libc/15615] Poor quality output from rand_r

["neleai at seznam dot cz" <sourceware-bugzilla@sourceware.org>]

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.