[lkml]   [2001]   [Aug]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: /dev/random in 2.4.6
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.

(Yes, I see dont_count_entropy, but it doesn't appear to be used, and
doesn't address flooding the queue with 0-entropy entries. I'd take it

"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.101 / U:1.172 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site