lkml.org 
[lkml]   [1996]   [May]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: CONFIG_RANDOM (compromise?)
Date
- 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.


\
 
 \ /
  Last update: 2005-03-22 13:37    [W:0.021 / U:2.072 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site