From owner-freebsd-numerics@FreeBSD.ORG Wed Mar 18 18:41:46 2015 Return-Path: Delivered-To: freebsd-numerics@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A6E6D7E9; Wed, 18 Mar 2015 18:41:46 +0000 (UTC) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "gold.funkthat.com", Issuer "gold.funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 797A67B9; Wed, 18 Mar 2015 18:41:46 +0000 (UTC) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.14.5/8.14.5) with ESMTP id t2IIRlJb052061 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Mar 2015 11:27:47 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.14.5/8.14.5/Submit) id t2IIRkx4052060; Wed, 18 Mar 2015 11:27:46 -0700 (PDT) (envelope-from jmg) Date: Wed, 18 Mar 2015 11:27:46 -0700 From: John-Mark Gurney To: Pedro Giffuni Subject: Re: Random number generators Message-ID: <20150318182746.GI51048@funkthat.com> References: <7CBD7758-9472-4A2E-8065-EC6E68EE8DAB@FreeBSD.org> <20150317060310.GA21975@troutmask.apl.washington.edu> <00a001d060d7$0077f100$0167d300$@acm.org> <55086E2D.9080806@FreeBSD.org> <550874DE.3060700@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <550874DE.3060700@FreeBSD.org> X-Operating-System: FreeBSD 9.1-PRERELEASE amd64 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (gold.funkthat.com [127.0.0.1]); Wed, 18 Mar 2015 11:27:47 -0700 (PDT) Cc: freebsd-numerics@FreeBSD.org, dennis.hamilton@acm.org X-BeenThere: freebsd-numerics@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Discussions of high quality implementation of libm functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 18:41:46 -0000 Pedro Giffuni wrote this message on Tue, Mar 17, 2015 at 13:39 -0500: > On 03/17/15 13:18, Mehmet Erol Sanliturk wrote: > > > > On Tue, Mar 17, 2015 at 11:10 AM, Pedro Giffuni > > wrote: > > > > On 03/17/15 12:22, Dennis E. Hamilton wrote: > > > > There is a lot of discussion about qualities of Random Number > > generators on cryptography lists. MT is not a good choice for > > that, but it might not need to be important for other > > applications. > > > > There has been some recent work, PCG, that has attracted some > > attention, . There are good videos > > explaining what the approach is about as well. PCG also has > > implementations in C. (It is under the Apache License 2.0 > > too: for a minimal > > family and for ones with > > extended capabilities.) > > > > The analysis of what does and doesn't work, and how passing > > diehard is too easy, is also valuable. > > > > If you are serious about crypto grade randomness, libc is > > probably not the answer. Generally, I don't think reliance on > > a single generator for general purpose use and for > > cryptographic quality is going to work well. This is a very > > context-sensitive situation and addressing specific threat > > models against cryptographic PRGs is a very different matter > > from wanting unpredictable and good quality pseudo-randoms for > > simulations and other purposes. This is a statement I wholely agree with... If you need an RNG for repeatable simulations, then you should understand what you are getting, which means you won't be using random OS's random(3) call.. If you don't really care about repeatablility, then using the OS's CSPRNG should be just fine... > > The pcg-random link seems to be down now but for crypto, we have > > arc4random(3) which is pretty good and about to be improved further. > > > > Pedro. > > > > _______________________________________________ > > > > > > > > Three of the above links are accessible from here at Izmir , in Turkey . > > > > It just came up here. It looks like PCG compares favorably with > ChaCha20, but > this is PCG's page and the comparison is not very clear ("Secure" vs > "Challenging"?) i.e. it's not secure, which means it MUST NOT be used for nonces and key material... Which makes it unsuitable for a replacement for any arc4rand* function, be it userland or kernel... The table on the page is incorrect... ChaCha20 MUST ALWAYS be Reproducible otherwise it isn't secure, same goes for arc4random... They said not always reproducible, but that's just because it is seeded differently, and implementations don't allow you to provide a seed manually... Most implementations automatically get their seed from another secure PRNG, usually the kernel.. If someone were to use their own implementation which allowed a custom seed (which this page seems to require) then it is reproducible.. I find it funny that they consider it a problem w/ arc4random that it can't be used w/ a user provided seed... That's a feature for what arc4random is documented as being used for... It would be a major security issue if it was easy for a program to make arc4random to return predictable numbers... (See recent problem when arc4random was being used w/ a possibly predictable seed.) I would like to know what they think the period of ChaCha20... In one place they list it as being huge, but in the negatives they say: "Has a much smaller period than might be inferred from the size of the generator state." I don't know how they can predict the period of ChaCha20.. If they mean you never reseed/stir it, then it's by definition 2^69 as that is the counter roll over (each counter generates 64 bytes of output, so +2^5), or maybe 2^133 bytes if you include the IV as part of the counter, but if you reseed/stir, then the period would be very long, possibly effectively infinite if you use an external source for seeding... As someone who worked on a program that pretty much was just: if (customrandom() % 4) dominorwork(); and where customrandom was aes256-ctr, I still only saw something like 10-20% of the program's time generating randomness... And this was a pure software implementation of aes256, not AES-NI accelerated.. Yes, having fast random numbers for simulations can be important, but is very different problem than the one I'm addressing... It's a shame they didn't just list MB/sec under the time performance column... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."