On Sat, May 30, 2020 at 11:44:55PM +0200, Gero Treuner wrote:
According to the documents available in the net, entropy is not influenced by consuming random numbers. Entropy is used to contantly (re)reseeding the PRNG, and if insufficient entropy is present, you might get imperfect random numbers (we don't care much for our purposes).This could happen right after boot. On Linux this is commonly mitigated by seeding with saved random from the previous system run. FreeBSD is reported to wait before emitting random numbers until the entropy level is reached. Both, OpenSSL and GnuTLS source /dev/urandom, which doesn't block.
Thanks Gero. What I'm a bit unclear about is the effect reading from /dev/urandom has on /dev/random users. Some peeking around seems to indicate that (at least at one time) they read from the same "pool", but when the pool runs low urandom emits "less-random" values, whereas /dev/random blocks. Doesn't this mean there is an effect from using /dev/urandom for /dev/random users?
Also, FreeBSD apparently doesn't distinguish between the two. Does GnuTLS and OpenSSL take care to not block in that case?
Is this something we *really* want to do for tempfiles and boundaries?That said, this is also *really* something I don't care deeply about, and I hate to block your and Remco's efforts on this just because it's low priority for me. Would you be willing to collaborate with Remco to come up with patches for a random api and message-id generator that you both approve of? If it's something that passes your review, I will commit it.
Thank you. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
signature.asc
Description: PGP signature