[lkml]   [2001]   [Aug]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
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
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:57    [W:0.092 / U:0.172 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site