Date: Sun, 02 Feb 2003 19:43:14 +0000 From: Mark Murray <mark@grondar.org> To: David Malone <dwmalone@maths.tcd.ie> 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: <200302021943.h12JhEaX050421@grimreaper.grondar.org> In-Reply-To: Your message of "Sun, 02 Feb 2003 19:35:10 GMT." <20030202193510.A6945@graves.maths.tcd.ie>
next in thread | previous in thread | raw e-mail | index | archive | help
David Malone writes: > On Sun, Feb 02, 2003 at 07:08:47PM +0000, Mark Murray wrote: > > RC4 is _utterly_ repeatable, given a particular seed/key. > > 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. > > > The old 16 bit rand() was broken enough that it didn't matter > > > much (read: _I_ don't care) if its behavior got changed but > > > random() has a pretty long cycle and enough "randomness" to > > > be very useful and it *is* used. > > > > Yes. And it breaks, and we have a complainant. > > I thought the complaint was about rand, not random? Erm, yes. Similar difference though. PRNGs are _trouble_ unless designed properly. > > > If you think random() is not random enough for your purposes, > > > go create a new function with a *new* name. > > > > Any supporters of this request? > > 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? > I'd suggest we ammend the rand and random man pages saying that sequences > produced from either cannot be expected to be suitable for cryptographic > purposes, but are should be OK for simulation and games. (I guess a > couple of numbers produced after calling srandomdev might be safe, > but I wouldn't like to bet on them being that safe...) I'm fine with this. > 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. Cast-in-stone algorithms are dumb, but if you really want those, its probably best to put them in your own code. 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?200302021943.h12JhEaX050421>