-
Notifications
You must be signed in to change notification settings - Fork 75
BREAKING: Make random_mod platform-independent #1010
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
Conversation
Succeeds: ```sh cargo test # --target=x86_64-unknown-linux-gnu ``` Fails: ```sh cargo test --target=i386-unknown-linux-gnu ```
Replaces the fancy platform-word-based logic with a simple call to
`random_bits_core` with rejection sampling. Each retry has p > 0.5
(worst case) of selecting a number inside the range; compare against
[OpenBSD][0]:
```c
/*
* This could theoretically loop forever but each retry has
* p > 0.5 (worst case, usually far better) of selecting a
* number inside the range we need, so it should rarely need
* to re-roll.
*/
for (;;) {
r = arc4random();
if (r >= min)
break;
}
```
**NB**. This change will generally result in different numbers being
produced after calls to `Uint::random_mod`, as evidenced by the test
change.
[0]: https://github.com/openbsd/src/blob/0c90e2b526b26d9f50dde7f7712cec107cda3326/lib/libc/crypt/arc4random_uniform.c#L43-L53
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #1010 +/- ##
==========================================
+ Coverage 79.86% 79.87% +0.01%
==========================================
Files 162 162
Lines 17575 17577 +2
==========================================
+ Hits 14036 14040 +4
+ Misses 3539 3537 -2 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
#1011 shows failing test results. |
Uses a modulus with even odds of rejection so that the number sequence produced exercises the rejection logic in `random_mod_core`. Also tests a sequence of five numbers instead of four, giving us about 64 (in fact, exactly 65) bits against this modulus.
|
Opened #1017 to revert this. It seems it never actually passed CI (my bad) |
This reverts commit 75001b2 (#1010) We're noticing CI failures on cross which seem to be related to this change, e.g. https://github.com/RustCrypto/crypto-bigint/actions/runs/19647957432/job/56267760132 It looks like it's potentially getting stuck in an infinite loop.
This reverts commit 62b90b8 (#1010) We're noticing CI failures on cross which seem to be related to this change, e.g. https://github.com/RustCrypto/crypto-bigint/actions/runs/19647957432/job/56267760132 It looks like it's potentially getting stuck in an infinite loop.
This reverts commit 62b90b8 (#1010) We're noticing CI failures on cross which seem to be related to this change, e.g. https://github.com/RustCrypto/crypto-bigint/actions/runs/19647957432/job/56267760132 It looks like it's potentially getting stuck in an infinite loop.
Re-applies the random_mod platform-independence change from RustCrypto#1010 with additional diagnostic tests to help identify the cause of the CI hang on aarch64-unknown-linux-gnu under cross/QEMU. Diagnostic tests added: - random_bits_core_small_bits_diagnostic: Verify 14-bit generation - random_mod_minimal_rejection: Use 2^14-1 modulus (minimal rejection) - ct_lt_small_values_diagnostic: Verify ct_lt works for small values - random_mod_manual_step_diagnostic: Step through random_mod_core logic - random_mod_detailed_debug: Print values for debugging If the issue is in random_bits_core or ct_lt, these tests should fail with informative error messages instead of hanging.
Replaces the fancy platform-word-based logic with a simple call to
random_bits_corewith rejection sampling. Each retry has p > 0.5 (worst case) of selecting a number inside the range; compare against OpenBSD:NB. This change will generally result in different numbers being produced by
Uint::random_mod, as evidenced by the test change.Fixes #1009