5

Doing fuser -v /dev/urandom tells me which processes currently have /dev/urandom open, but only that. Is there any was to determine anything about how much entropy each one is using up over time? For instance, it might be that one process is using up about 1 bit of entropy every minute, while a different one is using up about 8 bits per second; I'd like some way of determining that.

  • /dev/urandom is not really an entropy source, it is a PRNG reusing what is fed into /dev/random - estimating its entropy is questionable at best. – peterph Oct 9 '13 at 7:48
5

The short answer is 0, because entropy is not consumed.

There is a common misconception that entropy is consumed — that each time you read a random bit, this removes some entropy from the random source. This is wrong. You do not “consume” entropy. Yes, the Linux documentation gets it wrong.

During the life cycle of a Linux system, there are two stages:

  1. Initially, there is not enough entropy. /dev/random will block until it thinks it has amassed enough entropy; /dev/urandom happily provides low-entropy data.
  2. After a while, enough entropy is present in the random generator pool. /dev/random assigns a bogus rate of “entropy leek” and blocks now and then; /dev/urandom happily provides crypto-quality random data.

FreeBSD gets it right: on FreeBSD, /dev/random (or /dev/urandom, which is the same thing) blocks if it doesn't have enough entropy, and once it does, it keeps spewing out random data. On Linux, neither /dev/random nor /dev/urandom is the useful thing.

In practice, use /dev/urandom, and make sure when you provision your system that the entropy pool is fed (from disk, network and mouse activity, from a hardware source, from an external machine, …).

While you could try to read how many bytes get read from /dev/urandom, this is completely pointless. Reading from /dev/urandom does not deplete the entropy pool. Each consumer uses up 0 bits of entropy per any unit of time you care to name.

  • 5
    Although the answer is correct, it sort of misses the point I believe. The kernel does have an estimate on the amount of entropy available (readable from /proc/sys/kernel/random/entropy_avail) - and although it is not a reasonable practice, reading from /dev/urandom consumes it and makes processes reading from /dev/random block. So it is a perfectly reasonable thing to attempt to account which processes read /dev/urandom and how much, even if it does not make cryptographic sense. – Nakedible Apr 17 '14 at 10:50
  • See 2uo.de/myths-about-urandom for details on why this answer is correct and which entropy is not quite the problem people think it is. – Walter Nov 17 '16 at 1:53
1

While not automated, you could use a tool like strace to watch for reads from the file descriptor(s) related to urandom. Then see how much data is read over a specific time period to get the read rate.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.