Re: Why does reading from /dev/urandom deplete entropy so much?

From: Eric Dumazet
Date: Thu Dec 06 2007 - 02:03:33 EST


Matt Mackall a écrit :
On Tue, Dec 04, 2007 at 07:17:58PM +0100, Eric Dumazet wrote:
Alan Cox a ?crit :
No matter what you consider as being better, changing a 12 years old and widely used userspace interface like /dev/urandom is simply not an option.
Fixing it to be more efficient in its use of entropy and also fixing the
fact its not actually a good random number source would be worth looking
at however.
Yes, since current behavior on network irq is very pessimistic.

No, it's very optimistic. The network should not be trusted.

You keep saying that. I am refering to your previous attempts last year to remove net drivers from sources of entropy. No real changes were done.

If the network should not be trusted, then a patch should make sure network interrupts feed /dev/urandom but not /dev/random at all. (ie not calling credit_entropy_store() at all)


The distinction between /dev/random and /dev/urandom boils down to one
word: paranoia. If you are not paranoid enough to mistrust your
network, then /dev/random IS NOT FOR YOU. Use /dev/urandom. Do not
send patches to make /dev/random less paranoid, kthxbye.

I have many tg3 adapters on my servers, receiving thousand of interrupts per second, and calling add_timer_randomness(). I would like to either :

- Make sure this stuff is doing usefull job.
- Make improvements to reduce cpu time used.

I do not use /dev/urandom or/and /dev/random, but I know David wont accept a patch to remove IRQF_SAMPLE_RANDOM from tg3.c

Currently, I see that current implementation is suboptimal because it calls credit_entropy_store( nbits=0) forever.


If you have some trafic, (ie more than HZ/2 interrupts per second), then add_timer_randomness() feeds
some entropy but gives no credit (calling credit_entropy_store() with nbits=0)

This is because we take into account only the jiffies difference, and not the get_cycles() that should give
us more entropy on most plaforms.

If we cannot measure a difference, we should nonetheless assume there
is one?

There is a big difference on get_cycles() and jiffies. You should try to measure it on a typical x86_64 platform.

In this patch, I suggest that we feed only one u32 word of entropy, combination of the previous distinct
words (with some of them being constant or so), so that the nbits estimation is less pessimistic, but also to
avoid injecting false entropy.

Umm.. no, that's not how it works at all.

Also, for future reference, patches for /dev/random go through me, not
through Dave.


Why ? David is the network maintainer, and he was the one who rejected your previous patches.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/