1
$\begingroup$

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?

Improve this question
$\endgroup$
4
  • $\begingroup$ 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). $\endgroup$
    – Aleph
    Mar 2 '16 at 17:25
  • $\begingroup$ This question might also get an interesting (and probably different) answer on Computational Science. $\endgroup$
    – Mike Ounsworth
    Mar 2 '16 at 18:55
  • 2
    $\begingroup$ If you don't care about security you may just not reseed the PRG after $2^{16}$ blocks. $\endgroup$
    – kludg
    Mar 2 '16 at 19:28
  • 1
    $\begingroup$ 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. $\endgroup$
    – fgrieu ♦
    Mar 3 '16 at 7:39
2
$\begingroup$

No, in your situation (where you don't care about security), there isn't any harm in seeding the generator from its own output (or, for that matter, reseeding it by just incrementing the original seed, and resubmitting it).

The chief issue would be if you would fall into a loop (that is, you start repeating outputs); if the seed you generate is 128 bits or more, that is highly improbable for any reasonable number of reseeding.

Now, as you are well aware, a CSRNG is overkill for your purpose; however the question is whether it is cheap overkill. If the total amount of time your simulation takes is short, or if the bulk of your computation is in things other than generating the random string (and so taking a bit longer in the generation part doesn't significantly slow you down), then it is cheap overkill.

Improve this answer
$\endgroup$
2
  • $\begingroup$ These guys claim that PRNGs based on cryptographic primitives can actually be blazingly fast compared to, say, an MT. thesalmons.org/john/random123/papers/random123sc11.pdf $\endgroup$
    – Alex Coventry
    Mar 2 '16 at 20:30
  • 2
    $\begingroup$ @AlexCoventry If you CPU as AES-NI and you use AES-CTR and prng or if your CPU has fast SIMD instructions and you use ChaCha20 as prng you should be able to produce output at about 1 CPU cycle per byte. The round reduced variant ChaCha8 goes down 0.6 CPU cycles per byte. See eBACS: Stream ciphers for detailed benchmarks. That's pretty fast, but some non secure PRNGs are still much faster than that. $\endgroup$
    – CodesInChaos
    Mar 2 '16 at 20:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.