Together with the italicized remark I read that as “there is this unnamed platform that does not use RNG but just hashes bunch of arbitrary system parameters and state and calls the result random-enough”. In fact the unnamed OS does not do that and reality is significantly more complex and involves PRNG, but the official documantation for well-known and officially undocumented and unsupported internal get_random()-like API is worded in a way that implies that what it returns is simply MD5 of giant struct containing around hundred of assorted timers, counters and other system state.
Re:Entropy and the NetBSD Kernel
by libeclipse on Sunday May 17, 2020 @10:22AM
(#23212194)
Yep, one of the cool things about entropy is that it always increases. If you keep XORing more information into the seed pool, you only ever increase the total entropy.
As long as you use reasonably secure way to add entropy into the pool, ie. don't XOR stuff into some kind of pool buffer but use something that at least partly resembles secure hash even for adding entropy (as using full-blown SHA-x to process interrupt timings and similar high volume low quality entropy sources is not exactly practical due to both performance and synchronization issues).
Also, total entropy is not necessarily the same thing as attacker's uncertainity of the pool's state. The difference seems mostly theoretical, but there are practical issues for both cases of these two quantities beeing wildy different.
+1 on the mix-with-SHA or something like it paragraph.
Re: Entropy; in a system RNG design, entropy is typically considered relative to an attacker. In some very real sense, the "total entropy" of the system is only the unpredictability of the generator to the most knowledgeable attacker.
Re:Entropy and the NetBSD Kernel
by a1369209993 on Sunday May 17, 2020 @05:28PM
(#23215642)
I wasn't one of the downvoters, since your actual point is clear and true, but DO NOT EVER USE XOR TO COMBINE ENTROPY! I cannot emphasize this enough - XOR allows malicous entropy sources to cancel out other entropy. Always use a cryptographically secure hash function, especially when adding entropy from RDRAND.
As this article says, early in the process you often have several soirces of low quality, and all we can do is hope to get the best we can from anywhere we can. The name and versions of everything attached is fairly horrible entropy, but it doesn't hurt.