4 ms·

You should post these reasons in your gist. As I thought, there are a few reasons one might want to use /dev/random. Blanket "don't use X" statements are much

You should post these reasons in your gist. As I thought, there are a few reasons one might want to use /dev/random. Blanket "don't use X" statements are much more useful with context and information about why not to use X (and when using X may be required, useful, or a better choice).

tptacek 10y ago
No, there aren't. Don't use /dev/random.
- jjnoakes 10y ago
  The reasons I know about for using /dev/random are quoted in the article you yourself just posted here... https://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/ https://sockpuppet.org/blog/2014/02/25/safely-generate-rando...
  - tptacek 10y ago
    Since I wrote that article, I'm pretty confident that it doesn't recommend ever using /dev/random.
    - jjnoakes 10y ago
      I said the article mentioned reasons one might want to use /dev/random (or be careful about blindly using /dev/urandom), not that the article recommends using /dev/random. But since you wrote the article you should realize this. Just because the article recommends seeding over using /dev/random early at boot time doesn't mean the original gist shouldn't mention these issues so that readers are aware of them. Just saying "use /dev/urandom all the time" without mentioning the caveats we're discussing here means someone might read your article and in a (misguided) appeal to authority implement something solely on your recommendation without doing their research properly first. I would have thought someone writing security articles would want to avoid misleading someone into implementing something that's accidentally insecure. I hope I'm not wrong.
      - tptacek 10y ago
        Here's another article you can argue with: http://www.2uo.de/myths-about-urandom/ http://www.2uo.de/myths-about-urandom/ And another: http://security.stackexchange.com/questions/3936/is-a-rand-from-dev-urandom-secure-for-a-login-key/3939 http://security.stackexchange.com/questions/3936/is-a-rand-f...
        jjnoakes 10y ago
        > Here's another article you can argue with: > http://www.2uo.de/myths-about-urandom/ http://www.2uo.de/myths-about-urandom/ Which backs up my point that using /dev/urandom blindly without knowing about some of the edge cases isn't a good idea, and lists those edge cases and what to do about them (which is what I suggested you do too). > And another: > http://security.stackexchange.com/questions/3936/is-a-rand-f.. http://security.stackexchange.com/questions/3936/is-a-rand-f.... Which also lists the edge cases I'm talking about. Hey look if you just want to say "I'm aware of the edge cases and don't want to put them in my gist for others to see" that's fine with me, but dodging the issue by claiming there are no edge cases (and then listing 3 articles which all mention the edge cases) isn't the right reply I think. Don't be surprised if someone suggests that a gist listing security best practices list some edge cases that go along with the blind advice too. Feel free to disagree, but at least disagree honestly.
        tptacek 10y ago
        I honestly disagree.
        jjnoakes 10y ago
        Appreciated.
Dylan16807 10y ago
There's no reason to pull bytes out of /dev/random. In the rare circumstance that you're worried about it being early in the first boot and getrandom doesn't exist, you might throw away a single byte from /dev/random to make sure it's ready. But then you're done, and use urandom. And your program almost certainly doesn't need to worry about that circumstance.
- jjnoakes 10y ago
  Unless no programs ever need to worry about that case (which is untrue), why not mention in a security gist purporting to be a list of crypto implementation suggestions? Why not be complete and list the caveat, instead of incomplete and possibly lead that one in a thousand down the wrong path?
  - Dylan16807 10y ago
    Far more than one in a thousand will use it as an excuse to do the wrong thing. And lots of articles about best practice leave out very rare edge cases. No advice is always always right.
    - jjnoakes 10y ago
      > lots of articles about best practice leave out very rare edge cases I don't think that's an argument in support of leaving out edge cases, and even if you disagree in general, I think security articles should be more diligent than random best-practices articles. > Far more than one in a thousand will use it as an excuse to do the wrong thing. If an article says "always do X" and someone does X and the implementation is subtly wrong or insecure, that's an argument to improve the article (which is what I'm suggesting). But if an article says "almost always do X, and be aware of this edge case" and someone gets it wrong by not following instructions, then I don't think the article is at fault. I would personally want my security advice to cover any edge case I could think of, even if only in the footnotes.

