6 ms·

Can anyone elaborate on why Ruby's SecureRandom shouldn't be used? I find this to be rather surprising and discomforting.

tptacek 10y ago
It defaults to the OpenSSL userland CSPRNG, if available, because Ruby's maintainers believe (incorrectly) that urandom is unsafe for key generation.
- brandur 10y ago
  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. [1] https://github.com/cryptosphere/sysrandom#why https://github.com/cryptosphere/sysrandom#why [2] https://bugs.ruby-lang.org/issues/9569 https://bugs.ruby-lang.org/issues/9569
  - scrollaway 10y ago
    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...
  - raverbashing 10y ago
    > 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]. Why doesn't this surprise me...
  - Nokinside 10y ago
    Oh man. 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.
    - tptacek 10y ago
      This is a case where both the Ruby community and the Linux community are standing in the way of security.
      - Nokinside 10y ago
        What's wrong with random numbers in Linux?
        tptacek 10y ago
        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.
        Nokinside 10y ago
        /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.
        tptacek 10y ago
        /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.
  - ufo 10y ago
    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?
    - tptacek 10y ago
      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.
      - CiPHPerCoder 10y ago
        You totally can, but more importantly, you shouldn't. :)
  - joepie91_ 10y ago
    > 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 https://eprint.iacr.org/2016/367.pdf
- veeti 10y ago
  Is that Linux man page ever going to be corrected?
  - cpach 10y ago
    I sure hope so! But don't hold your breath...
  - pwg 10y ago
    Given that those man-pages are a community open source project much like the kernel, the best way to see it fixed is to contribute a fix: https://www.kernel.org/doc/man-pages/contributing.html https://www.kernel.org/doc/man-pages/contributing.html
    - chowells 10y ago
      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.
    - deleted 10y ago
      [deleted]
  - Sir_Cmpwn 10y ago
    There's a patchset that's been under discussion for a while.
- eveningcoffee 10y ago
  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.
wastedhours 10y ago
I always use SecureRandom to generate unique IDs, but not to actually secure things - am I to take it that it would still be wise to switch to Sysrandom in that case as the vuln is in going through OpenSSL to do it (rather than the generated random not being random etc)?

tptacek 10y ago

It defaults to the OpenSSL userland CSPRNG, if available, because Ruby's maintainers believe (incorrectly) that urandom is unsafe for key generation.

brandur 10y ago
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. [1] https://github.com/cryptosphere/sysrandom#why https://github.com/cryptosphere/sysrandom#why [2] https://bugs.ruby-lang.org/issues/9569 https://bugs.ruby-lang.org/issues/9569
- scrollaway 10y ago
  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...
- raverbashing 10y ago
  > 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]. Why doesn't this surprise me...
- Nokinside 10y ago
  Oh man. 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.
  - tptacek 10y ago
    This is a case where both the Ruby community and the Linux community are standing in the way of security.
    - Nokinside 10y ago
      What's wrong with random numbers in Linux?
      - tptacek 10y ago
        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.
        Nokinside 10y ago
        /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.
        tptacek 10y ago
        /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.
- ufo 10y ago
  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?
  - tptacek 10y ago
    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.
    - CiPHPerCoder 10y ago
      You totally can, but more importantly, you shouldn't. :)
- joepie91_ 10y ago
  > 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 https://eprint.iacr.org/2016/367.pdf
veeti 10y ago
Is that Linux man page ever going to be corrected?
- cpach 10y ago
  I sure hope so! But don't hold your breath...
- pwg 10y ago
  Given that those man-pages are a community open source project much like the kernel, the best way to see it fixed is to contribute a fix: https://www.kernel.org/doc/man-pages/contributing.html https://www.kernel.org/doc/man-pages/contributing.html
  - chowells 10y ago
    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.
  - deleted 10y ago
    [deleted]
- Sir_Cmpwn 10y ago
  There's a patchset that's been under discussion for a while.
eveningcoffee 10y ago
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.

wastedhours 10y ago

I always use SecureRandom to generate unique IDs, but not to actually secure things - am I to take it that it would still be wise to switch to Sysrandom in that case as the vuln is in going through OpenSSL to do it (rather than the generated random not being random etc)?