[lkml]   [2001]   [Aug]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [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
have to be done all inside the kernel. And I oppose further extending
places where the event gathering code goes in between.

BTW> There is one strong flaw in the resoning behing this whole entropy

Iff you trust the cryptographic algorithm for the one way function you
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
the time. You could call it: breaking risk as well.

If you continuously reinitialize your one way function, the propabilitie
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
with the values delivered to the user by this device WILL INCREASE.

Multiple initializations help only against cryptographic attacks - but
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
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:57    [W:0.092 / U:0.108 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site