Date: Wed, 24 Sep 1997 11:47:11 +0400 (MSD) From: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= <ache@nagual.pp.ru> To: Mark Murray <mark@grondar.za> Cc: cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG, cvs-games@FreeBSD.ORG Subject: Re: cvs commit: src/games/arithmetic arithmetic.c Message-ID: <Pine.BSF.3.96.970924111647.14121A-100000@lsd.relcom.eu.net> In-Reply-To: <199709240702.JAA01227@greenpeace.grondar.za>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 24 Sep 1997, Mark Murray wrote: > =?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. 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. > > 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. 1) /dev/random driver can use user call time as additional randomness source. 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? 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. 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. > 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? 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. 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. -- Andrey A. Chernov <ache@null.net> http://www.nagual.pp.ru/~ache/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.970924111647.14121A-100000>