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

11–20 of 93 posts

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

#12

Post by goodburb »

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 overhead accessing OS entropy and isn't always supported. [1]

Go 'math/rand', python 'Random', C# 'Random' to name a few are also not unique or safe for crypto.

Their secure equivalents: Go 'crypto/rand', Python 'SystemRandom', C# 'RNGCryptoServiceProvider'.

This isn't a Dart or Flutter issue [0]:

"A generator of random bool, int, or double values.

The default implementation supplies a stream of pseudo-random bits that are not suitable for cryptographic purposes.

Use the Random.secure constructor for cryptographic purposes."

[0] https://api.dart.dev/dart-math/Random-class.html [1] https://api.dart.dev/dart-math/Random/Random.secure.html

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

#13

Post by rumori »

PRNG = pseudo-random number generator. I think it would have made sense to spell it out in the first sentence and go with the acronym from then on. Like the author does it with multiply-with-carry (MWC). Makes it more readable and consistent throughout the article.

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

#14

Post by tobyjsullivan »

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

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

#15

Post by orr94 »

nickcw wrote: post #4
robin_reala wrote: post #3

I’m not a Dart fan so maybe I’m biased, but wow this (from the article) is a failure on many levels: https://github.com/dart-lang/sdk/issues/56609

From the code in the issue // TODO: Make this actually random static int _initialSeed() => 0xCAFEBABEDEADBEEF; Oops.

That TODO was committed on 2022-02-16 and wasn't fixed until 2024-09-2. That is... a long time for something that critical.

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

#16

Post by abenga »

nickcw wrote: post #4
robin_reala wrote: post #3

I’m not a Dart fan so maybe I’m biased, but wow this (from the article) is a failure on many levels: https://github.com/dart-lang/sdk/issues/56609

From the code in the issue // TODO: Make this actually random static int _initialSeed() => 0xCAFEBABEDEADBEEF; Oops.

Oops indeed. I like using FIXME for such to make it stand out it's a deficiency that should be fixed asap (usually before merging the change altogether) compared to TODOs that are improvements that can be implemented in a more leisurely fashion.

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

#19

Post by swatcoder »

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 reproducibility limitations of -- secure randonmness when that's not what they need. It's both useful and traditional for standard libraries to either include both forms, or to leave the secure form for other libraries to contribute.

If an application uses the wrong supply of randomness for their needs, that's an application error. And if developers writing security-sensitive code don't know to think anticipate this distinction and avoid the error, then that sounds like there was a project management error in assigning them such a sensitive task.

Post reply on HN