Update rand

[vks]

No description provided.

[hdevalence]

Because the rand crate is part of our public API, and 0.6 -> 0.7 is a breaking change, we can't make this update without releasing a new major version of curve25519-dalek, and we have no plans to do that in the short- to medium- term (say, the next 6 months).

When we eventually release a 2.0.0 version of curve25519-dalek, we will consider changing the version of the rand crate we use, but for now we're sticking with the version we have.

[hdevalence]

See also #262

[Silur]

The reason why so many duplicates for this issue/pr exist is that since no cryptographic rust code exists without an explicit dependency to rand, your policy is literally forcing all users of the library to use an outdated version.

[vks]

@hdevalence What is the motivation for supporting userspace CSPRNGs? You could get rid of the dependency on rand by using the getrandom crate directly, which is similar to what ring is doing.

[burdges]

Any more complex protocols to specify some test vectors by pulling randomness from some stream cipher like ChaCha with a specified seed, so getrandom should probably not be use directly by protocol crates.

[hdevalence]

@vks There are lots of reasons to support userspace CSPRNGs, such as the reasons @burdges mentioned, or the reasons I described on this page.

The bigger design principle is separation of concerns (apparently not a design principle for Ring, in this and other ways). The functionality of an elliptic curve library should be focused on elliptic curve operations, not on providing an RNG. These are orthogonal problems and they should be implemented orthogonally, which is why this API is designed to accept an arbitrary RNG implementation.

@Silur Thanks for the input, but nobody is "literally forcing" anybody to do anything.

[burdges]

If I understand, rand_core 0.4 to 0.5 aka rand 0.6 to 0.7 occurred largely due to adding SeedableRng::from_entropy, which calls getrandom directly. You could not simply let OsRng be a wrapper around getrandom and use SeedableRng::from_rng(OsRng)? Ok well..

[burdges]

I think rand_core v0.5 looks like nonsense rust-random/rand#854 so yeah maybe everyone should skip rand 0.7 until this gets sorted out.

[burdges]

I've no clue about rand 0.6 -> 0.7 but at least rand_core 0.4 -> 0.5 adding SeedableRng::from_entropy should probably not be considered a breaking change. I suppose this crate depends upon rand not rand_core though. Ugh.