Re:Entropy and the NetBSD Kernel
by cipher_314159 on Sunday May 17, 2020 @09:02PM
(#23217100)
Oh, there are definitely better ways to de-bias; the read-check-discard construction is meant as a math example, not practical advice. Most of the popular PRNG constructions (for instance, anything in SP800-90A) will integrate things in a much saner fashion (e.g., with a hash or MAC algorithm). I was mainly trying to make the point that a bias in a random bit source doesn't automatically mean that everything is broken and horrible.
The biased/low-entropy point was mainly in relation to a specific case mentioned in the original article (Allwinner embedded ARM systems). I don't know how quickly that particular HWRNG provides data, but if the bias isn't huge, and the random can be read quickly enough, I'd probably argue to include it. Even if it's biased 4-to-1, you can still reach a desired "amount" of randomness (however you're choosing to measure it) pretty quickly.
Low-entropy random sources don't hurt but there's not really much point using them unless you have no better options (i.e., jitter entropy for initial seeding on embedded systems).
Better to just use the biased source directly than to make up an ad-hoc de-biasing algorithm. I'm know there are mathy ways to combine imperfect sources and get perfect entropy out, but it adds complexity, which is a risk.
Respect where it is due to DJB, but if Intel wants to compromise your system, it's already got the SMM/IME backdoor; it doesn't need to poison RDRAND. There is sometimes a disconnect between cryptography researchers and cryptography practitioners. I enjoyed and would recommend JPA et al's RWC paper, Too Much Crypto: https://eprint.iacr.org/2019/1492.pdf