Three mistakes from Dart/Flutter's weak PRNG

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.

Rust does this.

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

For a PRNG you should probably be using something like a good hash function that passes the SMHasher3 tests to generate it (which funnily enough I just posted now after a long overdue enhancement: https://news.ycombinator.com/item?id=42409577).

Alternately develop something that at least passes all the Dieharder tests.

There are many good options for a variety of requirements.

Maybe the following perspective is missing some key context here (?) but when I skimmed the code for this, I was stunned that such a low quality algorithm was used by Zellic (some kind of high end cyber genius cabal, it seems) and in cryptocurrency purposes. I'm rarely harsh on projects here but bloody hell that's utterly stupid. Especially when there are so many good options.

No, it's totally overblown. As discussed in the comments on that issue as an example, the failure was in whoever wrote Flutter's `uuid` feature.

It's simply incorrect for them to have naively used a PRNG there, regardless of whether it has a static seed or not. They should have used Random.secure all along, and anyone working in a cryptographically sensitive module, like `uuid` should be familiar enough with the distinction to make the right choice.

There's nothing especially harmful about having that static seed and there are even some diagnostic and debugging advantages offered by it. Shuffling the seed on init is a generous convenience for people who want to make sure there's more per-run variety in their randomness without setting a seed themselves, but (when using in a non-secure context) it quickly doesn't matter since anything but toy programs tend to have enough complexity, branching, and data-dependency that the sequence of invocations isn't consistent anyway.

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/toolkit strongly encourage developers to use an insecure generator -- e.g., by making an insecure generator the default or "simpler" option (such as Random() instead of Random.secure()).

4. Is there some broad and general understanding that this toolkit is only intended for applications, such as monte-carlo testing or graphics rendering, where performance at the cost of security will always be the correct solution?

Given that the authors are able to offer several examples of real security vulnerabilities caused by developers using an insecure PRG, I'm going to read the answers as (1) Yes, (2) not unreasonable, (3) Yes, (4) I don't think so.

The decision to make insecure RNGs the default creates security vulnerabilities. This is demonstrable and has broad and unpredictable effects, given that developers are not security experts. The decision to make secure RNGs the default (easier path) has exactly one implication, which is that a small number of specialized applications will have slightly worse performance, performance that can easily be improved by making a conscious decision to remove the secure RNG.