Re: [Bug libc/15615] Poor quality output from rand_r

["Ondřej Bílka" <neleai@seznam.cz>]

On Fri, Jun 14, 2013 at 03:37:30PM +0000, bugdal at aerifal dot cx wrote:
> 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

Well I wrote above 

> > To test rand_r equivalent I wrote a simple generator (which is for
> > mostly to test performance, I did not look for quality.)
Which was only to show that using cryptographic functions is not too
slow. (You can alternatively use CRC32 instruction.)

I am still not convinced that changing implementation is improvement as
everybody which cares about quality uses random_r. 

I would accept an warning that rand_r is weak and one should use
random_r.