The future of `ThreadRng`

[dhardy]

Can we have one generator to do it all (excepting reproducibility)? ThreadRng attempts to achieve this:

• It's fairly fast
• It only requires 320 bytes + overhead (Rc and thread_local) per thread
• It's unpredictable
• It has periodic reseeding

Put another way, there are reasons that this is sub-optimal:

• SmallRng is significantly faster (very roughly double the performance) and much smaller (32 bytes) while being good enough for many uses
• ThreadRng does not currently have forward secrecy. We could tack this on for approx 10-25% performance overhead.

Plan

ThreadRng has quite a few users, so I do not believe we should just abandon it. Instead, I propose:

• Re-add ReseedingRng not as a generic wrapper but as a concrete struct over ChaCha12 with periodic reseeding and fast erasure.
• Add StrongRng (name?) as a handle to a Mutex<ReseedingRng> in static memory (feature-gated, default off).
• Add SmallThreadRng as a thread-local SmallRng and maybe rand::fast_rng() to access it (feature-gated, default off).
• If possible, #[deprecate] the existing ThreadRng and methods after adding replacements before the next breaking release.

Note: the fast-erasure (forward secrecy) addition requires breaking changes to rand_core. The rest should be possible to add in a patch release.

Note: this is very much a tentative plan. Feedback welcome!

[LiosK]

As for SmallThreadRng, let mut rng: rand::rngs::SmallRng = rand::make_rng(); generally looks sufficient to me because the memory footprint is minimal, and the initialization is fast if ThreadRng is already initialized. rand::fast_rng() returning an initialized SmallRng would be handy to omit type annotations and performance-favorable if it pulls seeds from getrandom directly to skip initializing ThreadRng when not done yet. I do not really see the benefit of sharing a SmallRng state within a thread.

[LiosK]

As for fast erasure, the natural approach seems to be publishing the FastErasureCore (name?) and replacing the current ThreadRng's type Core = chacha20::ChaChaCore<chacha20::R12, chacha20::variants::Legacy>; with it without deprecating the existing ThreadRng. Whether to retire the existing ThreadRng feels like a separate question, tied more to whether it should stay thread-local or move to being process-wide. Either way, exposing the ThreadRng-ish internals separately would be great for users who want to re-implement whichever mode isn't provided by default, which is the motivation behind #1750.