> 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....
If you're going to be using a pseudo-random number generator, then it
doesn't belong in the kernel at all. There's no advantage to having
there; let it be a user-mode library routine. (See who's complaining
about kernel bloat now?)
The whole reason for putting a /dev/random driver into the kernel was
because it had access to low-level timing information which you couldn't
efficiently obtain from a user-mode program. If you remove the use of
such low-level timing information, why bother putting a random number
generator into the kernel?
The only reason to put a pseudo-random number generator and give it the
name /dev/random (even if you use different minor numbers), will be to
try to trap programs who aren't careful to make sure that /dev/random is
the real (tm) /dev/random, and try to trick them into using a completely
insecure random number generator.
If you want to go and edit your own kernel sources to remove
/dev/random, you can do so. But putting in an insecure /dev/random
driver into the kernel is just stupid. It doesn't make sense from a
security perspective, and it doesn't make sense if you're really worried
about kernel bloat and use of precious non-swappable kernel memory.
- Ted