[cryptography/secp256r1] Add batch verification #2661
Conversation
Add BatchVerifier implementations for both standard and recoverable secp256r1 signature variants. For recoverable signatures: implements algebraic batch verification using random coefficients. The recovery ID allows reconstructing the signature point R directly, enabling the batch equation check: sum(z_i * u1_i) * G + sum(z_i * u2_i * P_i) - sum(z_i * R_i) = O For standard signatures: implements sequential verification due to ECDSA's limitation that standard signatures only contain r (the x-coordinate of R). Without the recovery ID, determining R requires computing u1*G + u2*P for each signature, which is the main cost of individual verification. Also adds: - Unit tests for both batch verifiers - Benchmarks for batch verification with multiple public keys/messages
Remove batch verification from the standard signature variant since ECDSA without recovery ID cannot benefit from algebraic batch verification - computing u1*G + u2*P for each signature to determine R is the main verification cost anyway. Batch verification is only available for recoverable signatures which include the recovery ID needed to reconstruct R without scalar multiplication.
…ation Add explicit high-s check in batch verification to reject malleable signatures. ECDSA signatures have a malleability property where both (r, s) and (r, n-s) are mathematically valid. We enforce low-s to prevent signature malleability attacks. Also adds test that explicitly verifies batch verification rejects malleable (high-s) signatures.
Add test that verifies batch verification correctly rejects the "cancelling forgery" attack where an attacker creates two invalid signatures with R1'=R1+delta and R2'=R2-delta. The random coefficients (z_i) in batch verification prevent this attack since z1*(error) + z2*(-error) = error*(z1-z2) ≠ 0 with overwhelming probability.
Move all inline imports in batch verification tests to the top of the test module per project style guidelines.
Deploying with
|
| Status | Name | Latest Commit | Updated (UTC) |
|---|---|---|---|
| ✅ Deployment successful! View logs |
commonware-mcp | 6595bd4 | Jan 03 2026, 08:35 PM |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| // The x-coordinate might be r or r + n (if is_x_reduced) | ||
| // For P-256, this is extremely rare since n is close to p | ||
| if recovery_id.is_x_reduced() { | ||
| // r + n case - extremely rare for P-256 | ||
| return None; |
There was a problem hiding this comment.
The batch verifier always returns false when recovery_id.is_x_reduced() is set because recover_r_point bails out, but valid recoverable signatures can legitimately have x = r + n (that is exactly what is_x_reduced signals). In that case individual verification/recovery would succeed, while batch verification will deterministically fail for that signature, so batch verification is not equivalent to single verification for all valid inputs. This is rare for P-256 but still a correctness bug; the fix is to reconstruct the point with x = r + n when is_x_reduced is true instead of rejecting.
Useful? React with 👍 / 👎.
…ication Fix recover_r_point to properly handle the is_x_reduced case by computing x = r + n instead of rejecting. While rare for P-256 (since n is close to p), valid recoverable signatures can have x = r + n, and batch verification must handle them equivalently to single verification.
Deploying monorepo with
|
| Latest commit: |
6595bd4
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://86ed851d.monorepo-eu0.pages.dev |
| Branch Preview URL: | https://claude-add-secp256r1-batch-v.monorepo-eu0.pages.dev |
|
This isn't really worth the squeeze/complexity (the only place where batch verification makes sense is recoverable signatures where we already have the associated public keys). |
Codecov Report❌ Patch coverage is
@@ Coverage Diff @@
## main #2661 +/- ##
========================================
Coverage 92.62% 92.63%
========================================
Files 357 357
Lines 102956 103150 +194
========================================
+ Hits 95366 95548 +182
- Misses 7590 7602 +12
... and 2 files with indirect coverage changes Continue to review full report in Codecov by Sentry.
🚀 New features to boost your workflow:
|
…inversion - Implement Montgomery's trick for batch scalar inversion, reducing n inversions to 1 inversion + 3(n-1) multiplications - Add batch_vs_individual benchmark comparing batch to individual verification - Add tests for batch_invert function Performance improvement: ~7% faster batch verification, achieving ~2.17x speedup over individual verification for large batches. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <[email protected]>
It may be worth it if we want to just use recoverable signatures always (but seems to be slower than #2684) |
🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <[email protected]>
Summary
Add batch verification for secp256r1 recoverable signatures using algebraic batching with random coefficients.
Features
Batchstruct implementingBatchVerifiertrait for recoverable signaturessum(z_i * u1_i) * G + sum(z_i * u2_i * P_i) - sum(z_i * R_i) = OWhy Only Recoverable Signatures?
Standard ECDSA cannot benefit from algebraic batch verification because determining R requires computing
u1*G + u2*Pper signature - which IS the main verification cost. Recoverable signatures include the recovery ID needed to reconstruct R directly via point decompression.Performance
Benchmark comparing batch verification vs individual verification (Apple Silicon):
Key Results