Why generating random consumes an entropy?
For the same reason that to generate true random bits using coin throws, one needs to throw a coin for each bit generated. Any attempt to use less throws is doomed (against a computationally unbounded adversary, or if the technique relies on few simple bit combinations).
Why generating a random bit causes that entropy to become useless?
Revealing a generated random bit is what makes it useless towards generating further secure random bits.
There's a solution: generate a sufficient number of random bits (like 256 or more) and use these, exclusively, to seed a Cryptographically Secure Pseudo Random Number Generator which will supply an endless stream of bits that have all testable properties of truly random bits. That's part of the strategy of Unix's /dev/urandom
/dev/random
works in Linux. If you read from it then it subtracts from an entropy counter how many bits you requested. It doesn't need to work that way. It's disagreed upon whether this should be the behavior of/dev/random
. As long as at least 128 bits of entropy have been in the system since boot time (or since the last compromise of kernel memory) then both devices produce unpredictable output. $\endgroup$ – Future Security Sep 28 '18 at 21:01getrandom
system call withflags == 0
is preferable, in my opinion. It only blocks before there is enough entropy to securely seed a CSPRNG. After that it ignores the entropy counter and produces RNG output without blocking. Theurandom
,random
, andgetrandom
interfaces all use the same source of randomness. The OS continues to incorporate extra entropy into that randomness pool, in case entropy was over-estimated or kernel memory was compromised. $\endgroup$ – Future Security Sep 28 '18 at 21:18