Messages in this thread |  | | From | Paul Gortmaker <> | Subject | Re: CONFIG_RANDOM (compromise?) | Date | Sat, 25 May 1996 03:29:13 +1000 (EST) |
| |
- From Stephen C. Tweedie (sct@dcs.ed.ac.uk) Mon, 20 May 1996 20:47:25 +0100
> 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.
I agree with the above completely. And I feel the need to reiterate that I did *NOT* propose a "weak" /dev/random in my patch that started this horrible thread, since I assumed that it was obvious to all that: (a) a weak random number generator would be a security problem, and (b) a weak random number generator can be done in user-space.
I just took the next logical step based on your first sentence above: "If I don't use any programs that use the /dev/random device, then I do not need to compile in the random driver."
which is not all that different from saying: "If I don't use any programs that use the /dev/audio device, then I do not need to compile in the sound driver."
Until /dev/random is as common as /dev/null, any application that doesn't check the return from an open() for ENODEV is simply broken.
[[ Others: *please* no more vain followups regarding gravity waves, predictions of the future, and other useless cruft... ]]
Paul.
|  |