From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25805 invoked by alias); 13 Jun 2013 12:38:52 -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 25738 invoked by uid 55); 13 Jun 2013 12:38:43 -0000 From: "bugdal at aerifal dot cx" To: glibc-bugs@sourceware.org Subject: [Bug libc/15615] Poor quality output from rand_r Date: Thu, 13 Jun 2013 12:38: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/msg00101.txt.bz2 http://sourceware.org/bugzilla/show_bug.cgi?id=15615 --- Comment #2 from Rich Felker --- On Thu, Jun 13, 2013 at 08:26:27AM +0000, neleai at seznam dot cz wrote: > A problem here is that for many users predictability is much more > important than quality. Developer expects that when he uses rand_r with > state that he controls will not vary. This can cause extra debbuging hastle > when > code mysteriously fails on one machine but not other or desync issues. Could you explain better what you're concerned about? By "predictable", do you mean keeping the same sequence it's had in the past? Aside from that, any PRNG with 32-bit state and 31-bit output is equally "predictable". > > To fully fix rand_r, the approach of concatenating multiple iterations should > > be abandoned in favor of a single-LCG-iteration approach followed by an > > invertable transformation on the output. Obviously a 32-bit cryptographic block > > cipher would give the best statistical properties, but it would be slow. In > > This is false, I have a replacement of this with four rounds of AES. On > intel using aesenc I performance is better than current, I did not > propose that due of problems above. I wrote a RFC for random > replacement on libc-alpha, browse archives. AES itself does not use 32-bit blocks, so you must be using a modified version. Would you care to explain? I searched the archives but could not find your post. -- You are receiving this mail because: You are on the CC list for the bug.