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 Flutter Web in which Random.secure will fail, this isn't exclusive to Dart/Flutter. [1]
NaCL [0] offloads these concerns for developers, especially indie/startup.
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.
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.
Or randomInsecure() and randomCryptographic() to avoid any ambiguity around the word 'weak' for non-security minded programmers[0], and to avoid using the substring 'secure' twice[1] in two very different functions.
[0] In my experience, most of them -- who reads documentation these days...? Or programmers using editors like vim (no slight on vim by the way, don't shoot me!) which (generally) won't alert the programmer to the library options, unless it's been set up with a suggestion/completion/intellisense plugin?
[1] randomSecure() vs randomInsecure(), which can look similar at 3:00am on three hours sleep. Naming the functions explicitly differently makes it patently clear which function is cryptographically safe. Also helps when the interpreter/compiler won't understand the context the function is being called in, therefore can't throw warnings or errors to alert the overtired/overworked programmer that they're using insecure random number generation for crypto.
Big brain idea: Perhaps cryptographically-weak/insecure random number generators should be type incompatible by default, requiring an explicit cast to integer/float? Probably overkill, but definitely wards off mistakes and/or misuses by forcing the developer to type cast out, otherwise the compiler simply refuses, then explains why by fatal error at compile time, or by exception thrown.
But then why not make secure random number generators type incompatible by default? Because we're trying to encourage secure-by-default programming, making it slightly harder (but not onerous) to use the equivalent insecure function over secure one. Create a speed bump to prompt the programmer to think about their code, not a road block.
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.
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.
