Date: Wed, 24 Sep 1997 20:17:58 +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: <199709241818.UAA05817@greenpeace.grondar.za>
next in thread | raw e-mail | index | archive | help
=?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= wrote: > > 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. > > randomnes of srandom(time) was never good enough, I remember well broken > hack map or repeated fortunes... Safest way is replace all occurances than > will be hitted sometimes. Agreed. > > 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. > > 1) /dev/random driver can use user call time as additional randomness > source. True, but not relevant. > 2) To say true, any user can read /dev/urandom from shell forever. The > generator must be resistent of such sort of attack or its usability is in > a big question. Why you talk about such minor thing as repeated fortune > calls while anybody (and especially hacker) can just say: > cat < /dev/urandom > /dev/null > eating all possible true randomness? True. But this is an attack. There will be improvements to /dev/random (I have code ATM), that can help here. Userland programs should not coperate with doubtful behaviour. > 3) If it is a sparse resource as you say, it must be _not_ available for > user. I.e. only root or "crypto" group can read generator. It makes > C-library functions based on it (like arc4random() or srandomdev()) > useless for anybody but hypotetical "crypto software". It means that > the driver needs splitting again provide one abusable interface for user > programs and sparse intefrace for root only. All of what you say above is true. All ove the above should have been done _before_ giving userland default use of /dev/random. > F.e. /dev/rrandom for root and /dev/urandom for users. It makes harder > for crypto software to access /dev/rrandom without library functions > which understand another device (/dev/urandom), but fallback can be > implemented just inside library functions, i.e. open /dev/rrandom first, > if it fails (for non-root), open plain /dev/urandom. Reasonable? > > The whole purpose of adding in /dev/random was for security use. > > It provide true randomnes which can be used in more wide scope, so > why not use it and keep it for hypotetical crypo software while real > programs have a big lack of true randomness? What of these programs _NEED_ real randomness. How many of them can get away with a _good_ approximation? What about somthing that has far more of a requrement for randomness? "No sorry, you cant seed your TCP sequnces randomly, the games have got all the random bits"? > I see NetBSD/OpenBSD use it in more wide scope, i.e. for user programs. > They even have /dev/arandom we not have, they claim it faster. We will have this. (I have the NetBSD code). > Converting /usr/games is final step of switching to srandomdev(), > all main utilites already fixed and you not come with discussion > in long period while it happens. Apologies for that. I was out of discussions for a long time while my equipment was stolen, and while I was coming back to speed. I am not screaming for you to change everything back to srandom(time()) at this late stage. I am, hoever quite interested in my opinions being on record. So let's declare this debate over with both of us having stated our points, and leave it at that. OK? :-) 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?199709241818.UAA05817>