This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/15615] Poor quality output from rand_r
- From: "neleai at seznam dot cz" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Tue, 25 Jun 2013 06:58:21 +0000
- Subject: [Bug libc/15615] Poor quality output from rand_r
- Auto-submitted: auto-generated
- References: <bug-15615-131 at http dot sourceware dot org/bugzilla/>
http://sourceware.org/bugzilla/show_bug.cgi?id=15615
--- Comment #5 from Ondrej Bilka <neleai at seznam dot 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.
--
You are receiving this mail because:
You are on the CC list for the bug.