lkml.org 
[lkml]   [2002]   [Aug]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
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 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: 2005-03-22 13:28    [from the cache]
©2003-2011 Jasper Spaans