From owner-freebsd-chat Tue May 1 12:16:44 2001 Delivered-To: freebsd-chat@freebsd.org Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135]) by hub.freebsd.org (Postfix) with ESMTP id 4F5A437B423 for ; Tue, 1 May 2001 12:16:40 -0700 (PDT) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.3/8.9.3) id MAA27601; Tue, 1 May 2001 12:16:37 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp05.primenet.com, id smtpdAAA0NaW21; Tue May 1 12:16:27 2001 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id MAA05406; Tue, 1 May 2001 12:20:35 -0700 (MST) From: Terry Lambert Message-Id: <200105011920.MAA05406@usr06.primenet.com> Subject: Re: BSD libc for Linux? To: kris@obsecurity.org (Kris Kennaway) Date: Tue, 1 May 2001 19:20:34 +0000 (GMT) Cc: tlambert@primenet.com (Terry Lambert), kris@obsecurity.org (Kris Kennaway), jason@smethers.net (Jason Smethers), chat@FreeBSD.ORG In-Reply-To: <20010501113148.A9444@xor.obsecurity.org> from "Kris Kennaway" at May 01, 2001 11:31:48 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > I wish the non-scientists who keep claiming that it is > > legitimate to break this code, and who think that when you > > multiply two random numbers that the result is "even more > > random than before the multiply", and who think randomness > > is more important than pseudo randomness... > > I'm a physicist by day. I can think of few things worse than having a > lengthy simulation ruined by the poor statistical properties of the > old rand() algorithm. Then use ?and48(); it's a linear congruential generator. It's all a matter of potency and periodicity. The most important thing for physics work, IMO, is repeatability. > > See also the "spectral test" in section 3.3.4 for the definition > > of "acceptably random". AFAIK, the "improved" FreeBSD code has > > not yet passed this test, which is currently the strongest test > > known. > > Last time this came up we established you had no idea about the actual > algorithm in use by rand(), and you still haven't shown that you > actually understand its properties and why they needed to be fixed. > > Tell me, please, Terry, have YOU run that spectral test on the old > rand()? Yes. Just like random(), it _fails_ the test, just as you would expect from a poor generator. And just like you'd expect, ?rand48() passes. > > The purpose of rand() is to provide a sound mathematical basis > > from which real work can be accomplished, not to make it so some > > Right. *Now*, it does this. No, it doesn't. Now it no longer repeats in the exact same sequence that it has historically repeated. It is no longer useful for repeating sequences. > > jackass can protect his password file with security through > > obscurity, without having to get off their duff and expend any > > effort. > > And this of course requires completely different mathematical > properties which is why rand() or random() is not used for seeding > password hash functions. I see the rand() change to an alias of random() as part and parcel of the /dev/random crap, where people who are not PhD's in math are pretending they are, and the system is becoming poorer for it. If people want random() instead of rand(), they should damn well call "random()" instead of calling "rand()". Additive feedback generators suck almost as much as the original rand() algorithm, which at least had the merit of repeatability over long periods of time, so that papers written 10 years ago yield the same results today as they did then. Consider that someone may have erroneously used rand() as something other than a repeatable pseudo-random sequence, and then used that for the basis of a paper. Now we have no comparative method for invalidating the conclusions of that paper, since it looks like rand() "works", when in fact, we should be questioning the methods used to arrive at the data. Only now, we can't, because someone took access to those methods away from us, preventing us from doing a comparative analysis. Ugh. Don't change boats in the middle of the river. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message