Skip to content

Add self-contained wNAF scalar multiplication in primeorder#1690

Open
tob-scott-a wants to merge 1 commit intoRustCrypto:wnaffrom
tob-scott-a:wnaf-new
Open

Add self-contained wNAF scalar multiplication in primeorder#1690
tob-scott-a wants to merge 1 commit intoRustCrypto:wnaffrom
tob-scott-a:wnaf-new

Conversation

@tob-scott-a
Copy link

The upstream group::Wnaf has two bugs that break SEC1/NIST curves:

  1. wnaf_form() assumes Scalar::to_repr() returns little-endian bytes, but ff::PrimeField documents repr endianness as implementation-specific. All SEC1/NIST curves use big-endian.

  2. wnaf_form() drops the final carry when the scalar fills all bit_len bits. This is masked on BLS12-381 (255-bit modulus in 256-bit repr) but causes wrong results for p256/k256/p384/p521.

Rather than depending on an upstream group crate fix, this adds primeorder::wnaf::WnafScalarMul — a self-contained wNAF that handles big-endian repr and the carry correctly.

The WnafGroup impl on ProjectivePoint is filled in (was todo!()) but warns that group::Wnaf itself remains broken for these curves.

This is an alternative to #1689 that doesn't rely on an external change to the group crate.

The upstream `group::Wnaf` has two bugs that break SEC1/NIST curves:

1. `wnaf_form()` assumes `Scalar::to_repr()` returns little-endian
   bytes, but `ff::PrimeField` documents repr endianness as
   implementation-specific. All SEC1/NIST curves use big-endian.

2. `wnaf_form()` drops the final carry when the scalar fills all
   `bit_len` bits. This is masked on BLS12-381 (255-bit modulus in
   256-bit repr) but causes wrong results for p256/k256/p384/p521.

Rather than depending on an upstream group crate fix, this adds
`primeorder::wnaf::WnafScalarMul` — a self-contained wNAF that
handles big-endian repr and the carry correctly.

The `WnafGroup` impl on `ProjectivePoint` is filled in (was
`todo!()`) but warns that `group::Wnaf` itself remains broken for
these curves.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
@tarcieri
Copy link
Member

This sort of approach seems like a reasonable stopgap, but I'd probably prefer to vendor group::Wnaf for now and modify it to remove endianness assumptions so as to ease migrating back to the upstream version whenever it's fixed

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.

2 participants