5 ms·

This document is very informative for sure, but I don't really think it's dispositive for many of today's use cases for randomness. In fact, I think this docum

by jMyles 8y ago

This document is very informative for sure, but I don't really think it's dispositive for many of today's use cases for randomness. In fact, I think this document is pretty dangerous. I referenced this document here in this stackexchange question, which I think has a good and lively discussion about the real stakes of /dev/urandom today: https://security.stackexchange.com/questions/186086/is-always-use-dev-urandom-still-good-advice-in-an-age-of-containers-and-isola https://security.stackexchange.com/questions/186086/is-alway...

tptacek 8y ago
I don't think you're going to find too many cryptography engineers recommending that you use /dev/random, or, for that matter, the blocking variant of getrandom(2). This might be a live debate on message boards, or on the wrong stack overflow boards --- though Pornin's answer[1] on this question is one of the all-time good Stack Overflow answers --- but among practitioners, this is long settled. [1]: https://security.stackexchange.com/questions/3936/is-a-rand-from-dev-urandom-secure-for-a-login-key/3939 https://security.stackexchange.com/questions/3936/is-a-rand-...
- jMyles 8y ago
  Well, perhaps you have a better answer to my question than forest's answer, to which I awarded the bounty. For my money, I think that's one of the finest and most balanced pieces of writing on this topic available on the internet today. > I don't think you're going to find too many cryptography engineers recommending that you use...the blocking variant of getrandom(2). It depends on what you mean by "the blocking variant". To quote Cory Benfield: > Can we please try to be clear about what kind of blocking we mean? getrandom(flags=0) absolutely can block: that's what the original issue was all about. To ensure it never blocks you need to call getrandom(GRND_NONBLOCK): that's why the flag exists. It may (or may not) surprise you to learn that PEP 524, which uses this (sometimes blocking) variant of getrandom, has been accepted. Here's a discussion of the matter featuring several reputable, kickass security-minded python people discussing the matter and indeed endorsing the sometimes-blocking (flags=0) variant of getrandom: https://bugs.python.org/issue27266 https://bugs.python.org/issue27266 For full transparency: I read your post on this topic before I posted my question and found that, as far as I was able to read, it added nothing new to the public discourse on this topic. It does not seem to overcome the very real and well-sourced concerns raised by forest in his answer to my question. Anyway, I'm not sure what you mean by "the wrong stack overflow boards" - can you tell me which are right and which are wrong? The link which you've provided, which of course I had already read thoroughly, as I pointed out in my question, is not from Stack Overflow, but from Security StackExchange, just like my question. I haven't yet marked an answer correct, so if you actually have something substantive to add that you think is better than forest's answer, it's possible that you can grab the check.
  - tptacek 8y ago
    Regarding that Stack Exchange answer: avoiding the Linux KRNG in favor of alternate RNG's like OpenSSL's is literally the opposite of what cryptographic software security engineers will tell you. For the past decade and a half, virtually all notable cryptographic failures owing to bad randomness came from systems that weren't using the kernel RNG.
    - jMyles 8y ago
      Yeah, as you can see, I pushed back on that. But, as far as I can tell - and I do indeed write with this in mind - the movement to create applications for very fresh, naive installations such as containers or IoT devices, does indeed present a problem for purely-blocking random. My sense is that you and others in the community encouraging blind trust of /dev/urandom need to adjust your language when consulting on this matter in the future. Since I mostly write python, I'm happy that this has been worked out and that python now uses blocking random (via getrandom(flags=0)) in these very rare situations.
      - tptacek 8y ago
        Once again: there is exactly one time in the lifecycle of an entire system when you want a blocking read from the Linux KRNG: when the system is first booting, to ensure it's seeded (FreeBSD is smarter about this and handles that automatically). Apart from that one time, every other read on your system should be from urandom. No, this doesn't need to updated for IoT or "containers" (Linux containers share the KRNG).
        jMyles 8y ago
        > there is exactly one time in the lifecycle of an entire system when you want a blocking read from the Linux KRNG Right. I'm glad to hear you phrasing it this way. And listen: I don't mean to be flamy here, and it's possible that my sense of these things is tainted by our many... colorful discussions here on HN, but the unradom orthodoxy, to which getrandom and python's os.urandom are in part a response, is something for which you are arguably a tiny bit responsible, having actually written "Use urandom. Use urandom. Use urandom. Use urandom. Use urandom. Use urandom" on your blog. That kind of punditry has no place in security engineering. There is a need for a degree of sobriety with these sorts of security considerations. Sometimes edge cases move toward the mainstream, and that's exactly what has happened with this odd little phenomenon of programs being executed much, much earlier in the OS lifecycle in the case of containerization and IoT devices. Yes, some containers are deployed in settings where the host KRNG can be and is used. But not all. And many IoT devices suffer from a sufficiently weak set of entropy sources as to need to block. These are real concerns, as identified by the study I linked from the University of Michigan. The researchers there were able to replicate over 1% of the SSH keys that they found in the wild because the devices that created them had insufficient entropy at the time of the key generation. All I'm saying is: don't treat these sorts of security issues as subject to orthodoxy. Clear thinking and solid engineering are the orders of the day.

