Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Three mistakes from Dart/Flutter's weak PRNG

zellic.io

Post reply on HN
Print view View original

41–50 of 93 posts

Re: Three mistakes from Dart/Flutter's weak PRNG

#41

Post by colmmacc »

goodburb wrote: post #12

Why did Proton and SelfPrivacy use Random instead of Random.secure? DTD is local host or over SSH due to the unecrypted websocket. Browsers block unsecure WS over HTTPS. The key generated is for tagging multiple instances per IDE not security. Random is instant and is used for runtime collision prevention and performance especially UI, not uniqueness, PRNG is not truly random anyways. Random.secure has a large overhe…

When I wrote a Random class for use at Amazon, I made SecureRandom (which couldn't be seeded, and was a multi-source DRBG) the default, and you had to intentionally choose InsecureRandom. This is how it has to be, and in this case there should only be Random, and Random.insecure IMO.

Re: Three mistakes from Dart/Flutter's weak PRNG

#42

Post by dgroshev »

klooney wrote: post #10

New 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.

Re: Three mistakes from Dart/Flutter's weak PRNG

#44

Post by tptacek »

shwaj wrote: post #39
sdenton4 wrote: post #36

Earlier quoted context omitted.

Seems like a lot of grief could be avoided if the default was the secure rng... If the insecure one is faster or something, call it random.weak() or something.

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.

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.

Re: Three mistakes from Dart/Flutter's weak PRNG

#45

Post by tptacek »

matthewdgreen wrote: post #29
tptacek wrote: post #21

This is weird, since it reads as a critique of the insecure random number generator in a language that has a secure random number generator. What does it mean for the insecure random number generator to be insecure? That's the point: it's the one you use when security doesn't matter, because you need speed or determinism.

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…

That may be, but having the default generator be non-cryptographic has been the conventional design choice in languages since the dawn of time. I would get the willies seeing security-sensitive code using "Random()" even if you told me in your language "Random()" was a CSPRNG.

Re: Three mistakes from Dart/Flutter's weak PRNG

#46

Post by swatcoder »

matthewdgreen wrote: post #29
tptacek wrote: post #21

This is weird, since it reads as a critique of the insecure random number generator in a language that has a secure random number generator. What does it mean for the insecure random number generator to be insecure? That's the point: it's the one you use when security doesn't matter, because you need speed or determinism.

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 done naively. It's entirely unreasonable that someone writing a `uuid` implementation that's meant to be a cryptographically secure library for use by application developers wouldn't anticipate that their standard library would offer both and would prioritize the PRNG as its basic and most accessible generator.

On #4: It's very rare that an application developer needs direct access to a cryptographically secure random number generator, especially because of that trade consensus that security-sensitive applications deserve expert care. In contrast, application developers are building test data pools, shuffling arrays, adding noise to signals, adding surprise to gameplay, writing and running reproducible tests, etc every day and naive use of a cryptographically secure random number generator in those contexts is easily paralyzing and catastrophic. The overhead can be order of magnitude in measure (which matters quite a lot in typical highly-repetitive/looped usage), and in some implementations it can introduce non-deterministic and potentially indefinite blocks on execution. And because they specifically can't be made deterministic by design, they significantly frustrate debug and test efforts that benefit from reproducibility. They're an essential tool in modern standard libraries, when they're needed in unusual cases, but are not suitable for naive everyday use at all.

Re: Three mistakes from Dart/Flutter's weak PRNG

#47

Post by SAI_Peregrinus »

dgroshev wrote: post #42
klooney wrote: post #10

New 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.

In context I read PRNGs as being compared to CSPRNGs. CSPRNGs should be the default.

Re: Three mistakes from Dart/Flutter's weak PRNG

#49

Post by benatkin »

mjw1007 wrote: post #34
tobyjsullivan wrote: post #14

Earlier quoted context omitted.

sane defaults is always the goal. The only problem is people can't seem to agree on what behaviour is "sane".

So don't have a default. Have securerandom() and insecurerandom() and make the programmer choose. That has the advantage of avoiding problems in a generation's time: if most platforms moved to random() being secure, it would be excusable if young programmers started assuming that would be the case on older platform too.

It’s already implied by the presence of secure_random and it isn’t insecure when it’s being used for the appropriate use case.

Re: Three mistakes from Dart/Flutter's weak PRNG

#50

Post by swatcoder »

tptacek wrote: post #44
shwaj wrote: post #39

Earlier quoted context omitted.

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.

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 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.)

Post reply on HN