[Bug libc/15615] Poor quality output from rand_r

["bugdal at aerifal dot cx" <sourceware-bugzilla at sourceware dot org>]

http://sourceware.org/bugzilla/show_bug.cgi?id=15615

--- Comment #2 from Rich Felker <bugdal at aerifal dot cx> ---
On Thu, Jun 13, 2013 at 08:26:27AM +0000, neleai at seznam dot cz wrote:
> 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.

Could you explain better what you're concerned about? By
"predictable", do you mean keeping the same sequence it's had in the
past? Aside from that, any PRNG with 32-bit state and 31-bit output is
equally "predictable".

> > 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.

AES itself does not use 32-bit blocks, so you must be using a modified
version. Would you care to explain? I searched the archives but could
not find your post.

-- 
You are receiving this mail because:
You are on the CC list for the bug.