by jMyles 8y ago

tptacek 8y ago

I don't think you're going to find too many cryptography engineers recommending that you use /dev/random, or, for that matter, the blocking variant of getrandom(2). This might be a live debate on message boards, or on the wrong stack overflow boards --- though Pornin's answer[1] on this question is one of the all-time good Stack Overflow answers --- but among practitioners, this is long settled. [1]: https://security.stackexchange.com/questions/3936/is-a-rand-from-dev-urandom-secure-for-a-login-key/3939 https://security.stackexchange.com/questions/3936/is-a-rand-...

jMyles 8y ago
Well, perhaps you have a better answer to my question than forest's answer, to which I awarded the bounty. For my money, I think that's one of the finest and most balanced pieces of writing on this topic available on the internet today. > I don't think you're going to find too many cryptography engineers recommending that you use...the blocking variant of getrandom(2). It depends on what you mean by "the blocking variant". To quote Cory Benfield: > Can we please try to be clear about what kind of blocking we mean? getrandom(flags=0) absolutely can block: that's what the original issue was all about. To ensure it never blocks you need to call getrandom(GRND_NONBLOCK): that's why the flag exists. It may (or may not) surprise you to learn that PEP 524, which uses this (sometimes blocking) variant of getrandom, has been accepted. Here's a discussion of the matter featuring several reputable, kickass security-minded python people discussing the matter and indeed endorsing the sometimes-blocking (flags=0) variant of getrandom: https://bugs.python.org/issue27266 https://bugs.python.org/issue27266 For full transparency: I read your post on this topic before I posted my question and found that, as far as I was able to read, it added nothing new to the public discourse on this topic. It does not seem to overcome the very real and well-sourced concerns raised by forest in his answer to my question. Anyway, I'm not sure what you mean by "the wrong stack overflow boards" - can you tell me which are right and which are wrong? The link which you've provided, which of course I had already read thoroughly, as I pointed out in my question, is not from Stack Overflow, but from Security StackExchange, just like my question. I haven't yet marked an answer correct, so if you actually have something substantive to add that you think is better than forest's answer, it's possible that you can grab the check.
- tptacek 8y ago
  Regarding that Stack Exchange answer: avoiding the Linux KRNG in favor of alternate RNG's like OpenSSL's is literally the opposite of what cryptographic software security engineers will tell you. For the past decade and a half, virtually all notable cryptographic failures owing to bad randomness came from systems that weren't using the kernel RNG.
  - jMyles 8y ago
    Yeah, as you can see, I pushed back on that. But, as far as I can tell - and I do indeed write with this in mind - the movement to create applications for very fresh, naive installations such as containers or IoT devices, does indeed present a problem for purely-blocking random. My sense is that you and others in the community encouraging blind trust of /dev/urandom need to adjust your language when consulting on this matter in the future. Since I mostly write python, I'm happy that this has been worked out and that python now uses blocking random (via getrandom(flags=0)) in these very rare situations.
    - tptacek 8y ago
      Once again: there is exactly one time in the lifecycle of an entire system when you want a blocking read from the Linux KRNG: when the system is first booting, to ensure it's seeded (FreeBSD is smarter about this and handles that automatically). Apart from that one time, every other read on your system should be from urandom. No, this doesn't need to updated for IoT or "containers" (Linux containers share the KRNG).
      - jMyles 8y ago
        > there is exactly one time in the lifecycle of an entire system when you want a blocking read from the Linux KRNG Right. I'm glad to hear you phrasing it this way. And listen: I don't mean to be flamy here, and it's possible that my sense of these things is tainted by our many... colorful discussions here on HN, but the unradom orthodoxy, to which getrandom and python's os.urandom are in part a response, is something for which you are arguably a tiny bit responsible, having actually written "Use urandom. Use urandom. Use urandom. Use urandom. Use urandom. Use urandom" on your blog. That kind of punditry has no place in security engineering. There is a need for a degree of sobriety with these sorts of security considerations. Sometimes edge cases move toward the mainstream, and that's exactly what has happened with this odd little phenomenon of programs being executed much, much earlier in the OS lifecycle in the case of containerization and IoT devices. Yes, some containers are deployed in settings where the host KRNG can be and is used. But not all. And many IoT devices suffer from a sufficiently weak set of entropy sources as to need to block. These are real concerns, as identified by the study I linked from the University of Michigan. The researchers there were able to replicate over 1% of the SSH keys that they found in the wild because the devices that created them had insufficient entropy at the time of the key generation. All I'm saying is: don't treat these sorts of security issues as subject to orthodoxy. Clear thinking and solid engineering are the orders of the day.