Messages in this thread |  | | From | (David Wagner) | Subject | Re: [PATCH][RFC] Allow net devices to contribute to /dev/random | Date | 26 Sep 2001 00:20:32 GMT |
| |
I'm worried about the language in the configuration documentation: + Some people, however, feel that network devices should not contribute to + /dev/random because an external attacker could observe incoming packets + in an attempt to learn the entropy pool's state. Note this is completely + theoretical. Incrementing the entropy counter based on externally observable values is dangerous. Calling this risk 'completely theoretical' is, I believe, a misrepresentation, unless I've missed something.
A failed RNG is one of the most likely -- and most devastating -- failure modes possible for modern cryptosystems, and as such it pays to be careful here. Are you proposing this for inclusion in the mainline Linux kernel? If so, I'm concerned that this patch could put security at risk. What am I missing?
Here is my reasoning. I'd like to quote drivers/char/random.c: * add_interrupt_randomness() uses the inter-interrupt timing as random * inputs to the entropy pool. Note that not all interrupts are good * sources of randomness! For example, the timer interrupts is not a * good choice, because the periodicity of the interrupts is too * regular, and hence predictable to an attacker. Disk interrupts are * a better measure, since the timing of the disk interrupts are more * unpredictable. * * All of these routines try to estimate how many bits of randomness a * particular randomness source. They do this by keeping track of the * first and second order deltas of the event timings. This suggests that add_interrupt_randomness() should not be called on all interrupts without discrimination. Would it be fair to say that your patch enables randomness collection on almost all interrupts? If so, why is this safe to do?
I hope you agree that making this configurable does not obviate our responsibility to make sure that the default configuration is reasonable. This stuff is subtle, and changing it is not something I'd recommend without a careful analysis of the impact on security. Moreover, the comments about 'completely theoretical' leave me concerned that any analysis that has been done on this patch may be based on misconceptions about cryptographic security. Can you tell us anything about what security analysis you've done so far? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |