3 ms·

This is something that has frustrated me for years. There has been no interest in modernizing the Linux PRNG really ever. This article doesn't go into more de

by salmo 5y ago

This is something that has frustrated me for years. There has been no interest in modernizing the Linux PRNG really ever. This article doesn't go into more depth so I don't know if it's just tacking on more entropy sources and algorithm support or a real modernization. Windows, MacOS, every BSD, Solaris, etc. have moved past the (blocking) /dev/random vs /dev/urandom to more mathematically sound solutions. (Seriously, measuring entropy?) But Torvalds, Ts'o, etc. have blocked, belittled, or ignored any movement there. It's crazy that the OS that runs all the things essentially has a roll-your-own-crypto PRNG at its core rather than relying on actual experts for that. Unfortunately, it's "good enough" to not HAVE to change. Use /dev/random sparingly to seed your own PRNG, change your Java config to use /dev/urandom, or (shudder) use rngd to make it seed itself. At least once a year I hit some COTS product that craps itself under load blocking on /dev/random on a VM, causing an outage. Yes, it's a "worked on my laptop" problem, but an unnecessary rake to leave out in the garden.

gerdesj 5y ago
This is from early last year: https://lwn.net/Articles/808575/ https://lwn.net/Articles/808575/ "Removing the Linux /dev/random blocking pool"
jeltz 5y ago
Linux has also moved past it, but only quite recently. https://lwn.net/Articles/808575/ https://lwn.net/Articles/808575/
ploxiln 5y ago
Blocking /dev/random has been a problem that many people were interested about for a long time, and it has had alternatives: /dev/urandom since forever (though it has a big problem for some short period just after bootup), getentropy() since 2015 can do the right thing with the right options, and finally since 2020 /dev/random does the right thing - it only blocks until seeded, then gives unlimited secure random bytes. (I only learned about this 2020 update in this very thread!) My understanding is that /dev/random behavior persisted for so long only due to some dumb corporate/military compliance thing that some huge companies "needed". EDIT: apparently this was due to NIST standard SP800-90B and maybe German AIS 31, and the most recent idea is to forget them, and have orgs that really need the strange/problematic blocking behavior implement it in user-space.

by salmo 5y ago

gerdesj 5y ago

This is from early last year: https://lwn.net/Articles/808575/ https://lwn.net/Articles/808575/ "Removing the Linux /dev/random blocking pool"

jeltz 5y ago

Linux has also moved past it, but only quite recently. https://lwn.net/Articles/808575/ https://lwn.net/Articles/808575/

ploxiln 5y ago

Blocking /dev/random has been a problem that many people were interested about for a long time, and it has had alternatives: /dev/urandom since forever (though it has a big problem for some short period just after bootup), getentropy() since 2015 can do the right thing with the right options, and finally since 2020 /dev/random does the right thing - it only blocks until seeded, then gives unlimited secure random bytes. (I only learned about this 2020 update in this very thread!) My understanding is that /dev/random behavior persisted for so long only due to some dumb corporate/military compliance thing that some huge companies "needed". EDIT: apparently this was due to NIST standard SP800-90B and maybe German AIS 31, and the most recent idea is to forget them, and have orgs that really need the strange/problematic blocking behavior implement it in user-space.