Date: Sun, 02 Feb 2003 20:05:29 +0000 From: David Malone <dwmalone@maths.tcd.ie> To: Mark Murray <mark@grondar.org> Cc: Bakul Shah <bakul@bitblocks.com>, "Jeroen C. van Gelderen" <jeroen@vangelderen.org>, phk@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: rand() is broken Message-ID: <200302022005.aa62194@salmon.maths.tcd.ie> In-Reply-To: Your message of "Sun, 02 Feb 2003 19:43:14 GMT." <200302021943.h12JhEaX050421@grimreaper.grondar.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> > I presume it also produces reasonably uniform output for most > > seeds too. > Yes. Modulo the requirement to "burn" a bit of output after a > reseed. I guess the crypto guys would have junked it otherwise ;-) > > I thought the complaint was about rand, not random? > Erm, yes. Similar difference though. PRNGs are _trouble_ unless > designed properly. I thought random was relatively carefully designed, though I don't know what the design goals were. I guess we should find out so we can do a fair comparison. > > I'd support that. People who are using rand and random for crypto type > > randomness are deceiving themselves, as neither are portably suitable > > for that use. Lots of people are using rand, random and the rand48 > > suite for simulation or games, and this type of randomness has different > > requirements (as Bakul points out - repeatability being a useful one). > Repeatability is fine. Is convergence-to-constant OK? While we have no obligation to keep our implimantation constant accross between versions of libc, it may be a pain for users if we change the implimentation. We should just consider that before we decide to make a change. If it our change really is an improvement for most users, then it may be worth making anyway. [I presume you mean our rand* implimentation is slowly converging-to-constant code ;-] > > The man page can refer people on to arc4random, the apropriate OpenSSL > > pages, uuidgen and so on. As different consumers have different, sometimes > > contradictory, requirements for "randomness" it seems foolish to try to > > lump them all into one group of functions. > Yes. We should separately document (or at least clarify) the differences > between cryptographic randomness and statistical randomness. We should also > make sure that both are bug-free. Good idea - though it might make a better paper than a man page! > Cast-in-stone algorithms are dumb, but if > you really want those, its probably best to put them in your own code. Indeed, that's what I've done when I really want portable repeatibility. Infact the old crappy rand() implimentation had some interesting interactions when used when one of the MSc students here used it to test some of the AES candidates. [It may be mentioned in that document that I sent you recently.] David. 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? <200302022005.aa62194>