On Sun, 23 Jan 2000, sottek wrote:
[snip 810 RNG]
> Solutions:
> #1 Make random.c export a function to the kernel that takes in raw
> random data and adds it to the entropy pool without doing any work on
> it. This is a trust issue, we have to assume that people in the kernel
> have better ways to mess with the machine than adding non-random data
> to the pool. If this existed the device file would go away and the
> rng.o module would just call add_random_byte() once per jiffie, no-one
> would even know it was running.
[snip]
Heres my take on the Ideal Solution(tm):
You mix random data from the 810RNG into the random pool on a periodic
basis (not once per jiffy!!! The 810RNG may take little CPU to pull from
but the /dev/random stiring function does not!) I believe you should be
able to use the existing interface which is used for mixing in random info
from interupts, keyboard, etc.
It doesn't matter here that the 810rng might not be random, because you
can mix non-random data into the pool and the pool is still as random as
when you begun.
You make /dev/urandom pull random data from the pool:
A) When the pool random estimate runs out or reaches a watermark;
then you pull from the 810rng.
OR
B) If you pull faster then a certian rate it switches to the
810rng.
OR
C) It randomly picks bits from one or the other, the ratio depends on how
fast you are pulling.
This behavior would be diabaleable from a syscall or ioctl.
Get rid of the randomness test: It doesn't matter when stiring into
/dev/random. And if people need critical random data is userspace they
should not use /dev/urandom or should disable the urandom 810rng use via a
syscall.
This system makes the most sence to me.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jan 31 2000 - 21:00:12 EST