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/
This archive was generated by hypermail 2b29 : Thu Aug 23 2001 - 21:00:35 EST