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

[fjarri]

Bumping this issue before the 0.6 release.

A recent use case where I hit it - tried to implement a custom curve, and in elliptic_curve::Field the random() method takes rng: impl RngCore (not sure why it's not &mut impl, but that's an orthogonal issue), so I can't just use Uint::random_mod() in it.

[tarcieri]

We can remove the bound