Date: Sun, 02 Feb 2003 20:15:05 +0000 From: Mark Murray <mark@grondar.org> To: Bakul Shah <bakul@bitblocks.com> Cc: "Jeroen C. van Gelderen" <jeroen@vangelderen.org>, phk@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: rand() is broken Message-ID: <200302022015.h12KF5aX050851@grimreaper.grondar.org> In-Reply-To: Your message of "Sun, 02 Feb 2003 11:55:25 PST." <200302021955.OAA20742@glatton.cnchost.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200302022015.h12KF5aX050851>