Mike,
(off list - as I've posted this elsewhere)
>> This is not the issue; some of use _are_ worried whether or not we
>> have enough entropy (and want a read that blocks until sufficient
>
> If you are that worried, shouldn't you be using a hardware generator?
You could say the same thing to anyone who uses /dev/random
rather than /dev/urandom. Why use /dev/random when it can
block (inconvenient) instead of a h/w random number generator?
I'm sufficiently concerned that I want to have some 'external'
entropy, and on the machine in which it is causing me problems,
in an idle state, there is no other entropy source, but lots of
network activity which I trust can't be snooped on.
The machine was bought and tested in one config. A hardware
random number generator is something else to go wrong, and
additional expense.
Using an entropy estimate which includes network event timings
is no[1] worse (in this situation) than using (say) IDE interrupt
timings. And no better. It certainly isn't as good as using
an external random number generator. However, it is better
than using /dev/urandom and leaving the kernel unpatched
(see previous analysis). It's a trade-off. But if we can make
(depending on circumstance) the OS (s/w) perform better
with given h/w, that sounds like a good thing to do to me.
[1]=certainly not a lot worse.
-- Alex Bligh - 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/
This archive was generated by hypermail 2b29 : Thu Aug 23 2001 - 21:00:32 EST