PRNGs are insecure by design, why does this article frame the problem as the implementation being insecure? Applications shouldn’t use PRNGs if they need a true random source to begin with.
Three mistakes from Dart/Flutter's weak PRNG
51–60 of 93 posts
Re: Three mistakes from Dart/Flutter's weak PRNG
#52Earlier quoted context omitted.
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.
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 ju…
"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.
Re: Three mistakes from Dart/Flutter's weak PRNG
#53New languages should make sure the default random() is cryptographically secure, and hide PRNGs behind weakrandom() or repeatablerandom() or something. Safe and slow defaults are better than fast and unsafe.
There is nothing wrong with PRNGs, they are perfectly cryptographically secure when used correctly. In fact, AES-CTR is just XORing the plaintext with a pseudo-random generator (AES'd counter + initialiser). The problem is bad and misused PRNGs.
GP is using "PRNG" to mean "the subset of PRNGs that are not CSPRNGs."
Re: Three mistakes from Dart/Flutter's weak PRNG
#54Earlier quoted context omitted.
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 ju…
"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.
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.
Re: Three mistakes from Dart/Flutter's weak PRNG
#55Earlier quoted context omitted.
"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.
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 ma…
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.
Re: Three mistakes from Dart/Flutter's weak PRNG
#56[deleted]
Re: Three mistakes from Dart/Flutter's weak PRNG
#57Earlier quoted context omitted.
With any question like this, the path to an answer follows three intermediate questions: 1. Was there a security problem that resulted from the use of this insecure generator? 2. Were the developers who encountered this problem completely unreasonable and in the wrong, or were they simply non-(security)-experts who developed software that happened to have a security vulnerability? 3. If the latter, did the language/t…
I think most very experienced engineers would strongly disagree with you on (2) and would laugh at the usage characterization you make in (4). On #2: The difference between a PRNG and a cryptographically secure random number generator is foundational knowledge for software engineers, and there's (finally) a strong trade consensus that writing security-sensitive code has a higher bar of preparation and shouldn't be do…
The person you're responding to is pretty familiar with the space you're commenting on, for whatever it's worth to you to know.
Re: Three mistakes from Dart/Flutter's weak PRNG
#58Earlier quoted context omitted.
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 ma…
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…
> 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.
Re: Three mistakes from Dart/Flutter's weak PRNG
#59PRNGs are insecure by design, why does this article frame the problem as the implementation being insecure? Applications shouldn’t use PRNGs if they need a true random source to begin with.
The only true random sources in the universe are quantum. But it's not practical or performant to hook your workload up to a raw quantum measurement like the spin of a fundamental particle, or radioactive decay.
Instead we take sources that are still believed to be statistically random and influenced by underlying quantum randomness. E.g. RF interference, clock phasing, or an avalanche amplifier that are measures of entropy that is considered to be random to the same extent as say the ideal gas laws. But even those measures can still be imperfect; a probe might have a bias or manufacturing error that shows up later than QC.
To cope with this, we have PRNG designs that can use mixed sources in ways that will provably debias any such errors from a single source, and remain secure. All modern RNGs use these kind of PRNGs or DRBG/NRBG designs as a last stage. Far from being insecure, they are what give us more confidence in the overall system.
Re: Three mistakes from Dart/Flutter's weak PRNG
#60Earlier quoted context omitted.
I think most very experienced engineers would strongly disagree with you on (2) and would laugh at the usage characterization you make in (4). On #2: The difference between a PRNG and a cryptographically secure random number generator is foundational knowledge for software engineers, and there's (finally) a strong trade consensus that writing security-sensitive code has a higher bar of preparation and shouldn't be do…
The person you're responding to is pretty familiar with the space you're commenting on, for whatever it's worth to you to know.
Hah! Thanks for bringing that to my attention. :)