For this, I need consequent samples from a PRNG to be really uncorrelated and fast. But there is no adversary relationship, so I don't need cryptographic strength. I just cannot have any spurious correlations between samples, as they might throw off convergence speed or worse, introduce error.

The flaws of an MCG or LCG are easily witnessed, so it's totally fair for someone to go find out if it's possible to do better (i.e. remove obvious patterns, fix low period of low order bits, improve statistical quality) without sacrificing much performance; and indeed perhaps making it faster than a large-state LCG of comparable quality would be.

If you admit that there are any legitimate uses for non-cryptographic PRNGs then I guess a 32 bit MCG (or "42") is just perfect for you (otherwise you'd know what's better and you don't need to ask anyone to define good). You're easy to please.

If you think there are no legitimate use cases for these fast generators at all, then I'm sorry but a lot of people disagree and they will never rewrite their sims, noise generators, world generators, etcetra to use a CSPRNG no matter how much you whine about it.

1. Non-cryptographic RNGs, should they be incorporated in security-critical applications are dangerous. If you insist on manufacturing poisonous chemicals that look appetizing and say “Kool-Aid” on them, kids are going to drink them. And this is your damned fault.

2. Non-cryptographic RNGs should not be evaluated and improved so as to (appear to provide) security properties. Non-invertability is a security property. Anyone who needs this property probably wants something that has been properly evaluated by experts to provide it. This construction has not been, and it is appropriate to assume that against a sufficiently-motivated adversary it will not provide it. Assuming otherwise is stupid and dangerous.

3. People who can use a non-cryptographic RNG but can’t afford the compute of a full cryptographic RNG are a very small subset of all users with very specific computing limitations. If you must target them with something, you should justify your computing speedup.

My proposal is that this type of non-cryptographic RNG should have a name that is not easily confused with safe cryptographic PRNGs. Perhaps “statistical sequence generator”. Moreover, people designing these systems should not be playing with security properties. Do one thing or the other, but not both things badly.

The set of people who need fast statistical (but insecure) sequence generators is small. They know who they are and what they need. Stop littering the school yard with poisonous chemicals that say “Kool Aid” in an effort to reach a few hundred laboratory chemists who are perfectly capable of calling you and ordering exactly the ingredients they know they need.

All I'm saying is that I'm happy the state of art of fast (but insecure) generators is improving and people have better options than cranky old LCGs or Mersenne Twister (ugh!).

I don't know why they brought up non-invertibility. But, at a glance, I see a new RNG that might be at least twice as fast as a comparable variant of PCG while offering similar or better statistical performance. That's exactly the kind of development I like to see.

1. Insecurity needs to be in the name: Make it Insecure<Your RNG Name Here>. This is extremely important. Since the intended use-context is going to be non-security critical, anyway, it's actually good that it states it's insecure. That way you know you're not accidentally using RNG where security properties might cause any bottle-necks. At the same time the misuse resistance of the RNG increases significantly.

2. Make sure this is not default, but something that needs to be imported separately from non-security context, such as module about statistics, simulation etc.

factoring/prime checking algorithms

any type of stimulation (eg for drug dosing/particle stimulation)

sorting algorithms

most graph based algorithms.

in short, many real works problems are best solved by random algorithms, but the randomness can be of fairly low quality without causing problems.

no, crypto IS the niche area. The vast majority of random code in existence has absolutely nothing to do with crypto. It's cryptographic use-cases which should be marked specifically.

See CWE-338 for an enumerated list of these things in the wild.

I found 300+ examples of CVEs with little effort.

Should developers who are writing code that involves cryptography know better? Sure - but they don't. They cut and paste from stackoverflow with horrific results.

but cryptography is just one small use case of RNGs. Grepping through my home for e.g. random_engine, less than 1% seems to be related to crypto use cases, the bulk are being taken by noise generation for various artistic use cases, games, compilers, schedulers, and tests. Stuff like shuffling a playlist, making particles move in random directions, randomness in paint brushes, etc.

If I want to generate a white noise texture for a video game do you think I care more about cryptographically-secureness or the operation not taking 10 seconds for a 4k texture ?