References for update
- Removing the Linux /dev/random blocking pool (Hacker News)
- Linux 4.13 will bring the next important updates for
I've updated the page to account for the "Removing the Linux /dev/random blocking pool" changes, and I made the "See also" section link to the LWN article. The other links mentioned above are related to the introduction of the
wait_for_random_bytes() kernel-internal API, which is a fairly minor detail that is not covered in the article. I think that should continue to be left out in favor of more relevant and important information. So I am considering this to be resolved. Synchronicity (talk) 08:11, 6 February 2023 (UTC)
Outdated! As far as I can tell this page is outdated, at least concerning the part about `/proc/sys/kernel/random/poolsize` which seems to be 256 now. e.g. https://unix.stackexchange.com/questions/704737/kernel-5-10-119-caused-the-values-of-proc-sys-kernel-random-entropy-avail-and-p and links therein. As I don't really understand this topic, I cannot contribute a fix. Here the writeup by the person contributing the kernel update: https://www.zx2c4.com/projects/linux-rng-5.17-5.18/ Mauro3 (talk) 21:09, 28 December 2022 (UTC)
- This has been fully resolved by the re-write of the page by Synchronicity on 2 February 2023. Mauro3 (talk) 08:22, 2 February 2023 (UTC)
- Yes, the kernel RNG section is up-to-date now. The other sections still need to be cleaned up. In general, the article should recommend the kernel RNG pretty strongly, and be more specific about the limited cases where something else (such as a userspace RNG seeded from the kernel RNG, or direct use of a hardware RNG) could make sense. Synchronicity (talk) 08:35, 2 February 2023 (UTC)
Removing "OpenSSL issues" section
If there are no objections, I'd like to remove the "OpenSSL issues" section. It describes how to configure OpenSSL's random number generation to use RDRAND directly, instead using the default setting of a CRNG seeded from the kernel's RNG. I do not see any reason to do this. There is no security benefit to doing this, because the kernel's RNG already uses RDSEED as an entropy source. There is also no performance benefit to doing this. In fact, it degrades performance by over 100x (at least on an AMD Zen CPU), based on benchmarking with
openssl rand, because RDRAND is very slow whereas OpenSSL's CRNG is very fast. Synchronicity (talk) 08:14, 6 February 2023 (UTC)
- I don't see we need an extra section for it either (anymore), but likewise don't think it is necessary to make general statements about performance. I think it is useful to give the examples of common server-/applications that may offer explicit engine choice options, but that can be added with a sentence to bullet 2 of Random number generation#Alternatives. --Indigo (talk) 18:22, 16 February 2023 (UTC)
- I've gone ahead and removed the section. By the way, someone at https://bbs.archlinux.org/viewtopic.php?id=283527 seems to have been confused by it existing.
- I don't think that direct use of RDRAND should be mentioned as a reasonable option at all. It's slow, and it's better to use multiple entropy sources rather than RDRAND exclusively.