Re: /dev/random in 2.4.6

[Robert Love <rml@tech9.net>]

On Tue, 2001-08-21 at 15:20, Alex Bligh - linux-kernel wrote:
> Only because if not, this argument is irrelevant, in that if SHA-1
> is not broken and can never be, then there is no point in the entropy
> measurement and blocking behaviour at all, and in this case, Robert's
> patch does no harm whatsoever.
>
> Perhaps I'm missing something, but /dev/urandom is only weaker than
> /dev/random NOW if SHA-1 is cracked (if not, the two are identical
> in 'strength'). And, in the extremely theoretical case that
> SHA-1 is crackable (perhaps with an attack that takes many days),
> then wanting to have gathered entropy before reading is useful.

I believe this is all correct.  If the one-way hash is uncrackable, then
we are never giving any clue to the state of the pool out, thus the
entropy estimate means nothing (entropy would never drop on read from
/dev/[u]random).

Thus, as you have pointed out, we have two situations:

One, SHA-1 is unbreakable: my patch does no harm, and (beneficently)
feeds the random pool with bits.

Two, SHA-1 is breakable: the patch, if _enabled_ and iff the entropy
estimate is too large (agreeable entirely possible) will weaken the
entropy estimate.  that is why you need to judge the situation.

> As you point out (above), and as did David, SHA-1 being cracked
> is a remote possibility in the extreme. But this scenario is the
> only one where Robert's patch could make a conceivable difference.
> If SHA-1 is invulnerable, then why argue against Robert's patch
> which merely stops some applications from not working on some machines.

True.  And, if we worry about SHA-1 being cracked, and network
interrupts having some air of predictability, then we might as well
worry up other interrupts causing an overestimate of entropy.

Its all a gamble.  Its all a theoretical estimate.

> But people obviously do have concerns about the reversibility of SHA-1,
> even if only at a very theoretical level, or they wouldn't be
> spending all this time arguing about the importance of metering entropy.
> 
> Adding entropy from the network and not accounting for it is probably
> better than nothing (as it makes the seeding problem better).
> 
> I propose not using Jiffies on machines other than some i386's, and
> not exposing /proc/interrupts 644 which reduces the attack space
> hugely.

agreed.

> IF you can observe packets, and IF you turn the config option
> on against advice [1] THEN the strength of /dev/random
> will be tainted IF and ONLY IF SHA-1 is breakable (in which
> case, as you point out, all sorts of other things break anyway).
> I consider this an acceptable risk.
> 
> [1] against the advice of a config option which should read
> 'DO NOT SWITCH THIS ON IF YOU BELIEVE THERE IS ANY CHANCE OF
> YOUR NETWORK PACKETS BEING OBSERVABLE AND YOU ARE WORRIED
> ABOUT THE SECURITY OF SHA-1' (but the same applies btw using k/b
> interrupts with wireless keyboards).

I will add this wording to the Configure.help of the next patch release.

-- 
Robert M. Love
rml at ufl.edu
rml at tech9.net