On Wed, Jul 06, 2016 at 12:31 AM, Rob Landley said: > Which is why you'd read a byte from /dev/random first if you > need to wait for the pool to have entropy in it? Given that > there's an existing mechanism that will block that'sbeen here > for 20 years?
This article: Myths about /dev/urandom http://www.2uo.de/myths-about-urandom/ and this LWN thread: A system call for random numbers: getrandom() https://lwn.net/Articles/606141/ provide answers to some of these questions. IIUC, reading one byte from /dev/random as a surrogate for getrandom() has several obvious problems. You want to: A) block until the CSPRNG has been seeded with at least 256 (128?) bits of entropy and, B) not block after that. I don't know if reading a byte from /dev/random satisfies the first condition but it clearly fails at the second. According to the "myths" article there are separate entropy pools for /dev/random and /dev/urandom (both fed from a primary entropy pool). So it is not clear to me that /dev/random gives an accurate indication of the state of the /dev/urandom pool. It even seems possible that reading from /dev/random will help starve the /dev/urandom pool. Also, I doubt Theodore Ts'o would have bothered with getrandom() if reading a single byte from /dev/random before reading from /dev/urandom was a reasonable alternative. Likewise, people who seem to know a lot more about this than I do would not be praising getrandom() if there was such an easy alternative. As said in the "myths" article: [W]hile appeal to authority is usually nothing to be proud of, in cryptographic issues you're generally right to be careful and try to get the opinion of a domain expert. Peace, James _______________________________________________ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
