Alex Bligh - linux-kernel wrote:
>If we assume SHA-1 was
>not breakable, then /dev/urandom in a ZERO ENTROPY environment would
>give the the same value on a reboot of your machine as a simultaneous
>reboot of a hacker's machine. /dev/random would block (indefinitely)
>under these conditions. So /dev/urandom and /dev/random are
>both dysfunctional in this circumstance (one spits out a predictable
>number, one blocks), but differently dysfunctional, and
>/dev/random's behaviour is better.
Yup. Fortunately, the countermeasure is simple: Your init script
should contain something like
dd count=16 ibs=1 if=/dev/random of=/dev/urandom
This fixes the problem. So this is arguably a user-level issue, not
a kernel issue.
>Similarly, if entropy disappears later on, then using /dev/urandom
>eventually provides you with information about the state of the pool,
>though as the pool is SHA-1 hashed, it's a difficult attack to exploit.
No, it's not just difficult, it is completely infeasible under
current knowledge.
>So let's use Occam's razor and assume the attacker could have an SHA-1
>exploit,
No, let's not. If the attacker has a SHA-1 exploit, then all your
SSL and IPSEC and other implementations are insecure, and they are
probably the only reason you're using /dev/random anyway.
Instead, let's assume SHA-1 is good, since it probably is, and since
you have to assume this anyway for the rest of your system.
-
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:44 EST