# Is it OK to reseed a Deterministic Random Bit Generator from itself?

I want a deterministic PRNG for simulation purposes, and I don't want to have to worry about spurious correlations like those the DMCT is designed to protect the Mersenne Twister against. So even though I don't care about cryptographically secure random numbers, a cryptographically secure Deterministic Random Bit Generator seems like the way to go.

For this purpose, I am thinking of using pycrypto's Crypto.Random.Fortuna.FortunaGenerator. It only allows $2^{16}$ blocks of pseudorandom data before reseeding because it uses an AES stream in counter mode. Since I care only about its resemblance to uniform independent draws and not about the entropy which would secure it from cryptographic attack, is there any harm in seeding the generator from its own output?

• You will need an initial seed at some point... Also, for simulation purposes I would recommend using the fastest RNG that satisfies your requirements (probably not a CSRNG). – Aleph Mar 2 '16 at 17:25
• This question might also get an interesting (and probably different) answer on Computational Science. – Mike Ounsworth Mar 2 '16 at 18:55
• If you don't care about security you may just not reseed the PRG after $2^{16}$ blocks. – kludg Mar 2 '16 at 19:28
• The simple, logical, tried and tested way to generate lots of randomness for simulation purposes is: for each simulation, use a fast CSPRNG with a seed unique to this simulation, that you keep track of (allowing a repeat). That seed can be random; incremental; the date/time..; or derived from one of the later two and a key. If the CSPRNG is the computational bottleneck of a simulation, typically either 1) the CSPRNG is way overkill; 2) it's poorly coded (e.g. in an interpreted language); 3) or/and the simulation could be replaced by an ounce of math from a good course on stats. – fgrieu Mar 3 '16 at 7:39