Messages in this thread |  | | Date | Mon, 20 May 1996 20:47:25 +0100 | From | "Stephen C. Tweedie" <> | Subject | Re: CONFIG_RANDOM (compromise?) |
| |
Hi,
On Sun, 19 May 1996 08:32:17 -0500 (CDT), lilo <TaRDiS@mail.utexas.edu> said:
> On Fri, 17 May 1996, Harald Anlauf wrote: >> Still, I maintain that DEK's generator is superior to what most people >> use. For non-networked machines, where security is not first priority, >> a clearly leaner and (I think) acceptable solution.
> As long as these devices don't have the same minor numbers. Programs which > are indiscriminate enough not to check the device before using it can then > settle for whatever they get. Programs which consider the quality and > derivation of the number sequences important can check, and they'll know you > are providing a lame generator which they presumably will then want to avoid > using....
This still misses the point. /dev/random has only one reason for being --- to provide a clean interface to a really dirty operation: the gathering of system-wide entropy into a random bit pool.
If you don't need this, then *you shouldn't be doing the random generation in kernel space*!! There are dozens of pseudo-random number generators out there, and many of them are good enough for just about any application where unpredictability is required. In these cases, it is perfectly adequate to generate the random sequence in user code.
The only reason why /dev/random is needed is that to get true unpredictability, we need to make observations of genuinely unpredictable behaviour, and the kernel is much much better placed to make these observations than user code is.
Programs which don't need this true unpredictability shouldn't be using /dev/random at all --- the overhead involved is too great for applications where the entropy isn't needed. There's no point in replacing it with a weaker /dev/random in this case; we shouldn't be using the kernel at all.
Only programs which genuinely require true unpredictability need to use /dev/random, and for these applications a weak substitute is not an option.
Cheers, Stephen. -- Stephen Tweedie <sct@dcs.ed.ac.uk> Department of Computer Science, Edinburgh University, Scotland.
|  |