From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18311 invoked by alias); 25 Jun 2013 06:58:27 -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 18208 invoked by uid 89); 25 Jun 2013 06:58:18 -0000 X-Spam-SWARE-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_00,DOS_RCVD_IP_TWICE_B,FREEMAIL_FROM,SPF_NEUTRAL,TW_DQ,TW_VD autolearn=no version=3.3.1 X-Spam-User: qpsmtpd, 2 recipients Received: from popelka.ms.mff.cuni.cz (HELO popelka.ms.mff.cuni.cz) (195.113.20.131) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Tue, 25 Jun 2013 06:58:17 +0000 Received: from domone.kolej.mff.cuni.cz (popelka.ms.mff.cuni.cz [195.113.20.131]) by popelka.ms.mff.cuni.cz (Postfix) with ESMTPS id 13773695BE; Tue, 25 Jun 2013 08:58:12 +0200 (CEST) Received: by domone.kolej.mff.cuni.cz (Postfix, from userid 1000) id 06A325FB95; Tue, 25 Jun 2013 09:39:44 +0200 (CEST) Date: Tue, 25 Jun 2013 06:58:00 -0000 From: =?utf-8?B?T25kxZllaiBCw61sa2E=?= To: bugdal at aerifal dot cx Cc: glibc-bugs@sourceware.org Subject: Re: [Bug libc/15615] Poor quality output from rand_r Message-ID: <20130625073944.GA27305@domone> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-SW-Source: 2013-06/txt/msg00202.txt.bz2 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 --- > 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.