> 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.