5 ms·

It's possible that the secure rng incorporates observed entropy; there might not be enough entropy available when you need it, if secure is made the default and

by shwaj 2y ago

It's possible that the secure rng incorporates observed entropy; there might not be enough entropy available when you need it, if secure is made the default and therefore used unnecessarily.

tptacek 2y ago
No, in this setting, this is not a thing: the secure generator, if it isn't literally just a wrapper around the OS secure RNG (which it ideally is) is seeded from that RNG. Userland code doesn't observe entropy at all; you are in a state of grave sin if your userland program is trying to do that.
- swatcoder 2y ago
  No, they don't mean that that the application would need to be observing entropy on its own. They're acknowledging that cryptographically useful entropy is a limited resource for the system as a whole, and naive exhaustion can either causes starvation, unbounded blocking, or degradation depending on the implementation. Having a casual array shuffle seize up because there's not enough secure entropy available might just be an absurd nuisance in many cases. But having an session key or uuid generator seize up because somebody burnt all the entropy on casual array shuffles can be a real problem for users. (And much worse so if the implementation just silently degrades in quality instead of blocking or failing, as some have done.)
  - loeg 2y ago
    "Useful entropy as a limited resource" is just an incorrect meme that has somehow brainwormed a significant fraction of engineers. Once that secure RNG is seeded, you're golden. Randomness is not depleted. Every mainstream OS is trivially capable of seeding the system secure RNG by the time userspace applications need to consume it. There is no availability / depletion problem for userspace.
    - swatcoder 2y ago
      That's absolutely not true, and some of us have directly experienced what happens when it runs out. There are implementations that will keep producing output without an ongoing and sufficient supply of fresh entropy, but there are also implementations that do not. Generally, those that do keep producing output in those cases are formally weaker. When the supply is treated conscientiously, depletion broadly doesn't matter outside of weird race conditions during system startup. But if everybody naively consumes cryptographically secure randomness for every casual occasion, it becomes a much bigger problem.
      - tptacek 2y ago
        No, it's definitely true. A conventional OS CSPRNG can be effectively modeled as a stream cipher, where the key is a hash of observed entropy. As you encrypt more bytes with a stream cipher, you don't "deplete key". Real CSPRNGs are more complex than this, but that complexity is there to improve things from the baseline of "hash some interrupts and key ChaCha20 with it"; the argument gets weaker on real CSPRNGs, not stronger. The parent comment is correct: entropy depletion is a weird meme. Unfortunately, Linux encoded that meme into its legacy KRNG ("/dev/random"), so lots of people believe it to be real. It is not, and modern userland programs don't use "/dev/random" anyways.
        swatcoder 2y ago
        > Unfortunately, Linux encoded that meme into its legacy KRNG ("/dev/random"), so lots of people believe it to be real. It is not, and modern userland programs don't use "/dev/random" anyways. It's not the only such system, nor has that "legacy KPRN" been eradicated from real-world use. Moreso, I can't understand how someone who seemingly has as much seasoning and experience as yourself can fathom making generalizing claims like "modern userland programs don't X". Application software and the platforms that it runs are insanely more diverse than that, especially now that we live in a world where people just paste in verbatim docker stacks that they read about in some blogspam tutorial written 12 years ago, and countless others are building on frameworks and dependencies that are themselves broken in ways they oughtn't be (like Flutter, in the article). While there exist contexts where cryptographically secure randomness may be treated as inexhaustible, we're decades away from being able to take that for granted across "modern userland programs" and its much safer to have people anticipate the dangers of exhaustion than it is to have them presume its universally inexhaustible.

by shwaj 2y ago

It's possible that the secure rng incorporates observed entropy; there might not be enough entropy available when you need it, if secure is made the default and therefore used unnecessarily.

tptacek 2y ago

No, in this setting, this is not a thing: the secure generator, if it isn't literally just a wrapper around the OS secure RNG (which it ideally is) is seeded from that RNG. Userland code doesn't observe entropy at all; you are in a state of grave sin if your userland program is trying to do that.

swatcoder 2y ago
No, they don't mean that that the application would need to be observing entropy on its own. They're acknowledging that cryptographically useful entropy is a limited resource for the system as a whole, and naive exhaustion can either causes starvation, unbounded blocking, or degradation depending on the implementation. Having a casual array shuffle seize up because there's not enough secure entropy available might just be an absurd nuisance in many cases. But having an session key or uuid generator seize up because somebody burnt all the entropy on casual array shuffles can be a real problem for users. (And much worse so if the implementation just silently degrades in quality instead of blocking or failing, as some have done.)
- loeg 2y ago
  "Useful entropy as a limited resource" is just an incorrect meme that has somehow brainwormed a significant fraction of engineers. Once that secure RNG is seeded, you're golden. Randomness is not depleted. Every mainstream OS is trivially capable of seeding the system secure RNG by the time userspace applications need to consume it. There is no availability / depletion problem for userspace.
  - swatcoder 2y ago
    That's absolutely not true, and some of us have directly experienced what happens when it runs out. There are implementations that will keep producing output without an ongoing and sufficient supply of fresh entropy, but there are also implementations that do not. Generally, those that do keep producing output in those cases are formally weaker. When the supply is treated conscientiously, depletion broadly doesn't matter outside of weird race conditions during system startup. But if everybody naively consumes cryptographically secure randomness for every casual occasion, it becomes a much bigger problem.
    - tptacek 2y ago
      No, it's definitely true. A conventional OS CSPRNG can be effectively modeled as a stream cipher, where the key is a hash of observed entropy. As you encrypt more bytes with a stream cipher, you don't "deplete key". Real CSPRNGs are more complex than this, but that complexity is there to improve things from the baseline of "hash some interrupts and key ChaCha20 with it"; the argument gets weaker on real CSPRNGs, not stronger. The parent comment is correct: entropy depletion is a weird meme. Unfortunately, Linux encoded that meme into its legacy KRNG ("/dev/random"), so lots of people believe it to be real. It is not, and modern userland programs don't use "/dev/random" anyways.
      - swatcoder 2y ago
        > Unfortunately, Linux encoded that meme into its legacy KRNG ("/dev/random"), so lots of people believe it to be real. It is not, and modern userland programs don't use "/dev/random" anyways. It's not the only such system, nor has that "legacy KPRN" been eradicated from real-world use. Moreso, I can't understand how someone who seemingly has as much seasoning and experience as yourself can fathom making generalizing claims like "modern userland programs don't X". Application software and the platforms that it runs are insanely more diverse than that, especially now that we live in a world where people just paste in verbatim docker stacks that they read about in some blogspam tutorial written 12 years ago, and countless others are building on frameworks and dependencies that are themselves broken in ways they oughtn't be (like Flutter, in the article). While there exist contexts where cryptographically secure randomness may be treated as inexhaustible, we're decades away from being able to take that for granted across "modern userland programs" and its much safer to have people anticipate the dangers of exhaustion than it is to have them presume its universally inexhaustible.