4 ms·

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

by 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.
  - tptacek 8y ago
    The blog post you're referring to contains exactly the advice I just gave in the preceding comment. I don't see a link to a Michigan study in this thread. If you post it again, I'll be happy to explain why it doesn't say that you should use /dev/random, or a userspace RNG.
    - jMyles 8y ago
      Well, man, that's not the debate. As so often in these conversations, you're running away with the goalposts. If I may advise: these are exactly the antics that are costing you credibility with those of us out here in the field actually building cryptographic systems. Good day.
      - tptacek 8y ago
        I don't understand your objections, like, at all. Every "concession" you think you're extracting is right there, in a blog post I wrote 4 years ago. Those are the goalposts. They haven't moved since 2014. Everything else you have to say just reads like word salad. I should be concerned about container RNGs, but not Linux containers, unless they're the Linux containers that don't share the KRNG? Or the IOT devices where blocking somehow solves the cold-start entropy problem, and at the same time can't be done in the init scripts? Even the Python issue thread you posted --- yes, I read it --- disagrees with you. I have no idea what you're talking about and, candidly, I don't know that you do either. I've written (until now) perhaps 1 word on this thread for every 30 of yours, and I think my comments are straightforward and make obvious points. You respond to each of them with a wall of text. Can I suggest that maybe instead of a grand disagreement, you've instead just done a poor job communicating whatever your concern might be? Regarding that last sentence of yours (er, the one before your "good day"): I am extremely comfortable with who does and doesn't find me credible. Thanks anyways.
        jMyles 8y ago
        Well look, the problem is solved, at least for people using python. So there's really no need on my end to discuss it further. As for community communication and understanding: I really don't think there's any good reason that we all have to lock horns all the time. I do think that you'll find more joy in these sorts of discussions if you can be less caustic and more deliberative. It's no more difficult to be nice than it is to be mean; give it a try. And if you get to the edge of your knowledge (and, it seems to me that you do, fairly frequently, which is great - you are obviously interested in a wide variety of societal topics just like I am), don't just keep marching. Stop and acknowledge your short-comings and recognize that there are others who might have had some original / compelling / correct thoughts on these matters also. Again, this is no skin off my nose. My current project is python, and python has wisely decided to stop using urandom in favor of getrandom(flags=0), so this is a non-issue. But won't it be nice if the next non-issue can be handled with greater ease and less toxicity?

by jMyles 8y ago

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.
- tptacek 8y ago
  The blog post you're referring to contains exactly the advice I just gave in the preceding comment. I don't see a link to a Michigan study in this thread. If you post it again, I'll be happy to explain why it doesn't say that you should use /dev/random, or a userspace RNG.
  - jMyles 8y ago
    Well, man, that's not the debate. As so often in these conversations, you're running away with the goalposts. If I may advise: these are exactly the antics that are costing you credibility with those of us out here in the field actually building cryptographic systems. Good day.
    - tptacek 8y ago
      I don't understand your objections, like, at all. Every "concession" you think you're extracting is right there, in a blog post I wrote 4 years ago. Those are the goalposts. They haven't moved since 2014. Everything else you have to say just reads like word salad. I should be concerned about container RNGs, but not Linux containers, unless they're the Linux containers that don't share the KRNG? Or the IOT devices where blocking somehow solves the cold-start entropy problem, and at the same time can't be done in the init scripts? Even the Python issue thread you posted --- yes, I read it --- disagrees with you. I have no idea what you're talking about and, candidly, I don't know that you do either. I've written (until now) perhaps 1 word on this thread for every 30 of yours, and I think my comments are straightforward and make obvious points. You respond to each of them with a wall of text. Can I suggest that maybe instead of a grand disagreement, you've instead just done a poor job communicating whatever your concern might be? Regarding that last sentence of yours (er, the one before your "good day"): I am extremely comfortable with who does and doesn't find me credible. Thanks anyways.
      - jMyles 8y ago
        Well look, the problem is solved, at least for people using python. So there's really no need on my end to discuss it further. As for community communication and understanding: I really don't think there's any good reason that we all have to lock horns all the time. I do think that you'll find more joy in these sorts of discussions if you can be less caustic and more deliberative. It's no more difficult to be nice than it is to be mean; give it a try. And if you get to the edge of your knowledge (and, it seems to me that you do, fairly frequently, which is great - you are obviously interested in a wide variety of societal topics just like I am), don't just keep marching. Stop and acknowledge your short-comings and recognize that there are others who might have had some original / compelling / correct thoughts on these matters also. Again, this is no skin off my nose. My current project is python, and python has wisely decided to stop using urandom in favor of getrandom(flags=0), so this is a non-issue. But won't it be nice if the next non-issue can be handled with greater ease and less toxicity?