Messages in this thread | | | Date | Mon, 20 Aug 2001 09:01:36 -0500 (CDT) | From | Oliver Xymoron <> | Subject | Re: /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/
| |