> On the BSDs getentropy() is hence unconditionally blocking
lore.kernel.org/linux-ext4/201
Lennart/Linux people still don't get it.. OpenBSD getentropy(2) does not block by design. The same as /dev/urandom.
man.openbsd.org/random.4
man.openbsd.org/getentropy.2
Conversation
Replying to
And about the nonblocking nature of getentropy(): After head scratching enough I realized (it's in the slides) that gentropy doesn't need to block because calling it produces entropy. Every call to it takes a slice of shared stream and one can't predict the order of consumption.
1
1
Every fork(), malloc(), free(), etc. takes a slice of shared stream. It's impossible to predict how much the random stream has advanced. And the stream gets stirred all the time with new entropy from multiple sources. It's really novel!
1
5
An 128-bit seed is enough to produce a strong cryptographic random stream indefinitely. Continuously adding entropy is useful because it provides backward secrecy where an attacker that has previously leaked the CSPRNG state quickly stops being able to predict future output.
1
1
7
The concept of entropy running out is a nonsense Linux cargo cult approach. It definitely makes sense to keep gathering entropy and adding it to the CSPRNG (which can avoid trusting either the existing state or the new entropy) but not because entropy of the CSPRNG is used up.