Re: /dev/random on Linux

[Muli Ben-Yehuda]

On Mon, May 15, 2006 at 11:41:07PM +0100, Alan Cox wrote:
> On Llu, 2006-05-15 at 14:39 -0700, Jonathan Day wrote:
> > http://www.securiteam.com/unixfocus/5RP0E0AIKK.html
> > 
> > (Just because something is claimed does not make it
> > so, but it's usually worth checking.)
> 
> "Holes in the Linux Random Number Generator"
> 
> [I would cc the authors but they seem to have forgotten to include their
> email addresses. I've cc'd the IEEE instead, especially as the paper
> gets a trademark incorrect and that wants fixing before printing.]

Zvi Gutterman CC'd.

> Indeed. 
> 
> A paper by people who can't work out how to mail linux-kernel or
> vendor-sec, or follow "REPORTING-BUGS" in the source,

Zvi did contact Matt Mackall, the current /dev/random maintainer, and
was very keen on discussing the paper with him. I don't think he got
any response.

> and think the
> person found in a file called MAINTAINERS is in fact a "moderator"
> doesn't initial inspire confidence.

I wouldn't read much (or anything) into that thinko.

[not trimming the rest for Zvi's benefit]

> The also got the "Red Hat" name
> wrong. It is "Red Hat" and it is a registered trademark.
> 
> Certainly there are lot of errors in the background but then their
> expertise appears to be random numbers and that part of the material
> looks much more solid.
> 
> > I know there have been patches around for ages to
> > improve the entropy of the random number generator,
> > but how active is work on this section of the code?
> 
> Going through the claims
> 
> I would dismiss 2.2 for the cases of things like Knoppix because CDs
> introduce significant randomness because each time you boot the CD is
> subtly differently positioned. The OpenWRT case seems more credible. The
> hard disk patching one is basically irrelevant, at that point you
> already own the box and its game over since you can just do a
> virtualisation attack or patch the OS to record anything you want.
> 
> 2.3 Collecting Entropy
> 
> Appears to misdescribe the behaviour of get_random_bytes. The authors
> description is incorrect. The case where cycle times are not available
> is processors lacking TSC support (pre pentium). This is of course more
> relevant for some embedded platforms which do lack cycle times and thus
> show the behaviour described. There are some platforms that therefore
> show the properties they are commenting on so it is still a relevant
> discussion in those cases.
> 
> 3.4 Security Engineering
> 
> The denial of service when no true entropy exists is intentional and
> long discussed. User consumption of entropy can be controlled by
> conventional file permissions, acls and SELinux already, or by a policy
> daemon or combinations thereof. It is clearly better to refuse to give
> out entropy to people than to give false entropy.
> 
> Unix/Linux philosophy is "policy belongs outside the kernel", therefore
> a daemon is the correct implementation if required. The paper perhaps
> makes an interesting case for this.
> 
> 
> Generally
> 
> The random number mathematics involved is not for me to comment on,
> several of the points raised are certainly good, and I will forward the
> paper URL on to vendor-sec to ensure other relevant folk see it.
> 
> Thanks for forwarding it.
> 
> Alan
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/