3 ms·

See https://news.ycombinator.com/item?id=21187044 https://news.ycombinator.com/item?id=21187044 > If you're on an ancient Linux kernel, you can poll /dev/rando

See https://news.ycombinator.com/item?id=21187044 https://news.ycombinator.com/item?id=21187044 > If you're on an ancient Linux kernel, you can poll /dev/random until it's available if you're uncertain whether or not /dev/urandom has ever been seeded. Once /dev/random is available, don't use /dev/random, use /dev/urandom. This side-steps the "/dev/urandom never blocks" concern that people love to cite in their fearmongering. This is essentially what getrandom(2) does. This is outlined here as well: https://paragonie.com/blog/2016/05/how-generate-secure-random-numbers-in-various-programming-languages https://paragonie.com/blog/2016/05/how-generate-secure-rando... This is what randombytes_buf() does in libsodium on older Linux kernels. This is actually the best of both worlds: Although /dev/urandom on Linux will happily give you predictable values if you try to read from it before the RNG has been seeded on first boot, once /dev/random is "ready" to be read from once, you know that the entropy pool powering /dev/urandom has been seeded. And then you can guarantee that /dev/urandom is secure and nonblocking henceforth. If you can't just use getrandom(2), do the "poll /dev/random, then read /dev/urandom" dance and even the fearmonger's favorite issue to cite becomes a non-issue.

raverbashing 7y ago
Thanks, I saw this comment right after I posted mine.
zumdeibel 7y ago
I don't think using poll on /dev/random is a good idea, here's why: 1. /proc/sys/kernel/random/read_wakeup_threshold is 64 by default [1,2], but the kernel only considers the pool initialized with >128 bits [3]. So in an early userspace you're likely to be reading from an uninitialized /dev/urandom after waking up from poll if you're not also checking the entropy count to be >128. 2. /dev/random could be a symlink to /dev/urandom, so the call to poll would return as soon as possible. 3. The system could only be providing /dev/urandom. So if you're going to have to check the entropy count anyway, a less convoluted approach would be to repeatedly retrieve it via the RNDGETENTCNT ioctl [1] on a /dev/urandom file descriptor and sleeping while it hasn't reached >128 bits yet. Don't take my word for the feasibility of this fallback method as I'm not a cryptographer or implementer of cryptographic interfaces. Instead, consider BoringSSL (Adam Langley et al.) that does almost the same in its /dev/urandom fallback. [4] [1]: http://man7.org/linux/man-pages/man4/random.4.html http://man7.org/linux/man-pages/man4/random.4.html [2]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/char/random.c?id=v5.3#n377 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... [3]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/char/random.c?id=v5.3#n770 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... [4]: https://boringssl.googlesource.com/boringssl/+/refs/heads/master/crypto/fipsmodule/rand/urandom.c https://boringssl.googlesource.com/boringssl/+/refs/heads/ma...

raverbashing 7y ago

Thanks, I saw this comment right after I posted mine.

zumdeibel 7y ago

I don't think using poll on /dev/random is a good idea, here's why: 1. /proc/sys/kernel/random/read_wakeup_threshold is 64 by default [1,2], but the kernel only considers the pool initialized with >128 bits [3]. So in an early userspace you're likely to be reading from an uninitialized /dev/urandom after waking up from poll if you're not also checking the entropy count to be >128. 2. /dev/random could be a symlink to /dev/urandom, so the call to poll would return as soon as possible. 3. The system could only be providing /dev/urandom. So if you're going to have to check the entropy count anyway, a less convoluted approach would be to repeatedly retrieve it via the RNDGETENTCNT ioctl [1] on a /dev/urandom file descriptor and sleeping while it hasn't reached >128 bits yet. Don't take my word for the feasibility of this fallback method as I'm not a cryptographer or implementer of cryptographic interfaces. Instead, consider BoringSSL (Adam Langley et al.) that does almost the same in its /dev/urandom fallback. [4] [1]: http://man7.org/linux/man-pages/man4/random.4.html http://man7.org/linux/man-pages/man4/random.4.html [2]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/char/random.c?id=v5.3#n377 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... [3]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/char/random.c?id=v5.3#n770 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... [4]: https://boringssl.googlesource.com/boringssl/+/refs/heads/master/crypto/fipsmodule/rand/urandom.c https://boringssl.googlesource.com/boringssl/+/refs/heads/ma...