Which Rngs need reseeding, if any?

[8573]

It is documented that the Rng returned by thread_rng will periodically reseed itself. Do the other Rngs need to be periodically reseeded in dependent code, or will they also reseed themselves, or do they not need reseeding at all?

[pitdicker]

Good question.

We have had several discussions around reseeding. Basically it is never necessary or a solution. If the concern is security, reseeding is not necessary because a good CSPRNG can produce a just about infinite stream of random numbers once initialized. And for simple PRNG's if the period is too small, reseeding is not a solution because after a reseed you will just end up somewhere else in the already too small period.

Why does tread_rng reseed itself periodically? It does not use a proven CSPRNG yet, but it frequently reseeds an ISAAC PRNG. While there is no known attack against ISAAC, it's security is also not formally proven (and probably also never going to happen). I think it is safe to assume there is no attack that can operate on the tiny window between reseeds.

Another reason is historical: thread_rng was supposed to be a faster alternative to OsRng with similar security. And the OS keeps collecting entropy and injecting it into it's internal PRNG. So tread_rng imitates that.

Finally reseeding can be seen as some form of 'security in depth'. Even if in the future there is found a cryptographic weakness in the used CSPRNG, occasionally reseeding should make exploiting it much more difficult or even impossible.

How reseeding in rand works now is that we have PRNG implementations that just provide the core algorithm, and a separate ReseedingRng wrapper that they can be combined with. To answer your question: they do not need reseeding, but we have an option available to do so.

Note that we have several changes in the works around reseeding:

• we are going to make reseeding less prominent by removing it from the SeedableRng trait;
• if things work out ReseedingRng is going to wrap the core algorithm of CSPRNG's to make the performance impact almost zero (while now it something like 30~50%);
• thread_rng is going to use an actual CSPRNG;
• thread_rng should not reseed frequently but just occasionally.

[dhardy]

@8573 any further questions or parts of the documentation you think should be improved? If there are action items we can work on them, otherwise I'll close this issue.

[pitdicker]

I think I will copy some of the above to the documentation for ReseedingRng.

[8573]

Thanks for the explanation. I don't think I have further questions; if you have the time for it, the improvement to the documentation that I would suggest would be to explicitly note that the need for reseeding implied by thread_rng's documentation doesn't apply to the other Rngs (if I understood correctly and that is indeed the case).

[dhardy]

I improved the doc: d82bad1