Entropy is a technical term for "Randomness". Computers don't really
generate entropy but gather it by looking at stuff like the variations of
hard drive rotation speeds (A physical phenomena that is very hard to predict due to friction etc.) When a computer wants to generate a pseudo random data it will seed a mathmatical formula with true entropy that it found by measuring mouseclicks, hard drive spin variations etc. Roughly speaking entropy_avail
is the measure of bits currently available to be read from /dev/random
It takes time for the computer to read entropy from its environment unless it has cool hardware like a noisy diode or something.
If you have 4096 bits of entropy available and you cat /dev/random
you can expect to be able to read 512 bytes of entropy (4096 bits) before the file blocks while it waits for more entropy.
For example if you “cat /dev/random
” your entropy will shrink to zero. At first you'll get 512 bytes of random garbage but it will stop and little by little you'll see more random data trickle trough.
This is not how people should operate /dev/random
though. Normally developers will read a small amount of data, like 128 bits, and use that to seed some kind of PRNG algorithm. It's polite to not read any more entropy from /dev/random
than you need to since takes so long to build up and is considered valuable. Thus if you drain it by carelessly cat
ting the file like above you'll cause other applications that need to read from /dev/random
to block. On one system at work we noticed that a lot of crypto functions were stalling out. We discovered that a cron job was calling a python script that kept initializing ramdom.random()
on each run which which ran every few seconds. To fix this we rewrote the python script so that it ran as a daemon that initialized only once and the cron job would read data via XMLRPC so that it wouldn't keep reading from /dev/random
on startup.