Re: /dev/random in 2.4.6

[Helge Hafting <helgehaf@idb.hist.no>]

Oliver Xymoron wrote:
> 
> On Sun, 19 Aug 2001, Theodore Tso wrote:
> 
> > The bottom line is it really depends on how paranoid you want to be,
> > and how much and how closely you want /dev/random to reliably replace
> > a true hardware random number generator which relies on some physical
> > process (by measuring quantum noise using a noise diode, or by
> > measuring radioactive decay).  For most purposes, and against most
> > adversaries, it's probably acceptable to depend on network interrupts,
> > even if the entropy estimator may be overestimating things.
> 
> 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_.

A 386 may have to add 0to the count, as it don't have a high-speed
timer.
People who have a network-only machine can go for
something better than 386 though.

Helge Hafting