[lkml]   [2001]   [Aug]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: /dev/random in 2.4.6
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

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
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:57    [W:0.094 / U:1.072 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site