RustCrypto
Is there a reason `random()` and `random_mod()` require `CryptoRng`?
I would argue that it's the user's decision whether they want a cryptographically safe RNG used or not; there can be applications which do not require that restriction, and CryptoRng is just a marker trait and does not provide any additional functionality.
Just generally, per the crypto-bigint name, this crate assumes cryptographic applications of all operations.
What's the use case where e.g. ChaCha8Rng is insufficient?
Perhaps it is sufficient, my point was that it is a misuse of the marker trait. CryptoRng requirement is justified when the operation is supposed to be cryptographically safe, like SecretKey::random() or something; there is nothing inherently cryptographic about just generating a random integer. As for the library name, I personally think of it as more of a "fixed-size-bigint", and perhaps it's the API that should influence the name and not the other way around.
there is nothing inherently cryptographic about just generating a random integer
When are you generating a random integer with this library where it’s a nonsecret value?
I suppose there are a handful of applications (e.g. batch verification)
As for the library name, I personally think of it as more of a "fixed-size-bigint"
It’s definitely more than just that. It’s intended to have a misuse resistant API which includes constant-time-by-default behavior.
If there’s a good real-world use case for nonsecret integers we can consider removing the bound, but IMO the main use case for a random integer with this library is generating cryptographic secrets
When are you generating a random integer with this library where it’s a nonsecret value?
One example is testing. Or a challenge value for some ZK proof (although you can argue that you'd still want a CryptoRng there). Or some Monte-Carlo algorithm running in a large integer space (who knows). In general, I'm just not excluding a possibility that someone at some point might want a non-cryptographic random, and we shouldn't put artificial restrictions on it.
It’s definitely more than just that. It’s intended to have a misuse resistant API which includes constant-time-by-default behavior.
Fair enough, although it is also a bit of an annoyance to cast Choice to boolean explicitly (but at least that is contained within methods and does not affect the API).