lkml.org 
[lkml]   [2006]   [May]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: /dev/random on Linux
    From
    Date
    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.]

    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, and think the
    person found in a file called MAINTAINERS is in fact a "moderator"
    doesn't initial inspire confidence. 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@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2006-05-16 00:30    [W:3.170 / U:0.228 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site