search

rust-random / rand

A Rust library for random number generation.
https://crates.io/crates/rand
Other
1.67k stars 432 forks source link

Move thread RNG into a separate crate #1520

Closed newpavlov closed 1 week ago

newpavlov commented 3 weeks ago

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.

newpavlov commented 3 weeks ago

Probably should be rand_thread_rng

How about rand_trng?

newpavlov commented 3 weeks ago

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 commented 3 weeks ago

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 commented 3 weeks ago

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 commented 2 weeks ago

How about rand_trng?

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

dhardy commented 1 week ago

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

newpavlov commented 1 week ago

@vks @tarcieri WDYT?

tarcieri commented 1 week ago

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 commented 1 week ago

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.