This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
Re: [Bug libc/15615] Poor quality output from rand_r
- From: OndÅej BÃlka <neleai at seznam dot cz>
- To: bugdal at aerifal dot cx <sourceware-bugzilla at sourceware dot org>
- Cc: glibc-bugs at sourceware dot org
- Date: Tue, 25 Jun 2013 09:39:44 +0200
- Subject: Re: [Bug libc/15615] Poor quality output from rand_r
- References: <bug-15615-131 at http dot sourceware dot org/bugzilla/> <bug-15615-131-si9rRV04Ff at http dot sourceware dot org/bugzilla/>
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.