Designing a New PRNG

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

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.

> After some minor optimizing, on my laptop here are benchmarks on filling a 1kb byte array: > > Mwc-256-X-X-A-64 (This algorithm): 100.98 ns

That comes to 10 GB/s. For comparison, I think ChaCha8 implemented with AVX-512 should run at a similar speed. Maybe a bit faster in short-ish, single-threaded benchmarks.

To be clear, there are plenty of caveats in making this comparison: ChaCha8 won't hit that throughput on any output size smaller than 1 KiB. AVX-512 requires a very recent processor. Most library implementations don't include AVX-512 support. Power usage will be high. Downclocking will be an issue, especially with multithreading. Etc. etc.

But in exchange, you get all the security properties.

I think one takeaway here is that the gap between cryptographic and non-cryptographic is smaller than many people think, which argues in favor of secure defaults. (Though to be clear, I don't think OP or anyone in this thread is opposed to secure defaults.) Another takeaway is that a lot of these blockers, like hardware and library support, will continue to improve over time. So if you find that a CSPRNG isn't fast enough for your use case today, make sure to check again in a few years. And of course, as always, it's important to benchmark your specific use case if you're worried about performance.

I think the biggest gains from AES-NI are when you can use the vectorized versions. So random byte generation would benefit, but small integer hashing probably not? (Unless you could arrange to hash a vector of integers at once.) But this isn't something I've tried myself.