lkml.org 
[lkml]   [2001]   [Aug]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: /dev/random in 2.4.6
On Mon, 20 Aug 2001, Helge Hafting wrote:

> Oliver Xymoron wrote:
> >
> > Can I propose an add_untrusted_randomness()? This would work identically
> > to add_timer_randomness but would pass batch_entropy_store() 0 as the
> > entropy estimate. The store would then be made to drop 0-entropy elements
> > on the floor if the queue was more than, say, half full. This would let us
> > take advantage of 'potential' entropy sources like network interrupts and
> > strengthen /dev/urandom without weakening /dev/random.
>
> It seems to me that it'd be better with an
> add_interrupt_timing_randomness() function.
>
> This one should modify the entropy pool, and add no more to the
> entropy count than the internal interrupt timing allow,
> i.e. assume that "the ouside" observed the event that
> trigged the interrupt. How much is architecture dependent:
>
> A machine with a clock-counter, like a pentium, can add
> a number of bits from the counter, as the timing is
> documented variable. (There could be several interrupts
> queued up, the interrupt stacks and routines
> may or may not be in level-1 cache) Even a conservative approach
> assuming a lot of worst cases would end up adding _some_.

Until you've spent a while trying to mount a serious timing attack, I
think any arguments as to how much entropy is there are just a bunch of
handwaving. Interrupt generation on an otherwise quiescent machine is
extremely deterministic.

--
"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 12:57    [from the cache]
©2003-2011 Jasper Spaans