Move thread RNG into a separate crate

[newpavlov]

This was previously discussed in #716 and recently raised in #1514.

The main disadvantage of moving thread RNG into its own crates is that users of rand (with default crate features) will have one additional dependency in their dependency tree. On the other hand, ThreadRng can be now used without the rest of rand (e.g. in cryptographic applications). It also results in simpler configuration flags and thread RNG code, since we don't need to deal with the generality of ReseedingRng.

If ReseedingRng is not used in practice (cursory search on GitHub shows mostly vendored rand code), we probably can remove it completely or move into a separate crate.

[dhardy]

Do we want this? I'm still not convinced.

If we do:

• The thread-rng name is not consistent with rand_core etc. Probably should be rand_thread_rng.
• We switched to using explicit features (#1473)
• rand::rng, rand::random etc. need their cfg updated

[newpavlov]

Probably should be rand_thread_rng

How about rand_trng?

[newpavlov]

This PR is mostly ready for review. I will work on docs and readme after it's decided that we will move forward with it.

Do we want this?

I do. :) My main motivation is to be able to use and recommend rand's ThreadRng for uses in cryptographic applications.

[dhardy]

My main motivation is to be able to use and recommend rand's ThreadRng for uses in cryptographic applications.

You can already. And if you're talking about the disclaimer, it applies to this just as much as it does to rand.

[newpavlov]

I can not fully recommend it now because it pulls the whole rand, which is not a small dependency. Everything else except ThreadRng does not have any uses in this context as was mentioned in #1514.

[dhardy]

How about rand_trng?

https://en.wikipedia.org/w/index.php?title=TRNG&redirect=no

[dhardy]

@newpavlov you were the only proponent in #716 while several people were against, and I haven't seen any change there.

[newpavlov]

@vks @tarcieri
WDYT?

[tarcieri]

Having ThreadRng in the rand crate and having it marked as CryptoRng seems somewhat at odds with #1514.

I guess the actual wording in the changes in #1514 is perhaps not as strong as "rand is not a crypto library":

Rand is not: [...] A cryptography library. Rand provides functionality for generating unpredictable random data (potentially applicable depending on requirements) but does not provide high-level cryptography functionality.

I would argue a CSRNG is high-level cryptographic functionality. It is not uncommon for cryptography libraries to suggest the use of thread_rng in end user-facing documentation for the purpose of creating cryptographic secrets including keys.

[dhardy]

My POV is that #1514 is mostly a disclaimer: rand is a community project which cannot provide binding guarantees. Meanwhile, rand has basically always tried to provide a fast and unpredictable randomness source, though IIUC the original motivation had less emphasis on absolute security and more on avoiding a DoS attack through hash keys.