Re: [PATCH] let Net Devices feed Entropy, updated (1/2)

From: Martin Dalecki (dalecki@evision-ventures.com)
Date: Mon Aug 20 2001 - 05:02:03 EST


Robert Love wrote:
>
> On 18 Aug 2001 22:36:00 -0500, Oliver Xymoron wrote:
> > But your claim is there _is_ entropy. If you think there is, go ahead and
> > use it. Via /dev/urandom. Yes, I know it's theoretically not secure, but
> > then neither is what you're proposing.
>
> I am only continuing this because I want to explain...
>
> I claim there is entropy from what? The difference between interrupts
> for net devices? Everyone agrees that there is. The issues is that an
> external attacker could influence the interrupts to the net device, and
> thus make some assumptions about the state. That is why this patch is
> configurable. Do as you please. As I said, some people want it or need
> it.

I think you are just wrong - nobody really needs this patch. /dev/random
or /dev/urandom ar *both* anyway just complete overkill in terms of
practical security. /dev/urandom is in esp silly, since it is providing
a md5 hash
implementation inside the kernel, which could be *compleatly* and
entierly
done inside user land.

> Again, /dev/urandom is just as "secure" as /dev/random. Its the same
> pool. The same stuff. Except that /dev/random blocks when the entropy
> count hits 0.
>
> Now, this count is purely theoretical, too. Its an estime of the amount
> of entropy -- lack of determinability -- in the pool of bytes.

Wrong. Don't let you confuse yourself by the way the term entropy is
used in
the documentation of /dev/random - it's an abuse of the mathematical
definition anyway. The more appriopriate term there
would be: signal source variability estimate.

> Even when it reaches 0, since the pool is still unknown (only previous
> output may be known) and the output is hashed, its still pretty much
> undeterminable. But mathematically and theoretically, our entropy
> estimate says it is not.

You mean - there is no known algorithm with polynomial time
behaviour enabling us to calculate the next value of this function
from the previous ones - Not more nor less - no pysics and
entropy involved. If you assume this holds true it's mathematically
entierly sufficient that a single only seed value is not known.
-
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:34 EST