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

71–80 of 93 posts

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

#71

Post by mightyham »

throwaway032023 wrote: post #37
mightyham wrote: post #24

[flagged]

> It's clear just from using the language that it was designed as a more "serious" Javascript replacement What is your usage of Dart? JavaScript is a target platform for Dart. The Dart interop story is the point. It’s a cohesive glue language. First class interop with JavaScript, Java/Kotlin, C++ and Swift/ObjC. Community interop supports go and rust. Maybe I am confused. We are comparing Dart to what again? Yes, Flu…

For clarity, I'll admit that I do not have industry experience with Dart. I have built a medium sized mobile application with it, and have spent a pretty good deal of time digging into Flutter's architecture and reading it's source code.

If you are debating the statement I made: "It's clear just from using the language that it was designed as a more 'serious' Javascript replacement", it's simply a fact that the Dart language was originally designed to be a Javascript alternative in Chrome, and the language clearly takes a lot of inspiration for Java and C++ which are widely used at Google.

> Maybe I am confused. We are comparing Dart to what again?

I'm comparing it to other garbage collected languages. I don't think Dart really even has a backend story, but in that case I would compare it to Go, any JVM language, and Javascript/Typescript. For frontend applications I'm comparing it to Javascript/Typescript.

Maybe you could tell me what about my comment is confusing, but I'll rephase it and add some more context. From everything I've read, the Dart team at Google is small an insular. Google has a nasty reputation of cutting niche products and has been doing lots of layoffs in recent years. Even though Dart has an good UI library, there are numerous attractive alternatives that are more familiar and popular. Putting all that information together, I would not choose to use Dart for basically any new project.

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

#72

Post by gwbas1c »

gwbas1c wrote: post #23
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.

Rust does this. IMO, it's not worth it: It makes working with random numbers very problematic when working on cryptographic use cases.

Too late to edit: I meant non-cryptographic use cases

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

#73

Post by gwbas1c »

ivanbakel wrote: post #28
gwbas1c wrote: post #23

Earlier quoted context omitted.

Rust does this. IMO, it's not worth it: It makes working with random numbers very problematic when working on cryptographic use cases.

Could you clarify this? What problems would you run into just from having the default RNG be secure?

Performance / getting a seed

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

#74

Post by loeg »

tptacek wrote: post #67
swatcoder wrote: post #63

Earlier quoted context omitted.

"It was an issue in Linux for a while, but isn't in recent kernels" is not really sufficient grounds for acting like it's not an issue. A language designer or library developer, especially, generally can't assert that their code will only run on the most robust, modern, popular systems currently available. They need to work defensively, anticipating the issues that they may plausibly encounter -- especially where tho…

No, there's really no space for wriggling here. You use getrandom() or, in the worst case, /dev/urandom, and this kernel nit goes away. It was never the case that the LRNG was "exhaustible"; there was only a broken interface to it.

Personally, I forgot that Linux only fixed /dev/random in 2020 in kernel 5.6. That's not that long ago in terms of enterprise / LTS kernels. I'm sure this has been a surprising pain point for end-users for a long time, and perhaps still is in some environments.

(Yes, I know, you have shared a workaround for a long time prior: https://sockpuppet.org/blog/2014/02/25/safely-generate-rando... . But that sort of presumes a clued-in user.)

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

#75

Post by ironhaven »

gwbas1c wrote: post #73
ivanbakel wrote: post #28

Earlier quoted context omitted.

Could you clarify this? What problems would you run into just from having the default RNG be secure?

Performance / getting a seed

Why is the default thread_rng from the rand crate a dealbreaker for rust? There are other rngs to choose from rand like `smallrng` that is a small fast unspecified default prng if you don't know what you want even for a prng. If the worst case 300 microseconds of the reseeding ChaCha12 default rng is measurable, then it is your job to make a decision about your random number generator.

I don't think rng seeding has anything to do with the algorithm you choose? Seeding from the os rng is usually what you want even for a prng. If you want to use use the current time there is a `seed_from_u64` if you want.

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

#76

Post by orf »

swatcoder wrote: post #19
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…

Yeah, it's a weird critique. The author acknowledges early on that `Random.secure` is there to provide randomness where it needs to be secure, but then spends the entire article fretting over how the other source of randomness isn't. But it's not supposed to be! Applications have plenty of reason for cheap, stable, or otherwise controlled forms of randomness and shouldn't have to pay the penalty for -- or face the re…

It’s not random, that’s the point. If you neuter it so much that it’s only useful for a specific use case then make sure it’s named something relevant and specific related to that use case!

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

#77

Post by SSNLF »

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…

I'd say it's because Proton does not employ actual cryptographers or security engineers. They do seem to have a lot of marketing folk, interns, and particle physicists, allegedly.

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

#78

Post by IshKebab »

benatkin wrote: post #49
mjw1007 wrote: post #34

Earlier quoted context omitted.

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.

It's only implied by secure_random if you know secure_random exists. This is a very very very well known thing. The default MUST be secure.

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

#79

Post by matthewdgreen »

swatcoder wrote: post #65
matthewdgreen wrote: post #64

Earlier quoted context omitted.

I think the following statements are entirely compatible with one another: * Most software developers (let's say, 95-99%+) are smart enough to avoid using insecure PRGs in their code. * The remaining 1-5% have contributed to a litany of avoidable security disasters, nonetheless. * The impact of these disasters has been vastly outsized when you compare it to the number of bad developers. * If every developer understoo…

> this type of incident used to pop up on HN every month or so, and yet in the past few years they've become incredibly rare. And do you know why that is? It is not because developers got better. It's almost entirely due to the fact that development frameworks (particularly JS in browsers) have made a multi-year and systematic effort to reduce the availability of insecure default PRGs to bad developers. The result is…

Just to beat the horse to death, I want to be clear that what I'm asking for isn't much:

1. The default random() call/library should always produce exactly what it says -- real, secure, unpredictable (pseudo)random numbers.

2. For statistical and non-security applications it's perfectly fine to have a generator of the form random.insecureAndFast(). Or call it whatever you want, the important thing is that the developer make a tiny amount of conscious effort in the process of using it.

3. If you require reproducible and insecure generator, just use approach (2) above and add a seeding function. (Honestly I don't like anything that uses global state, but I don't care as long as it's labeled insecure.)

4. If you require reproducible and secure random numbers, then you have a slightly challenging problem on your hands that is way beyond the scope of this discussion.

For people who don't require secure randomness, the total "cost" of my proposal is something like an extra dozen characters added to your code in a few places -- and if that's too much work for you, then you probably aren't writing reproducible tests or spending a lot of time optimizing for speed. On the flipside, you might save someone a few million dollars when their crappy Bitcoin library uses a dependency that relies on random().

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

#80

Post by tptacek »

loeg wrote: post #74
tptacek wrote: post #67

Earlier quoted context omitted.

No, there's really no space for wriggling here. You use getrandom() or, in the worst case, /dev/urandom, and this kernel nit goes away. It was never the case that the LRNG was "exhaustible"; there was only a broken interface to it.

Personally, I forgot that Linux only fixed /dev/random in 2020 in kernel 5.6. That's not that long ago in terms of enterprise / LTS kernels. I'm sure this has been a surprising pain point for end-users for a long time, and perhaps still is in some environments. (Yes, I know, you have shared a workaround for a long time prior: https://sockpuppet.org/blog/2014/02/25/safely-generate-rando... . But that sort of presumes…

Right. But the context here is whether languages can make the (very big) decision to default to a CSPRNG, in which case: you make that decision once, for all your users, and when you do, you don't use "/dev/random".
Post reply on HN