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

31–40 of 93 posts

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

#31

Post by ivanbakel »

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…

Well the article still has a point in that the insecure PRNG is neutered for seemingly no reason, contrary to developer expectations.

But I think we should, as language developers and users, be well beyond the point of pushing out and accepting insecure defaults with a little documentation disclaimer - especially if even the Dart developers themselves can't catch misuse of their own insecure APIs in widespread tools.

At the end of the day, we don't live in a computing world where true randomness is that resource-intensive anymore, and user-facing applications should basically always be relying on it. Non-randomness should really be the opt-in, when developers can actually justify that the performance penalty is a problem. Otherwise, I don't need library authors prematurely optimising my programs at the cost of security.

(There is a similar related discussion to have about the pervasiveness of floating points in programming languages when most applications would be better served by a more expensive, but more precise, numerical representation - since they rarely do that much calculation.)

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

#32

Post by zamadatix »

goodburb wrote: post #26
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.

Arguably, rolling your own crypto (in this case AES which is customizable) requires a very careful implementation, beyond RNG. Since dart/flutter is multi platform, using Random.secure for animation has it's own performance issues with interfacing host entropy RNG. The majority of Dart/Flutter users are creating UI apps. Few browsers with security policies and OS combination does not allow access to the entropy with…

Rolling your own security requires nothing more than gumption and willingness to deploy. That doesn't mean it's good security but it means people will do it whether they know all the golden rules. After all, rolling insecure security requires missing 1 small thing in a haystack of thousands and it doesn't matter you reviewed the language defaults when OS version blah blah from vendor xyz defaults to something insecure "because you should have checked the defaults". The same goes towards "this library does these kinds of things so there is no value in languages having secure defaults too" type thinking, they aren't convincing arguments for what security posture of other things should or shouldn't be.

I'm more a fan of "make the defaults as secure as you can reasonably expect to get away with for each step of the way". It'll never be as secure as everyone wants but if you but up against "it's as secure as people would want to put up with by default" then things are at least at a good starting point for others to build from. The hard part is finding out what people are willing to put up with and which tradeoffs are worth it. That default random number generators "only" go at GB/s on most PCs because they produce really good random numbers is probably an easy tradeoff though.

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

#33

Post by cryptonym »

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.

Or avoid ambiguity and remove the default random().

- randomWeak() - randomSecure()

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

#34

Post by mjw1007 »

tobyjsullivan wrote: post #14
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.

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.

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

#35

Post by BoorishBears »

mightyham wrote: post #24

[flagged]

The title had me quietly think to myself "Dart was the mistake".

So many stack/enviornments are leveling up their languages: ObjC => Swift, Java => Kotlin, Erlang => Elixr, C++ => Rust, Javascript => Typescript

Dart feels like one of the befores, not the afters.

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

#36

Post by sdenton4 »

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.

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.

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

#37

Post by throwaway032023 »

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, Flutter is what Dart is known for and it’s, imho, important for their to be primary customer to drive evolution of language.

I don’t do JavaScript development but anytime I bump into it it’s a cluster with regards to tooling (maybe this has changed in the past 3 years). Dart comes ootb with tooling that is a cohesive experience. The technology is impressive and I think it’s filling a niche.

Dart reminds me of Python 20 years ago. Python shipped with IDLE, glued platform (win32com), corba, java, etc features together.

Dart is doing similar stuff but first class interop from the supplier (Google/dart team) for the platforms (js/wasm, mobile, desktop). It is pretty damn amazing and ambitious (maybe too ambitious?). And pub/package system is nice - dart is statically compiled and Google is one of the main innovators in software supply chain security - I think there is real possibility of it being orders of magnitude more secure than python/javascript. (This is not the case currently)

I guess I see it as a “I can stay in this world and do most of what I need”. Are there sharp edges? Yes. But the tooling and the community can resolve this fairly quickly. I don’t need to jump between abuncha languages with tooling disparaties.

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

#38

Post by throwaway032023 »

BoorishBears wrote: post #35
mightyham wrote: post #24

[flagged]

The title had me quietly think to myself "Dart was the mistake". So many stack/enviornments are leveling up their languages: ObjC => Swift, Java => Kotlin, Erlang => Elixr, C++ => Rust, Javascript => Typescript Dart feels like one of the befores, not the afters.

Feels is the key to that statement. :-) It’s these “feels” that got USA to its 2024 election outcome.

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

#39

Post by shwaj »

sdenton4 wrote: post #36
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.

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.

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

#40

Post by tedunangst »

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…

Wait. Developers consciously chose to use this random because they believed it had a 64 bit seed? That's still wrong. It's irrelevant that it was truncated to only 32 bits.
Post reply on HN