Martin Dalecki writes:
> 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.
This is inconsistent with your earlier comment "for anything else
crypto related it just doesn't cut the corner". So are you retracting
that statement?
> 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.
I'm fairly confident that a user on the system can't tamper with my
mouse movements and keyboard presses. As for other interrupt sources
(such as network, disc and so on) which may be vulnerable to
"tampering" (i.e. injection or monitoring of timing data), that's why
we have the concept of "entropy". Think of it as a measure of trust.
> 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.
This is a completely flawed argument. The more entropy inputs there
are, the harder it is for an attacker to predict or control all of
them.
> Multiple initializations help only against cryptographic attacks -
> but THEY HURT overall security of the system, becouse they "open it
> up".
This doesn't make sense. If, as you say, something is better against
cryptographic attacks, then the overall security of the system is
better. A trivially obvious example is TCP.
> So this is indeed a serious FLAW inside the logics behind the
> implementation of this device.
The flaw is in your argument, which isn't logical, and uses
hand-waving in place of coherent step-by-step analysis of how
/dev/random is somehow harmful to security. Use of a few choice words
in uppercase isn't convincing. Furthermore, you talk about a risk to
system security, but you don't even clearly define what you mean be
that.
Regards,
Richard....
Permanent: rgooch@atnf.csiro.au
Current: rgooch@ras.ucalgary.ca
-
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/
This archive was generated by hypermail 2b29 : Thu Aug 23 2001 - 21:00:43 EST