Skip to content

Implement safegcd-bounds #634

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

Open
tarcieri opened this issue Aug 4, 2024 · 2 comments
Open

Implement safegcd-bounds #634

tarcieri opened this issue Aug 4, 2024 · 2 comments

Comments

@tarcieri
Copy link
Member

tarcieri commented Aug 4, 2024

This is a corresponding tracking issue for this TODO: https://github.com/RustCrypto/crypto-bigint/blob/ae30093/src/modular/safegcd.rs#L341

The bounds we currently implement for Bernstein-Yang are the ones described in the paper, which proves that the algorithm will always converge within the prescribed bounds. However, the bounds are overly conservative and not optimal:

https://github.com/sipa/safegcd-bounds

There is both an improved bounds calculation we can use, as well as an improved divsteps algorithm (hddivsteps) which itself has improved bounds over the original divsteps algorithm.

@dvdplm
Copy link
Contributor

dvdplm commented Mar 12, 2025

https://github.com/sipa/safegcd-bounds

Even more details here.

The current impl results in the following bounds (obtained by just printing out the iteration count while running the crate test suite, sampling the smallest and biggest iteration counts seen):

f bits: 250, g bits: 254 => iterations: 735
f bits: 256, g bits: 256 => iterations: 741

f bits: 1022, g bits: 1021 => iterations: 2949
f bits: 1024, g bits: 1024 => iterations: 2954

f bits: 2043, g bits: 2042 => iterations: 5892
f bits: 2048, g bits: 2048 => iterations: 5906

The improved CT algorithm results in 590 iterations for 256 bit; extrapolated to bigger sizes would mean 2360 iters for U1024 and 4720 for U2048. So there's potentially a ~25% gain to be made here.

@tarcieri
Copy link
Member Author

Though perhaps we should just go full binary GCD: #755

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

No branches or pull requests

2 participants