Use OsRng for thread_rng.

[tomprince]

Fixes#78.

[bluss]

I think we need to examine this for performance impact.

[alexcrichton]

Yes unfortunately when we've done this in the past the performance has been unacceptably slow afterwards, unfortunately. @tomprince did you find evidence to the contrary, however?

[dhardy]

@alexcrichton what precisely has unacceptable performance? This change has been argued for quite a bit in the crate evaluationthread.

If we're talking about specific applications, we may still want to use OsRng by default and let those applications decide. If we're talking about usage by the standard library, e.g. to randomise hash functions, then how big a deal is this?

[alexcrichton]

@dhardy historically the thread_rng performance has affected HashMap::new in the standard library, which IIRC was the main motivation for caching it. This dates way far back but the tl;dr is that if getting system randomness is slower than periodically reseeding a user-space RNG, so if you have a core piece of functionality that relies on getting random numbers a lot then using the OsRng will slow you down a lot.

Now that's mainly something to deal with the standard library, and it's probably the case no matter what that we'll never switch HashMap over to the OS RNG by default. That being said, the decision there in the standard library doesn't necessarily imply a correct decision for this crate! We'd just want to explicitly document that if you need a lot of random numbers really quickly you're in a "niche" case and provide a path to a different RNG.

[arthurprs]

Can we not do that? No matter the origins, this will lead to catastrophic performance in some programs as people use thread_rng liberally as an almost secure but still fast rng.

[burdges]

I'd propose this approach :

Abstract ThreadRng as some new type ReseedingRng<Out: Rng+SeedableRng,Src> that instantiates an Out and periodically reseeds it from Src where Src: Rng or preferably Src: CryptoRng. Initializing ReseedingRng might fail when Src: CryptoRng, so ReseedingRng::new(src: Src) -> Result<ReseedingRng,Src::Error> or whatever. After Initialization ReseedingRng should handle any errors produced by Src by running Out longer. I donno if Src blocking requires any cleverness.

Replace IsaacWordRng in StdRng with some cryptographic CSPRNG, maybe some fast Keccak or ChaCha variant, but permit different platforms to use different PRNGs. Now set ThreadRng to be a wrapper around ReseedingRng<StdRng,OsRng> that employs the thread_local! trick. Add a try_thread_rng() function because the ReseedingRng::new might fail, but make thread_rng()unwraps it.

Add an FastThreadRng that wraps roughly ReseedingRng<IsaacWordRng,ThreadRng> or whatever for people who only want extremely fast random numbers.

I think this provides a ThreadRng that runs reasonably fast, reasonably securely, does not panic, and rarely blocks for the common use case of seeding data structures like HashMap, but keeps it simple to optimize for specific use cases.

[dhardy]

@burdges given that the current thread_rngalready reseeds from OsRng and panics on error, I'm not sure your design achieves much else, other than using a different PRNG, and try_thread_rng (extremely unlikely ever to error).

[dhardy]

Closing (see reason in #78).