tptacek 10y ago

No, there aren't. Don't use /dev/random.

jjnoakes 10y ago
The reasons I know about for using /dev/random are quoted in the article you yourself just posted here... https://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/ https://sockpuppet.org/blog/2014/02/25/safely-generate-rando...
- tptacek 10y ago
  Since I wrote that article, I'm pretty confident that it doesn't recommend ever using /dev/random.
  - jjnoakes 10y ago
    I said the article mentioned reasons one might want to use /dev/random (or be careful about blindly using /dev/urandom), not that the article recommends using /dev/random. But since you wrote the article you should realize this. Just because the article recommends seeding over using /dev/random early at boot time doesn't mean the original gist shouldn't mention these issues so that readers are aware of them. Just saying "use /dev/urandom all the time" without mentioning the caveats we're discussing here means someone might read your article and in a (misguided) appeal to authority implement something solely on your recommendation without doing their research properly first. I would have thought someone writing security articles would want to avoid misleading someone into implementing something that's accidentally insecure. I hope I'm not wrong.
    - tptacek 10y ago
      Here's another article you can argue with: http://www.2uo.de/myths-about-urandom/ http://www.2uo.de/myths-about-urandom/ And another: http://security.stackexchange.com/questions/3936/is-a-rand-from-dev-urandom-secure-for-a-login-key/3939 http://security.stackexchange.com/questions/3936/is-a-rand-f...
      - jjnoakes 10y ago
        > Here's another article you can argue with: > http://www.2uo.de/myths-about-urandom/ http://www.2uo.de/myths-about-urandom/ Which backs up my point that using /dev/urandom blindly without knowing about some of the edge cases isn't a good idea, and lists those edge cases and what to do about them (which is what I suggested you do too). > And another: > http://security.stackexchange.com/questions/3936/is-a-rand-f.. http://security.stackexchange.com/questions/3936/is-a-rand-f.... Which also lists the edge cases I'm talking about. Hey look if you just want to say "I'm aware of the edge cases and don't want to put them in my gist for others to see" that's fine with me, but dodging the issue by claiming there are no edge cases (and then listing 3 articles which all mention the edge cases) isn't the right reply I think. Don't be surprised if someone suggests that a gist listing security best practices list some edge cases that go along with the blind advice too. Feel free to disagree, but at least disagree honestly.
        tptacek 10y ago
        I honestly disagree.
        jjnoakes 10y ago
        Appreciated.

Dylan16807 10y ago

There's no reason to pull bytes out of /dev/random. In the rare circumstance that you're worried about it being early in the first boot and getrandom doesn't exist, you might throw away a single byte from /dev/random to make sure it's ready. But then you're done, and use urandom. And your program almost certainly doesn't need to worry about that circumstance.

jjnoakes 10y ago
Unless no programs ever need to worry about that case (which is untrue), why not mention in a security gist purporting to be a list of crypto implementation suggestions? Why not be complete and list the caveat, instead of incomplete and possibly lead that one in a thousand down the wrong path?
- Dylan16807 10y ago
  Far more than one in a thousand will use it as an excuse to do the wrong thing. And lots of articles about best practice leave out very rare edge cases. No advice is always always right.
  - jjnoakes 10y ago
    > lots of articles about best practice leave out very rare edge cases I don't think that's an argument in support of leaving out edge cases, and even if you disagree in general, I think security articles should be more diligent than random best-practices articles. > Far more than one in a thousand will use it as an excuse to do the wrong thing. If an article says "always do X" and someone does X and the implementation is subtly wrong or insecure, that's an argument to improve the article (which is what I'm suggesting). But if an article says "almost always do X, and be aware of this edge case" and someone gets it wrong by not following instructions, then I don't think the article is at fault. I would personally want my security advice to cover any edge case I could think of, even if only in the footnotes.