Messages in this thread |  | | | Date | Tue, 8 Aug 2000 14:32:59 -0400 | | From | "Theodore Y. Ts'o" <> | | Subject | Re: /dev/random blocks forever on 2.2.12 and 2.2.16 |
| |
Date: Tue, 8 Aug 2000 20:15:40 +0200 From: "Andi Kleen" <ak@suse.de>
> I'm not sure what you mean about using a secure PRNG to select the > interrupts to get data from; there's a bootstrapping issue here, and You would need a master key. Still better than no random numbers on a diskless server.
True; but it's also no better than just using /dev/urandom...... > even if you do use a PRNG to select whether or not a particular entropy > is sampled, that decision only contributes one bit of entropy into the > pool..... One bit ? I was assuming you always put in in the time difference between interrupts, which is surely a lot more than one bit (when it is there or not) Alternatively you could just run a Stream cipher over the input, but I guess that requires too much trust for the outgoing hash (just like the prng)
The "one extra bit of entropy" is the question of "do we mix this input into the stream or not?" If the adversary knows the input (by watching the ethernet, for example, so he can figure out when the ethernet interrupts will be) with 100% accuracy, the choice of whether or not to include the interrupt adds one bit of uncertainty ("yes or no") which is taken from the PRNG.
I misunderstood you that to you meant use the PRNG to decide at boot time whether or not to include that irq channel for all time. I gather that what you meant was to use the PRNG on a per interrupt basis whether or not to include it. This, as I said, only adds one bit of uncertainty from the PRNG. Given that in the absence of any random input, /dev/urandom eventually degrades into a PRNG, it's not *substantially* better, but it does provide some protection.
- Ted
- 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/
|  |