12

I have found information that /proc/sys/kernel/random/entropy_avail indicates number of bits available in /dev/random. I wanted to check whether the next reading from /dev/random will block and my naive approach was just to compare entropy_avail and number of required random bits but it does not work well. When I did a simple stupid experiment I realized that the entropy is buffered. 64-bit entropy buffer provides 6 bytes of random data.

I monitored the entropy_avail via this simple command:

while true; do
    cat /proc/sys/kernel/random/entropy_avail
    sleep 1
done

And I was trying to get a random byte via command

dd if=/dev/random bs=1 count=1 > /dev/null

The dd command is blocked if entropy is 63 or lower. When entropy reaches 64 and I read a byte then entropy decreases to 0 but I can read another 5 bytes without blocking. Then dd blocks again till entropy reaches 64.

What is the exact meaning of the entropy_avail and how can I detect real number of available random bits?

4

1 Answer 1

16

entropy_avail does not indicate the number of bits available in /dev/random. It indicates the kernel's entropy estimate in the RNG state that powers /dev/random. That entropy estimate is a pretty meaningless quantity, mathematically speaking; but Linux blocks /dev/random if the entropy estimate is too low.

A program reading from /dev/random blocks until the value in /proc/sys/kernel/random/entropy_avail becomes larger than /proc/sys/kernel/random/read_wakeup_threshold. Reading from /dev/random consumes entropy at the rate of 8 bits per byte.

But anyway you shouldn't be using /dev/random. You should be using /dev/urandom, which is just as secure, including for generating cryptographic keys, and which doesn't block. Generating random numbers does not consume entropy: once the system has enough entropy, it's good for the lifetime of the universe. The OS saves an RNG seed to a file, so once the system has had enough entropy once, it has enough entropy even after a reboot.

The only cases where /dev/urandom is not safe are on a freshly-installed system booting for the first time, on a live system which has just booted (so generating cryptographic keys from a live system is not a good idea!), or on a freshly-booted embedded device that doesn't have either a hardware RNG or persistent memory. On such systems, wait until /dev/random agrees to let out 16 bytes to make sure the entropy pool is built up. Then use /dev/urandom.

4
  • > "On such systems, wait until /dev/random agrees to let out 16 bytes to make sure the entropy pool is built up." How is this best done? Wait until entropy_avail > 128?
    – Pod
    Commented Jan 4, 2017 at 10:48
  • 1
    @Pod That works. Alternatively, on a system level, have one boot-time service read enough entropy (say 16 bytes, or a bit more to be on the safe side) from /dev/random, using blocking read calls. At that time the entropy pool is known to be seeded and you can use /dev/urandom safely. Commented Jan 4, 2017 at 12:46
  • "That entropy estimate is a pretty meaningless quantity, mathematically speaking..." Can you explain why this estimate would be "meaningless"? This estimate doesn't seem to be similar to the bogomips situation.
    – code_dredd
    Commented Oct 15, 2018 at 22:38
  • 1
    @code_dredd In a nutshell, the entropy estimate is based on the assumption that entropy runs out: if you've consumed one bit of randomness, you don't have it anymore. But this is only true if you assume that the cryptography used to generate the output of /dev/{u,}random from the entropy sources is completely broken. If you assume that then what you're doing with that entropy is probably also completely broken anyway. If you want the details, read 2uo.de/myths-about-urandom Commented Oct 16, 2018 at 21:00

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .