Let rand::rng() use OsRng unless thread_rng is enabled?

[dhardy]

ThreadRng adds some thread-local memory. In case not all users want this, we could add a thread_rng feature flag (probably default-enabled).

Where the thread_rng feature is not enabled, rand::rngs::ThreadRng would not be available. rand::rng() would instead use OsRng (assuming that getrandom is available), thus thread_rng would mostly be a performance boost (at the cost of extra code and thread-local memory).

[newpavlov]

Personally, I would be somewhat surprised by such behavior, so I lean slightly against it. Though, it's not a strong opinion, so I would be fine with such change.

[pinkforest]

FWIW IMO All features should be deterministic & additive where it should not change behavior of any surface under the hood.

This can cause issues if someone is expecting explicit rng and is given another instead when there is another transient crate can change the behavior for another given there is no bifurcation of features.

We went through quite an exercise here between features and cfg's:

• Simplifying backend selection dalek-cryptography/curve25519-dalek#414
• https://github.com/dalek-cryptography/curve25519-dalek/tree/main/curve25519-dalek#manual-backend-override

I personally would like explicit selections and nothing else - or at least deterministic overides - given it only takes one single transient dependency to change the global behaviour - given the features do not bifurcate between the crates.

Also with say cfg(rng= "..") the top-level binary can override it over default - I have impl override too which drives the storage for my io_uring completions which can switch at will on impl based on decision of the top level binary which also typically owns the environment.

[dhardy]

In this case, the behaviour change would be mostly unobservable which is the only reason I would consider it. Nevertheless, it is possibly observable through side-effects:

• Faster performance
• Extra state usage (without memory protection)

getrandom has a similar getrandom_backend cfg. We could add a cfg like rand_rng=ThreadRng / rand_rng=OsRng, but likely the default should be ThreadRng (at least, this is quite a lot faster than OsRng on Linux; we could also select based on platform).

The only purpose I think would be to reduce code and state size where some code in a dependency uses rand::rng() but the RNG is not used enough to be a performance issue.

[pinkforest]

FIPS causes potentially a complication here given it dictates that cryptography library must choose explicitly which Rng it uses.

I hit this problem when trying to motivate rustls to adopt CryptoRng via it's CryptoProvider API.

However on another side composable cryptography primitives don't care about the environment unlike monolithic libraries like OpenSSL rustls etc. which make an opinion which one to use.

@tarcieri might have informed take on this.