From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4083 invoked by alias); 14 Jun 2013 15:37:36 -0000 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org Received: (qmail 4053 invoked by uid 55); 14 Jun 2013 15:37:32 -0000 From: "bugdal at aerifal dot cx" To: glibc-bugs@sourceware.org Subject: [Bug libc/15615] Poor quality output from rand_r Date: Fri, 14 Jun 2013 15:37:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: libc X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: bugdal at aerifal dot cx X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2013-06/txt/msg00111.txt.bz2 http://sourceware.org/bugzilla/show_bug.cgi?id=15615 --- Comment #4 from Rich Felker --- 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.