[lkml]   [2006]   [May]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: /dev/random on Linux
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:
> >
> >
> > (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
> More majordomo info at
> Please read the FAQ at
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: 2006-05-16 04:52    [W:0.052 / U:0.676 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site