Is there a reason random() and random_mod() require CryptoRng?

[fjarri]

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.

[tarcieri]

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?

[fjarri]

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.

[tarcieri]

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

[fjarri]

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).