The interesting angle here is 2x performance vs pcg64_fast or xoshiro256++, with competitive quality in that space. It’s a simulation PRNG, not a CSPRNG. I agree the introduction to the article is somewhat confused (i.e., mentioning invertibility), but it never claims to be a CSPRNG.

The vast majority of the article is pretty interesting, if you can get past the first couple paragraphs and some typos.

The context is Rust’s SmallRng[1]. The top-level description of that is:

> A small-state, fast non-crypto PRNG

[1]: https://docs.rs/rand/0.8.4/rand/rngs/struct.SmallRng.html

If you want to design a cryptographic RNG that falls between LCGs and PCG in speed, please have a go at it. Meanwhile we'll use our small and fast PRNGs and strive to make them as good as they can possibly be for non-cryptographic uses.

I beg you to define what “good” means in a way that doesn’t imply security properties. And if you must demand security properties, god help you if you designed something that can’t provide them.

Say I want to numerically approximate a high dimensional integral with MC sampling, say in a computational fluid dynamics simulation, or in a ray traced render.

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.

You don't need to define good in an absolute sense to see how one thing can be better than another.

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.

Saving some weight by leaving the airbag out of your car doesn't mean that it going faster is a good thing.

So did PCG or xoroshiro leave the airbag out of MCGs or what? Or are you one of those who pretend that there was never any legitimate use case for any non-cryptographic PRNG?

There are perfectly legitimate use case (in a tiny niche area) for non-cryptographic RNGs - however, three points:

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.

I agree on all three points. I might even agree on the proposed name; not that I care too much.

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.

It's great that insecure fast RNGs are improving, but it's extremely important to be responsible about how they should be promoted.

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.

point 1 is just false. some examples where it's perfectly acceptable to use a bad rng in a safety critical system

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.

He said security-critical not safety-critical. Security-critical implies an adversarial setting.

> There are perfectly legitimate use case (in a tiny niche area) for non-cryptographic RNGs - however, three points:

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.

There's no such thing as "a good thing". There are only goals, security is just a goal among other that not everyone have.

The problem that we have is that a minority of people realize that not all random implementations are actually fit for purpose for cryptographic security.

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.

> Should developers who are writing code that involves cryptography know better?

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 ?