Most simulations, games, everything that isn't generating cryptography does not need security in it's random.
For most domains secure random is a niche, not universally applicable.
For most domains secure random is a niche, not universally applicable.
* It's not fast enough. * It has patterns that can be seen if you are using it to, for instance, generate 2d noise.
So for games you'd typically use, say, the Mersenne Twister [1], which is faster (amortized) and is distributed evenly across 623 dimensions. [2]
It's not cryptographic, but it's far better for games. If you're not going to have a crypto default random, better to at least have a really good and really fast one.
[1] https://en.wikipedia.org/wiki/Mersenne_twister
[2] http://www.math.sci.hiroshima-u.ac.jp/m-mat/MT/ARTICLES/mt.p...
So given that Mersenne Twister sucks in pretty much every possible way other than having a catchy name, likely the sole source of its continued popularity, its probably not a good choice for replacing some "default" random number generator with something better.
Could you share at least one example of such a generator?
Most of these aspects are trivial to improve on, but having "better randomness" on top is quite the bar.
https://nullprogram.com/blog/2017/09/21/
I don't think better randomness than MT is as high a bar as you make it out to be, both links above also briefly mention statistical shortcomings of MT.
Mersenne Twister is not secure, and it isn’t a very good RNG even for insecure uses.
I used to be able to play about a dozen Pac-Man levels knowing exactly where every ghost was going to go and every bonus that was going to appear. And I wasn’t a very good player.
Pac-Man would have been a less fun game for many people if it used crypto grade random.
The vast majority of people reuse low-entropy passwords, figuring out what password generator someone used would be a much higher bar than figuring out passwords, and just knowing the insecure generator wouldnt reduce the entropy by that much.
Actually, a password generator on GitHub that generates the password that is literally just seconds-since-1970 would still be a good generator for almost all use cases.
I think if there's any gap it would be wrong roll your own password generator at all and you only use ones authored by security experts: just using SecureRandom instead of Random isn't going to somehow magically guarantee you didn't mess up another way and write a low-entropy password generator.
:facepalm:
Seriously.
Here are the last several times I saw random() used.
Seeding a neural network for a Coursera course. Not only do you need to call random() a bunch of times, but the ability to set a seed and get deterministic results makes grading of the results massively easier.
Creating simulation data used for integration tests on a piece of software.
Picking a few random numbers that I used in an explanation of an answer.
Of course the plural of anecdote is not data. However in my corner of the world it is very rare to need cryptographically secure anything. And when I do, I know better than to code it myself. But it is common to need a lot of cheap numbers in a hurry.
Only 7 rounds of chacha are cryptographically broken, so chacha20 has excessive security margin. Using 8 rounds of that everywhere you use random today (and not a CSPRING) should be a no-brainer, I guess.
On hardware with AESNI (like all x86 for the last 10 years), a reduced round AES-CTR should be very fast and also string enough for the cases when you don't need a CSPRING. Full AES-128 outputs 4.7GB/sec on my laptop, recent chips have better AES throughput.
The parent comment said "Most simulations, games ...". Most. Not all. I think it's pretty obvious that Poker would not be included a statement of "Most".
The real litmus test is the question of "What happens if a malicious actor is able to predict the random numbers?"
If you're using it to generate Monte Carlo hand playouts to generate % outcomes to assist such a game, then you most certainly want an extremely fast generator. Only slightly more complex than a LCG is the PCG class (based on a PCG, and it's just as simple and fast in most cases as a LCG). And you'll need such Monte Carlo simulations to detect cheating, among other things.
So even for an online poker game you need to know what you're doing. Neither type of RNG will solve all the issues you need.
So yes, at the base a simple LCG would suffice if you know how to use it.