Messages in this thread | | | Date | Tue, 21 Aug 2001 11:43:10 +0200 | From | Martin Dalecki <> | Subject | Re: [PATCH] let Net Devices feed Entropy, updated (1/2) |
| |
Richard Gooch wrote: > > Theodore Tso writes: > > On Mon, Aug 20, 2001 at 04:25:26PM +0200, Martin Dalecki wrote: > > > > > > The primary reson of invention of /dev/random was the need > > > for a bit of salt to the initial packet sequence number inside > > > the networking code in linux. And for this purspose the > > > whole /dev/*random stuff is INDEED a gratitious overdesign. > > > For anything else crypto related it just doesn't cut the corner. > > > > A number of other people helped me with the design and development of > > the /dev/random driver, including one of the primary authors of the > > random number generation routines in PGP 2.x and 5.0. Most folks feel > > that it does a good job. > > Indeed. If Martin has some deep insight as to why the /dev/random > implementation is insufficient for strong crypto, I'd like to hear > it.
I don't think that it's unsufficient. In fact I think that it just doesn't have to be done all inside the kernel. And I oppose further extending the places where the event gathering code goes in between.
BTW> There is one strong flaw in the resoning behing this whole entropy stuff.
Iff you trust the cryptographic algorithm for the one way function you are using then if you initialize it once - there will be only one chance for an attacker to tamper with the values. The possibility for tampering with it will have a certain value, which remains CONSTANT over the time. You could call it: breaking risk as well.
If you continuously reinitialize your one way function, the propabilitie to tamper with them will ADD (of course not in pure arithmetic terms). An attacer simply get's multiple chances. And therefore the overall propability of tampering with the values delivered to the user by this device WILL INCREASE.
Multiple initializations help only against cryptographic attacks - but THEY HURT overall security of the system, becouse they "open it up".
So this is indeed a serious FLAW inside the logics behind the implementation of this device. - 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/
| |