Skip to content
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

Fix predictability statements #17

Merged
merged 2 commits into from
Nov 13, 2019

Conversation

vks
Copy link
Contributor

@vks vks commented Nov 8, 2019

Also recommend xoshiro256++ over xoshiro256**.

It does not make much sense to rate the predictability of non-CSRNGs.

Fixes #905.
They are very similar, but the ++ variant works better with SIMD.
@vks
Copy link
Contributor Author

vks commented Nov 8, 2019

Fixes rust-random/rand#905.

@dhardy
Copy link
Member

dhardy commented Nov 8, 2019

As far as I understand, the only reason to recommend Xoshiro256++ over ** is for the vectorisation, which this implementation doesn't provide (and would have to be a distinct generator). So I don't think changing the recommendation here makes sense, especially since the ** variant is supposedly stronger. @vigna?

@vigna
Copy link

vigna commented Nov 8, 2019

There is no absolute "better" because, for example, xoshiro256++ has much higher linear complexity. In the original paper I was not able to prove enough equidistribution for the ++ scrambler—my idea was to obtain the maximum minus one, like for the + scrambler, but the proof eluded me. In the last version, I was able to come up with a new idea and at that point the ++ scrambler was included, and I started to promote the ++ scrambler vs. the ** scrambler for a number of reasons.

From a testing viewpoint, I cannot measure any difference. The ++ scrambler should be faster (no multiplications) but on different architectures results are different (e.g., hardware people love ++). Theoretically, xoshiro256++ is 3-dimensionally equidistributed, whereas xoshiro256** is 4-dimensionally equidistributed (the maximum possible), but as you notice in your book this actually means that you can prove that xoshiro256** will fail a collision test for 256-bit blocks after about 2^128 outputs. This is entirely academic, of course, as there's no way till the end of times to enumerate so many values, but makes you think whether maximum equidistribution is actually a good idea.

So, since you have already implemented it my answer would be yes, suggest as first choice xoshiro256++ (and I hope not to be proved wrong, this is always a risky business...).

@vks
Copy link
Contributor Author

vks commented Nov 8, 2019

As far as I understand, the only reason to recommend Xoshiro256++ over ** is for the vectorisation, which this implementation doesn't provide (and would have to be a distinct generator).

We have optional SIMD support in Rand, for which it might matter. (Not sure about this, I never used it.)

@dhardy dhardy merged commit 97fb54e into rust-random:master Nov 13, 2019
@vks vks deleted the fix-predictability-statements branch November 13, 2019 12:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants