Replace rand with rand_core+rand_os #222

newpavlov · 2019-01-05T11:32:52Z

You don't have to depend on the whole rand, instead rand_core and rand_os can be used.

hdevalence · 2019-01-09T19:23:40Z

What's the benefit of depending on rand_core+rand_os over rand?

Also, is it possible for us to make this change without breaking compatibility? Since the rand trait is part of our public API, I'm not sure we can do this without bumping the major version (which we're planning to do at the next time the rand crate is updated, but hopefully not beforehand)...

newpavlov · 2019-01-09T20:43:01Z

rand_core and rand_os are much smaller crates, which were introduced in part specifically for crates like this one. In addition to being more lightweight, using those crates will make it easier to review the whole dependency tree of your crates. Also API surface is significantly smaller (especially comparing rand_core vs rand), so they will have breaking changes much less often.

I think this PR is backwards compatible, as Rng is an extension trait of RngCore. And IIUC OsRng is an inner implementation detail, so it does not matter from where it comes. Essentially this PR just removes wrapper layer, as rand currently uses those crates and just re-exports/extends them.

tarcieri · 2019-01-10T00:08:49Z

What's the benefit of depending on rand_core+rand_os over rand

See rust-random/rand#648. The rand crate presently pulls in a small zoo of subcrates including non-cryptographically-secure RNGs as well as “90s crypto” RNGs

hdevalence · 2019-02-14T22:53:18Z

Thanks! This should be included in 1.1.0-pre.0, published as a prerelease to test that generalizing the trait bound doesn't cause problems.

See discussion at #232 , copied below: `1.1` changed the trait bounds for `RistrettoPoint::random` and `Scalar::random`, see #222 and #219. These changes have two benefits: * they unlink us from the `rand` crate and make us depend only on `rand_core`; * they allow passing both owned and borrowed RNGs. The change was not supposed to be a breaking change, since the new bounds are strictly more general than the old ones (as every `RngCore` is an `Rng` and every `&mut RngCore` is an `RngCore`), so the new bound is satisfied in every situation where the old bound applied. The `1.1.0-pre.0` version didn't cause problems on the crates I tested it on, but there was an unexpected problem: https://github.com/interstellar/slingshot/blob/ce71c93a9a29ac3b4f69ce71feb987bd64d6c4ec/spacesuit/src/value.rs#L160-L161 broke, since it took a borrow as input and used it twice. So there was slight breakage. One option is to revert the changes (probably just the ones from #219) and release 1.1.3; another would be to fix up `slingshot` and leave the new bound.

Bumps the `ed25519` crate to the v2.0.0-pre.0 prerelease. This version notably uses the `signature` crate's v2 API: RustCrypto/traits#1141

newpavlov added 2 commits January 5, 2019 14:27

replace rand with rand_core+rand_os

d6ca36f

enable rand_core/std

4e47303

newpavlov mentioned this pull request Jan 25, 2019

Could rand changes slow down and simplify the API before making new versions? rust-random/rand#704

Closed

hdevalence changed the base branch from master to develop February 14, 2019 20:19

hdevalence merged commit 4e47303 into dalek-cryptography:develop Feb 14, 2019

hdevalence mentioned this pull request Feb 15, 2019

Trait bounds for random functions in 1.1 #232

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Replace rand with rand_core+rand_os #222

Replace rand with rand_core+rand_os #222

newpavlov commented Jan 5, 2019

hdevalence commented Jan 9, 2019

newpavlov commented Jan 9, 2019 •

edited

tarcieri commented Jan 10, 2019 •

edited

hdevalence commented Feb 14, 2019

Replace rand with rand_core+rand_os #222

Replace rand with rand_core+rand_os #222

Conversation

newpavlov commented Jan 5, 2019

hdevalence commented Jan 9, 2019

newpavlov commented Jan 9, 2019 • edited

tarcieri commented Jan 10, 2019 • edited

hdevalence commented Feb 14, 2019

newpavlov commented Jan 9, 2019 •

edited

tarcieri commented Jan 10, 2019 •

edited