On Fri, May 26, 2023 at 9:11 PM Jonathan Billings <billi...@negate.org> wrote: > > The detail is covered in articles on lwn.net., search for RNG. > > It’s worth reading here: > https://lwn.net/Articles/884875/ > > Some of the comments on /dev/random blocking aren’t quite correct for Fedora > kernels in 37 and 38. > > Fun story: a couple jobs back we had a fancy documentation service on el5 > that launched just fine in dev but would hang until a timeout killed it in > prod. It was a big Java tomcat service and part of the initialization > involved creating some session keys on startup, and when I attached it to a > debugger, prod was hanging in the crypto libraries. I was able to watch the > entropy pool drain in real-time by watching the file in/proc. > > Turns out, dev was a cluster of VMs in a VMware cluster that ran hundreds of > other VMs, which ran on servers that had a lot of sources of entropy and fed > that to the VMs. But Prod was a bunch of blades in an enclosure using fiber > channel storage. They had a CPU that didn’t provide an entropy source. It had > no keyboard or mouse, and the network wasn’t active until after the service > started. The FC enclosure used disks that were SSDs that didn’t provide much > of an entropy source. The Java crypto library (I want to say it was > BouncyCastle?) was using a blocking /dev/random. > > Since we wanted the session keys to be more random, we decided not to use > urandom , so a quick fix was it dd’ing the first couple hundred megabytes off > the disk to /dev/null on boot, and eventually we got the haveged daemon > feeding the entropy pool. Explaining why my hack worked was fun.
There's no practical difference between /dev/random and /dev/urandom under the standard models. The standard security model presumes the prng's state is secret. If the state remains unknown to an attacker, it does not matter how the entropy is gathered, extracted or expanded. From the attacker's perspective, the stream looks random and follows a uniform distribution. And more importantly, the stream is unpredictable. You gain nothing by using /dev/random, and you set yourself up for a DoS (as you experienced). Or worse, you read /dev/random with the non-blocking flag (O_NONBLOCK), and you don't check return values so you don't realize you actually read 0 random bytes (but truck on as if successful). (I think what a lot of folks don't realize is, /dev/random has state. It does not matter what the secret state is from physical phenomena (or other gyrations for /dev/urandom), or how the entropy is extracted and expanded. What matters is the state stays secret). Jeff _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
