Oliver,
> Ok, you're going to assume that the 160-bit SHA hash with lots and lots
> and lots of mixing is more vulnerable than the IDEA or Blowfish or 3DES
> that you're using for your actual encryption?
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.
> How about simply adding possible entropy from the network but not
> accounting for it? /dev/urandom then becomes as strong as the proposed
> /dev/random (up to the load that /dev/random would allow), while
> /dev/random isn't weakened.
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.
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.
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).
>> Correct, and it's quite possible it should be contributing less bits
>> than 12 if the option is turned on. However, a better response would
>> be to fix the timers to be more accurate :-)
>
> We're already using cycle counters - do you propose being more accurate
> than that?
I propose not using Jiffies on machines other than some i386's, and
not exposing /proc/interrupts 644 which reduces the attack space
hugely.
>> I agree with your point that Robert's patch /could/ taint /dev/random,
>> but only if you switch it on!
>
> As it stands, it does. Assuming a 1GHz processor and hitting the maximum
> 12 bits of entropy per interrupt, we only need to guess the interrupt
> timing to within 4us - probably not hard. As I've pointed out, it's not
> hard to send our own apparently random packets to open up that window.
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).
-- Alex Bligh - 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:45 EST