The README of the gem that the article recommends ("sysrandom") provides a good explanation [1].
And here is the contentious Ruby issue wherein the Ruby core developers insist on cargo culting according to an outdated man page despite comprehensive refutation from a number of experienced security engineers [2].
That said, the arguments against OpenSSL seem to be largely theoretical at this point ("has been a source of vulnerabilities in Ruby ..."), so the misgivings about `SecureRandom` may be slightly exaggerated.
What a disaster of a bug report, on so many levels.
Speaking as a foss maintainer, to other foss maintainers out there: When you're systematically adopting a defensive attitude towards someone who believes found an important flaw in your project, you're the one being rude. You're refusing to hear people out. I see this awful attitude far too often.
On Github, it's even worse nowadays where a lot of maintainers immediately fall back to locking the bug report so that they don't have to think about it anymore. At least here there is some form of discussion going on. But that's with a lot of fingers in a lot of ears, and nobody trying to be practical...
There is huge undiscovered land of material for cross-cultural and comparative research in communication in these developer forums. Ruby and Linux mailing lists could provide material for number of really interesting studies in many fields.
Ruby community has hint of Japanese culture: design aesthetics, simplicity, importance of politeness, saving face and rigidity.
Linux community has hint of Finnish culture: practicality, "pig energy" and "management by perkele" combined with 80's competitive hacker culture.
They have a /dev/random interface which (literally) randomly blocks, disrupting programs, and a man page that instructs the Ruby community to use /dev/random and not /dev/urandom.
/dev/random is the blocking pseudorandom number generator in Unix-like operating systems and it provides only the entropy that can be obtained from environmental noise. I don't see how it can work any other way.
What is the manpage we are discussing here? I think getrandom(2) and random(4) are quite good.
/dev/random keeps a counter that is effectively random that tells the interface to block. /dev/urandom has the same mechanics as /dev/random, the same inputs, and the same cryptographic constructions, but does not have the random blocking counter.
/dev/urandom is the interface you want.
/dev/random is unsuitable for production code because, again, it randomly blocks, which can freeze your application. Worse still: applications that use /dev/random tend to "work around" the problem by using /dev/random to seed a userspace RNG that doesn't block. That's not just inconvenient but overtly unsafe.
> /dev/random is the blocking pseudorandom number generator in Unix-like operating systems
This is not the behavior on FreeBSD and OS X. On those systems, once a sufficient amount of entropy is estimated to have been gathered since boot, /dev/random will not block again.
Linux's /dev/random behavior (1) relies too heavily on accurate estimates of entropy and (2) implies a simultaneous fundamental mistrust in the ability of cryptographic methods to expand several hundred bits of entropy into a few megabytes of data indistinguishable from random noise and yet simultaneous belief in the strength of cryptographic algorithms for expanding maybe a kilobit of long-term key material into terabytes of data indistinguishable from random noise. (The rationale for blocking is to produce better long-term keys.)
Linux's /dev/random rekeys its internal state at a fixed entropy estimate. If state is compromised and the estimate is too optimistic, it will never recover from state compromise. If the estimate is too pessimistic, state is left vulnerable longer than necessary.
Bruce Schneier and Niels Ferguson's Fortuna for a design is more robust and consistent. A series of entropy pools all collect entorpy at the same rate, but are emptied at exponentially longer intervals. Eventually, one of the pools used to rekey will have enough entropy to recover from state compromise, and it doesn't rely on the dubious practice of entropy estimation. Now, estimating how long recovering from state compromise will take requires estimating entropy, but with a Fortuna construction we can prove that recovery will eventually happen as long as entropy is actually being collected.
If you're using TLS with AES-GCM, a Fortuna construction built using AES has an added advantage that an attack that recovers Fortuna state is almost certainly directly applicable to your TLS setup. In other words, you're depending on fewer algorithms, the failure of any one of which dooms you.
FreeBSD uses Fortuna for /dev/[u]random. OS X uses Fortuna's predecessor Yarrow, which still has the weakness of relying on entropy estimation, but at least it has two pools (one with a pessimistic rekey rate) instead of Linux's single rekey rate.
The LRNG is fine. It could be faster, and it could be simpler and more coherent to facilitate formal analysis. But the underlying task that we want an OS CSPRNG to do is not complicated.
I think it would be a bad idea to forklift out the LRNG in favor of an entirely new design.
It's possible that all Linux really needs to do is fix the man page, and perhaps do something in the kernel (rather than in OS distributions) to solve seed-at-boot.
> /dev/random is the blocking pseudorandom number generator in Unix-like operating systems and it provides only the entropy that can be obtained from environmental noise. I don't see how it can work any other way.
There is no reason to block; there isn't even any good way to estimate the entropy of environmental noise.
The only sane thing to do is to seed a CSPRNG with environmental noise, reseed with environmental noise as available, and never block.
I think the maintainer has a point in saying that the `man 4 random` page should have been updated if its giving wrong advice. I just checked and on my system that manpage still says all that wrong stuff about /dev/urandom. Why is it still unchanged?
Because Linux man pages are sometimes dumb. I can give you a more precise answer but I don't think it will improve the thread.
You should, however, take my word for it. Or, better yet, take Daniel Bernstein's word for it. Take Adam Langley's implied word for it (he's behind crypto/rand in Go). Take Thomas Pornin's word for. You can take Thomas Pornin's word on almost anything! Take Filippo Valsorda's word for it. Or Thomas Huhn's.
The man page is wrong. Should it be fixed? Yes, it should be fixed. But, no excuses. You can't introduce security problems out of obstinacy about man pages.
> That said, the arguments against OpenSSL seem to be largely theoretical at this point
I would disagree. This is a recent paper on the state of OpenSSL's userspace PRNG, for example, finding several issues: https://eprint.iacr.org/2016/367.pdf
> uby issue wherein the Ruby core developers insist on cargo culting according to an outdated man page despite comprehensive refutation from a number of experienced security engineers [2].
Anecdotal case here. I did a research about usage of secure random number generation few year ago and gave up with OpenSSL. They used indirection upon indirection and it was really hard to understand what would be actually called.
Therefore I was really not surprised when problems related to OpenSSL random generation started to pup up later on.
In this case, that's far from true. Many people have contributed correct documentation. Whoever is in charge of these things continually rejects it because of their mistaken beliefs about PRNGs.
