Re: /dev/random in 2.4.6

[daw@mozart.cs.berkeley.edu (David Wagner)]

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.