[Bug libc/15615] Poor quality output from rand_r

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

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

--- Comment #4 from Rich Felker <bugdal at aerifal dot cx> ---
On Fri, Jun 14, 2013 at 12:10:59PM +0000, neleai at seznam dot cz wrote:
> To test rand_r equivalent I wrote a simple generator (which is for
> mostly to test performance, I did not look for quality.)
> 
>   movd    (%rdi),%xmm0
>   movdqa %xmm0,%xmm1
> 
>   aesenc %xmm0,%xmm1
>   aesenc %xmm0,%xmm1
>   aesenc %xmm0,%xmm1
>   aesenc %xmm0,%xmm1
>   movd %xmm1, (%rdi)
>   movd %xmm1, %eax
>   shr $1, %eax

There's no reason to believe this code will have acceptable period or
be unbiased. Instead of storing the AES result back to the state, you
should simply increment the state value (or advance it via a LCG). In
other words, low-period PRNG using a cryptographic block cipher must
use it in CTR mode unless the cipher itself has proper period when
composed with itself (which is extremely unlikely but easily testable
when the period is bounded by 2^32).

In any case, I think the extreme low quality of rand_r qualifies as a
bug. I'm not partial to any particular fix, but any fix should have:

- maximal possible period given the constraint of 32-bit state, i.e.
  period of 2^32.

- no bias (equal frequency of all outputs)

- minimal/no statistical flaws other than those mandated by the
  constraint of short period (which in turn comes from the constraint
  of 32-bit state).

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