[lkml]   [2001]   [Aug]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] let Net Devices feed Entropy, updated (1/2)

(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
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:57    [W:0.081 / U:0.780 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site