[lkml]   [2002]   [Aug]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Problem with random.c and PPC
    On Fri, Aug 16, 2002 at 11:00:00AM +0100, Jon Burgess wrote:
    > >BTW, does anyone know where I can found the patch to get randomness from the
    > >network cards interrupt ?
    > Add the flag SA_SAMPLE_RANDOM into the request_irq() flags in the driver for
    > whichever interrupt source you want to use
    > e.g. from drivers/net/3c523.c
    > ret = request_irq(dev->irq, &elmc_interrupt, SA_SHIRQ | SA_SAMPLE_RANDOM,
    > dev->name, dev);

    Don't do this. This is the Enron method of entropy accounting.

    There is little to no reliably unpredictable data in network
    interrupts and the current scheme does not include for the mixing of
    untrusted sources. It's very likely that an attacker can measure,
    model, and control such timings down to the resolution of the PCI bus
    clock on a quiescent system. This is more than good enough to defeat
    entropy generation on systems without a TSC and given that the bus
    clock is a multiple of the processor clock, it's likely possible to
    extend this to TSC-based systems as well.

    Entropy accounting is very fickle - if you overestimate _at all_, your
    secret state becomes theoretically predictable. I have some patches
    that create an API for adding such hard to predict but potentially
    observable data to the entropy pool without accounting it as actual
    entropy, as well as cleaning up some other major accounting errors but
    I'm not quite done testing them.

    "Love the dolphins," she advised him. "Write by W.A.S.T.E.."
    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 13:28    [W:0.023 / U:32.932 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site