[xoroshiro]

As someone who first learned how to program by implementing PRNGs but never really digging deeper into it, I found this post very interesting to read. I do have an idea about some (small portion) of the things behind it, but I have no background in cryptography.

Looking at the other posts, it seems like most PRNGs are fine for non-cryptographic applications, but what are other ways to make PRNG's though? Everything I've learned (mostly simple stuff; Linear Congruential, Midsquare, etc.) seem to need to store a state to work, because otherwise, wouldn't you just output the same thing over and over again? I know there's stuff like /dev/random (though I'm unsure how that works), but that doesn't seem like a good idea for getting a lot of numbers.

[andrewla]

Professor O'Neill (mentioned in the article) has written a PRNG [1]. The jury is still out on how powerful it is in general. There continue to be fights between what it means to be random for cryptographic purposes vs. numerical analysis purposes.

That said, the PDF on that site that serves as a writeup for PCG contains a nice discussion of the links between the size of the state held and the strength of the algorithm, including a discussion of the state of the art for crypto- and non-crypto- PRNGs.

[1] http://www.pcg-random.org/

[tptacek]

There is in fact no real debate about what's required for an RNG to be suitable for security purpose. The standard for security is cryptographic. To design a new secure RNG, you effectively need to design a new cryptographic primitive (most likely, a new native stream cipher).

There may indeed be some debate about the requirements for non-security numerical analysis applications.

Most development platforms should be defaulting to secure random number generators, and most developers should be reaching for secure random number generators as their default choice. Neither PCG nor xorshiro128 are examples of these.

[fpgaminer]

> Most development platforms should be defaulting to secure random number generators, and most developers should be reaching for secure random number generators as their default choice.

I was curious about this statement. So I did some research.

This page (http://vigna.di.unimi.it/xorshift/) indicates that xoroshiro128+ generates 64-bits in 0.81ns on a modern 3.6GHz CPU.

If I'm reading this page correctly (https://bench.cr.yp.to/results-stream.html) ChaCha20 gets about 0.8 cycles per byte these days on modern CPUs.

Running the math we get 9.88 GB/s for Xoroshiro128+ and 5.14 GB/s for ChaCha20 (assuming a 3.6GHz modern CPU for both).

Actually a _lot_ closer than I thought. It never occurred to me that a CSPRNG could compete, performance wise, with a non-CS PRNG.

I'm sure there's variation here. Sometimes CSPRNGs will have re-keying cycles, and probably most implementations aren't going to use the highly optimized version we see in the benchmark. I'm not sure if the Xoroshiro128+ benchmark I found used a version utilizing all the SIMD functionality of the CPU (like the ChaCha20 benchmark does). I'm also not sure if Xoroshiro128+ is the fastest PRNG or not.

But I have to say, if these numbers are accurate ... you're just plain right. There's no reason to default to a non-CSPRNG. CSPRNG is a safer default, and in the rare scenario that a developer needs more performance they can go seek out a specific PRNG for their needs.

[tptacek]

I'm not even saying you should never use an LCG. Go ahead, if you're absolutely sure you need it, in the very specific places that you actually need it. But not only are CSPRNGs performance competitive on modern machines, but most places that need RNGs aren't in the performance hot-spot anyways.