Description
Currently we don't have thread_rng() available without the std feature.
The primary reason is that we do not have thread-local storage available to keep the state of ThreadRng in. And a second problem is that we don't have OsRng or JitterRng available, so we have no way to seed it.
The reason to make ThreadRng available, even when the performance is sub-par, is that it makes it easier to port libraries to the no_std environment. API's do not always allow for the state of an RNG to be passed around.
A few possible solutions:
- In some cases we may not have thread-local storage available to keep the
ThreadRngin. - Using a hardware RNG, like RDRAND on x86, or other on-chip devices may be a solution.
- With WebAssembly we have a fast cryptograpic 'system' RNG, that may be a good alternative to use directly instead of our own PRNG (exposed via
OsRng). - On tiny hardware using some RNG based on differences between timers may be a good and fast.
Two problems to keep in mind:
- We now guarantee the RNG is of cryptographic quality, i.e. unpredictable. When we use some other RNG (pluggable?), can we keep similar promises?
- Wo don't want some arbitrary dependency to silently override the
ThreadRngto something else.
One solution could be to let ThreadRng fall back to EntropyRng when we have no thread-local storage, meaning no std feature. Or maybe even put the fallback behind a feature flag itself.
Next EntropyRng could be changed to not only use OsRng, and JitterRng as a fallback, but to have a secondary fallback if both are not available. The secondary fallback should then somehow be pluggable, so some external generator like RDRAND can be used.