From owner-freebsd-current Sun Feb 2 12:22: 7 2003 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8A2FE37B401; Sun, 2 Feb 2003 12:22:05 -0800 (PST) Received: from storm.FreeBSD.org.uk (storm.FreeBSD.org.uk [194.242.157.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4BA2543F85; Sun, 2 Feb 2003 12:22:03 -0800 (PST) (envelope-from mark@grondar.org) Received: from storm.FreeBSD.org.uk (Ugrondar@localhost [127.0.0.1]) by storm.FreeBSD.org.uk (8.12.6/8.12.6) with ESMTP id h12KLsLf079645; Sun, 2 Feb 2003 20:21:54 GMT (envelope-from mark@grondar.org) Received: (from Ugrondar@localhost) by storm.FreeBSD.org.uk (8.12.6/8.12.6/Submit) with UUCP id h12KLsZW079644; Sun, 2 Feb 2003 20:21:54 GMT X-Authentication-Warning: storm.FreeBSD.org.uk: Ugrondar set sender to mark@grondar.org using -f Received: from grondar.org (localhost [127.0.0.1]) by grimreaper.grondar.org (8.12.6/8.12.6) with ESMTP id h12KF5aX050851; Sun, 2 Feb 2003 22:15:05 +0200 (SAST) (envelope-from mark@grondar.org) From: Mark Murray Message-Id: <200302022015.h12KF5aX050851@grimreaper.grondar.org> To: Bakul Shah Cc: "Jeroen C. van Gelderen" , phk@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: rand() is broken In-Reply-To: Your message of "Sun, 02 Feb 2003 11:55:25 PST." <200302021955.OAA20742@glatton.cnchost.com> Date: Sun, 02 Feb 2003 20:15:05 +0000 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Bakul Shah writes: > > RC4 is _utterly_ repeatable, given a particular seed/key. > > May be but it is not the same as the current random(). Also, > I know you will want to change it the next time some one > points out a problem with RC4. Yes. This is called "fixing bugs". We (OS maintainers) reserve that right. If you need something more predictable, please maintain your own code. > > Yes. And it breaks, and we have a complainant. > > So create a new function! Or use a different function to > generate or initialize the seed. I think one has to treat a > behavior bug very carefully. If enough people are depending > on it, it pretty much has to get enshrined as part of the > spec -- sort of like the timeout arg to select(). The documented behaviour is rand(3)/random(3). No guarantee of lifelong repeatability is provided. Would you prefer that we defined random() as int random(void) { static int retval = 0; return retval++; } and worked on statistical randomness somewhere else? > > The random() function in libc is documented to give the same > > pseudo-random output for a particular seed. If you link your > > program against a _different_ libc, you cannot expect your > > results to follow a particular number sequence. > > There is an expectation that on subsequent releases of the > same OS things continue to work. Where is that expectation guaranteed? Where is that expectation supported? > Historically rand() and random() under unix have been used > the most for simulation. [aside: Earl T. Cohen (the author > of random(3)) also has had a lot to do in this area] > > Why not totally separate all uses of crypto related random > number generator uses from the traditional simulation use? > That way you can change crypto_random to your heart's content > as the crypto needs change (as they will). The two are related topics. Consider the (joking reference to) "elephant-free biology". :-) M -- Mark Murray iumop ap!sdn w,I idlaH To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message