Date: Wed, 24 Sep 1997 09:02:31 +0200 From: Mark Murray <mark@grondar.za> To: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= <ache@nagual.pp.ru> Cc: Mark Murray <mark@grondar.za>, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG, cvs-games@FreeBSD.ORG Subject: Re: cvs commit: src/games/arithmetic arithmetic.c Message-ID: <199709240702.JAA01227@greenpeace.grondar.za>
next in thread | raw e-mail | index | archive | help
=?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= wrote: > 1) srandomdev() is designed to replace all srandom(time()) or > similar occurances. Games should not be using this. if the randomness from srandom(time()) is not good enough, then we need to think of other algorithms, like md5. > 2) cryptographics generator will be only better (less predictable) if > rolled more Not true. This is true randomness, not a linear congruential driver. /dev/random gets _actual_ randoness from its environment, and this may be a sparse resourse. What you should be doing rather is (say) MD5'ing the output of `ps -ax`. > 3) There is no resource waste here since /dev/urandom readed only > once per program. ...and some programs may be used heavily by users, thus depleting the stash of randomness. I have seen bored users sit for hours, running fortune(6). One srandomdev() call per <uparrpw><enter> on a machine with little environmental noise, and that machine's pool-of-entropy is history. I would prefer to see this use of randomness set as an option, not the default, if at all. The whole purpose of adding in /dev/random was for security use. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709240702.JAA01227>