-
Notifications
You must be signed in to change notification settings - Fork 432
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use ChaCha20 in StdRng and feature-gate SmallRng #792
Conversation
Note: I need to fix the tests, which shouldn't be using |
Aren't features additive? I'm dubious about this plan, but if doing it then using only one feature sounds best. I'd think |
Maybe it's better to be more conservative and provide no option between ChaCha12 and ChaCha20? We can suggest in the documentation to use ChaCha12 directly via |
I am not sure if I like this approach, to me it looks like features misuse. Also shouldn't be newtype pattern used here instead of type alias? For example it's possible to write code like this: fn foo(rng: &mut StdRng) { .. }
foo(&mut ChaCha12Rng::from_entropy()); So changing |
I believe this is the case for |
@burdges yes, but disabling a default feature which is used from multiple sub-crates is hard. @vks the point is to allow tuning of @newpavlov I agree, this is feature mis-use. It would be much better if Cargo allowed We do use the newtype pattern? The aliases are strictly for internal use. Of course, |
Ah, yes, you are right. |
I've no idea what StdRng gets used for. It's not used by ThreadRng, which sounds like the unique place. |
Me neither actually. By the time you've filtered out the duplicates and re-definitions... not so many. In contrast So I guess we drop the configuration idea. Probably we should keep Shall we feature-gate |
I think this is a good idea. It will presumably also make it easier to gauge how much |
StdRnd
and configuration features
Rebased. First and last commits are the same, the middle two are new. I think this covers all suggestions. |
The Miri test is failing:
So I guess for Miri's sake, we should use a simpler RNG in our tests (perhaps PCG like in |
The WASM/Emscripten test fails with a linker error. It is not very decipherable, but running the following (prerequisites are in the
@kazcw is there some way we can make If this also allows us to work around the Miri issue ( Note: of course we could just |
rand_jitter/src/error.rs
Outdated
// Timer check is already quite permissive of failures so we don't | ||
// expect false-positive failures, i.e. any error is irrecoverable. | ||
#[cfg(feature = "std")] { | ||
Error::with_cause(ErrorKind::Unavailable, "timer jitter failed basic quality tests", err) | ||
Error::with_cause(ErrorKind::Unavailable, "timer jitter failed basic quality tests", _err) | ||
} | ||
#[cfg(not(feature = "std"))] { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe it's better to add let _ = err;
here instead of renaming err
to _err
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does it matter?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would prefer it, because I think it reflects intent better, but ultimately it's not important and I'm fine with either way.
@dhardy I don't know off the top of my head what problem emscripten would have with the portable fallback; it all safe code and works on x86/arm/mips. I'll dig into it probably this weekend. |
If I understood correctly, the plan for this PR is the following:
|
Done. The result is a little hacky, but not too bad. It seems there is no problem with depending on the same thing twice within Cargo.toml. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
rand_distr/tests/uniformity.rs
probably should be updated to not use SmallRng
. Otherwise this looks very good!
Right. Switched to |
My opinion here is that the Miri and WASM failures lie outside the scope of the Rand project, and unless we get help addressing these issues, we should not block the 0.7 release on switching |
I released ppv-lite86 0.2.4, so Miri should pass now. |
Thanks @kazcw, you've been very helpful on this. The WASM failure is about a |
Wow, that's interesting. I created a project that just has a function that invokes u128::rotate_right: If I use But if I build it with rotate_left is also broken, but other u128 ops that I tried work. I don't see how this could be anything but a rustc bug, but why does it only break when built with cargo-web? Filed a bug in cargo-web: koute/cargo-web#193 |
Ok, as of ppv-lite86 0.2.5 I don't rotate any u128s. |
I think this can be merged after we
Then all tests should pass. |
… test We want a value-stable RNG to avoid future vector changes which means using something outside of Rand. Pcg32 is a good fit and is easy to embed if that is ever necessary.
seq::test::test_slice_choose updated with better bounds
Not ideal but seems to work; see: rust-lang/cargo#6945
This is considered an ugly hack, but easier than making the new ChaChaRng compatible with Emscripten. Potentially support for Emscripten will be dropped in the future, if it doesn't get support for u128.
Rebased. Reordered commits and tidied up (squashed) some. Adjusted the |
Where do you propose we do this? We don't have a direct dependency. I don't think it's worth bothering with minimum patch version requirements personally, especially where this only affects minor platforms (WASM in this case). |
Fair enough, this should be fine then. |
The tests passed! 🎉 |
Following #789, we change the
StdRng
algorithm. Additionally,stdrng_strong
andstdrng_fast
feature flagsThoughts @kazcw @vks @newpavlov @burdges? I don't exactly like adding configurability here, and maybe it's not worth doing so for a 50% performance boost. ChaCha12 is used by Google's Adiantum (repo) and appears to have a good security margin, though doesn't appear to have wide usage (probably because ChaCha20 is already fast enough for most).
I do think we should only use generators with a good level of trust, thus have not added ChaCha8 as an option (even though it remains unbroken).
Note: the names
stdrng_conservative
andstdrng_good
may be more appropriate, but are likely also confusing.