Date: Wed, 24 Sep 1997 22:59:36 +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.970924224637.23175A-100000@lsd.relcom.eu.net> In-Reply-To: <199709241818.UAA05817@greenpeace.grondar.za>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 24 Sep 1997, Mark Murray wrote: > > 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. With splitting /dev/*random to userland and root random we even don't need to care about this attack or any userland program which use srandomdev(). > > 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. Well, we can't change past. Lets think how to fix situation... > > 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? I think true random pool must be separated between userland and root devices and true randomness must come to root device first, then, when root pool is full, it can come to userland pool too. After it will be implemented I'll fix sdevrandom and arc4random to open root device first with fallback to userland device. > > 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). I mean we don't have ARC4 hash in the kernel, only MD5 which is slower. > I was out of discussions for a long time while my equipment was stolen, > and while I was coming back to speed. To be nitpicking: :-) the process was started long before this bad thing happens with you... > 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? :-) Of course I am interested to resolve this issue too, maybe I'll send you kernel driver patch for review if I'll understand how to fix it quickly. -- 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.970924224637.23175A-100000>