How secure is to seed PRNGs with the sequences from CSPRNG?

Question

Background: Implementing online casino, I would like to use a number of PRNGs with high throughput, like MersenneTwisterFast. I know it is not cryptographically strong, but quite unpredictable when used with a proper seed value (is it?), let's say, AES-CTR.

Question: How secure would be the PRNG, initialized by a generated value from another PRNG, that was initialized by a cryptographically strong seed (taken from /dev/random per se)?

As to my mind, good PRNG algorithm can't be predicted when seed is unknown (and which is securely random), so the seeds for the second level PRNGs are also securely random, and their sequence is also unpredictable. Am I right?

UPDATE: I think this article is highly related to my question: /dev/urandom is actually a properly seeded CSPRNG seeding other CSPRNGs.

Answer 1

First of all there is nothing wrong with seeding a CSPRNG with the output from another CSPRNG, as far as the source has been properly seeded in the first place.

As others have stated, Mersenne Twister is not a cryptographic algorithm, so you should not use it for a casino.

/dev/random and /dev/urandom is built using a solid CSPRNG on pretty much every modern UNIX, save for any possible incidents with improper seed you can use either for anything, and in many systems neither will ever block once they have been properly seeded.

The exception is Linux where an old home-grown slurry function is used in place of modern cryptography. /dev/random blocks because that theoretically under certain assumptions makes the output cryptographically secure, even if the slurry function is not of cryptographic strength. And /dev/urandom throws that away because then one can actually get some work done.

Linux random has not been truly broken, it is just in the zone of some partial exploits being possible under controlled conditions: https://www.schneier.com/blog/archives/2013/10/insecurities_in.html

Combined with the difficulties of only getting incomplete and permuted outputs I don't think it is likely that an attacker could exploit Linux /dev/urandom through your site. But why risk it? You can safely use /dev/random to generate a seed for a proper CSPRNG. As long as you don't otherwise expose output from /dev/random it doesn't matter if the slurry function is cryptographically strong or not, an isolated piece of the output is still sufficiently unpredictable.

Answer 2

This certainly looks like premature optimization.

A fast CSPRNG on a modern Intel CPU will output between 500 MB and 2 GB per second. Even if you have a quite random game which requires 100 random bytes per second per player (I can't think of a typical casino game anywhere near that) a single core will be able to generate random numbers for ten million simultaneous users.

Other operations, such as database access, the webserver etc. will be much more expensive than generating good random numbers. I recommend seeding a good stream cipher like ChaCha or AES-CTR from the system random generator instead of downgrading to an insecure PRNG. It's possible that the system random generator by itself is already fast enough.

Check eBACS for benchmarks of stream ciphers.

---

Using non crypto PRNGs like Mersenne-Twister for an online casino is a really bad idea. These generators don't aim an unpredictability. They only try to look random enough that their flaws don't cause any deviation from actual random data that breaks the using code by accident.

For example if you ran a scientific simulation with MT and with perfect random numbers and it gave different results, that'd be considered a flaw in MT. But it doesn't try to resist somebody who deliberately tries to predict the output.

As @CL. already said, MT is easily predictable once you've seen a few hundred outputs. Compare that with a CSPRNG which will be indistinguishable for true random numbers even after observing petabytes of data.

Answer 3

Wikipedia says:

The algorithm in its native form is not suitable for cryptography (ie it's not a CSPRNG). Observing a sufficient number of iterations (624 in the case of MT19937, since this is the size of the state vector from which future iterations are produced) allows one to predict all future iterations.

In other words, even with a strong seed, you get only a few unpredictable output values. The difference between the Mersenne Twister and a CSPRNG is that the latter stays unpredictable for much longer.

You need to reseed the PRNG regularly. Alternatively, use a CSPRNG in the first place, and concentrate on optimizing that one for speed.