[lkml]   [2001]   [Aug]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: /dev/random in 2.4.6
>> Am I correct in assuming that in the absence of other entropy sources, it
>> would use these (potentially inferior) sources, and /dev/random would
>> then not block? In which case fine, it solves my problem.
> No, /dev/random would always keep a conservative estimate of entropy.
> Assuming that network entropy > 0, this would add more real (but
> unaccounted) entropy to the pool, and if you agree with this assumption,
> you would be able to take advantage of it by reading /dev/urandom.

OK; well in which case it doesn't solve the problem. I assert there are
configurations where using the network to generate accounted for entropy
is no worse than the other available options. In that case, if my entropy
pool is low, I want to wait long enough for it to fill up (i.e. have the
/dev/random blocking behaviour) before reading my random number. If your
interpretation of Ted's suggestion is correct, this is no better than
switching to /dev/urandom, which is considerably worse than the effect
of using Robert's patch. I thought what Ted was suggesting was only
accounting for network-IRQ derived entropy when the entropy pool was
mostly empty. This would mean that if there were other sources of entropy
about, the network entropy would not be accounted for (which sounds
reasonable, on the presumption that they were better quality).

An alternative approach to all of this, perhaps, would be to use extremely
finely grained timers (if they exist), in which case more bits of entropy
could perhaps be derived per sample, and perhaps sample them on
more operations. I don't know what the finest resolution timer we have
is, but I'd have thought people would be happier using ANY existing
mechanism (including network IRQs) if the timer resolution was (say)
1 nanosecond.

Alex Bligh
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.460 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site