crypto-bigint 0.7.6 fixes timing leaks in constant-time arithmetic

The RustSec advisory RUSTSEC-2026-0387 was issued on October 23, 2026. It reports that several crypto-bigint operations meant to run in constant time could execute secret-dependent branches, and version 0.7.6 fixes them. If your code does crypto-bigint arithmetic on secret integers, upgrade to 0.7.6 (which requires Rust 1.87) and run cargo audit again.

What the advisory reports

The advisory's title is "Multiple timing variability issues in operations intended to be constant-time". It is a Vulnerability in the crypto-failure category, and it lists one patched range: >=0.7.6.

The advisory says that, "depending on the compiler and target CPU", these operations could branch on secret values:

• subtraction
• zero counting
• division
• Montgomery multiplication

It also names two more problems. UintRef equality could stop at the first limb that did not match, and BoxedMontyForm::invert branched on whether an inverse exists.

The fix is release PR #1365, merged into master on October 23, 2026. Its Security section lists four changes:

The advisory says v0.7.6 "removes the identified branches" and updates ctutils with its own constant-time fixes. It also adds BINSEC-based regression checks, run with cargo checkct, for arithmetic on multiple targets. These checks inspect the compiled code, so a branch added later by the compiler should fail CI.

The same release also has correctness fixes that have nothing to do with timing. They include BoxedUint GCD with mixed-precision zero operands, the carry from Karatsuba wrapping_square, exact division edge cases, Montgomery reduction in repeated squaring, a safegcd iteration-count overflow "at precisions of 93558 bits and above", and the carry returned by Uint::try_sub_with_carry.

Who is affected and why it matters

crypto-bigint is a big-integer library from RustCrypto, built for cryptography, with stack-allocated, no_std-friendly types. Code that uses it this way relies on constant-time behavior: the running time should not depend on the secret values being processed.

The advisory says that code using the affected operations "on secret integers may leak information through timing or microarchitectural side channels." The leaked information can include intermediate arithmetic values, which limbs match in a comparison, and whether a value has an inverse. The advisory warns that this leakage "could potentially enable recovery of cryptographic secrets."

You are most exposed if your code, or a crate you depend on, does any of the following:

• runs modular arithmetic with Montgomery forms (MontyForm, BoxedMontyForm) on private keys or nonces
• compares secret values using UintRef equality
• inverts secret values with BoxedMontyForm::invert
• divides or subtracts with secret operands

If crypto-bigint only handles public data in your project, such as signature verification inputs that are already public, the leak exposes little. You will still see the warning in cargo audit until you upgrade.

A related advisory came out the same day. RUSTSEC-2026-0385 covers ctutils, which crypto-bigint uses for constant-time choices. In ctutils releases before v0.4.4, mask generation could compile to a branch on common platforms, and u128 comparisons branched on 32-bit targets. crypto-bigint 0.7.6 requires ctutils v0.4.4, so one upgrade fixes both.

What to do now

The changelog for 0.7.6 says "Bump ctutils to v0.4.4; MSRV 1.87". Check your toolchain before you upgrade.

1. Check whether crypto-bigint is in your dependency tree, and which version:

cargo tree -i crypto-bigint

2. Check your Rust version. crypto-bigint 0.7.6 needs Rust 1.87 or newer:

rustc --version

3. If you are on the 0.7 line, update the lock file to the patched release:

cargo update -p crypto-bigint --precise 0.7.6
cargo update -p ctutils

4. If you depend on crypto-bigint directly, raise the minimum version in your Cargo manifest so the old version cannot come back:

[dependencies]
crypto-bigint = "0.7.6"

5. Run the RustSec checks again. Neither RUSTSEC-2026-0387 nor RUSTSEC-2026-0385 should be listed:

cargo audit

6. If crypto-bigint comes in through another crate that pins an older release line, cargo update cannot fix it. In that case, upgrade the crate that depends on crypto-bigint, or wait for that crate to release a version that allows 0.7.6.

7. If you publish a library that uses crypto-bigint on secret data, release a version that requires crypto-bigint = "0.7.6". Then your users get the fix without changing their own manifests.

Caveats

The advisory says practical exploitability "depends on the downstream algorithm, compiler, target CPU, and an attacker's ability to observe the side channel." It does not include a proof-of-concept or a measured attack, and it does not say which targets produced the branches.

The only patched range is >=0.7.6. The advisory does not list a fixed release for older lines, so cargo audit reports any version below 0.7.6. Projects that cannot move to the 0.7 line yet should check with their upstream crates whether any backports are planned.