Re-host variable-base signature verify on the fast Montgomery field - #185
Merged
Conversation
ECDSA/EC-NR/Schnorr verification ran its dual-scalar u1*G + u2*Q combination on the legacy 32-bit-limb normal-domain field with per-op heap objects, while [d]Q and signing already use the fast value-type Montgomery field. That left verify the slowest EC operation by far (secp256r1 ~11x OpenSSL). Add an order-keyed variable-base verifier over the fast field, built on the existing RCB2016 complete (exception-free) point formulas driven by interleaved wNAF. Because the formulas are unified, every degenerate verify input (u1=0, u2=0, u1*G = +/-u2*Q, mid-ladder collisions) is handled with no special-case code. TECAlgorithms.SumOfTwoMultiplies picks it up through a registry keyed on the group order, gated on both scalars being non-negative (the verify domain). The seam is reachable only from signature-verify call sites, never from a secret-scalar path, so the constant-time posture of [d]Q and signing is unchanged. Registered for secp256r1/secp256k1/secp384r1/secp521r1. Verify speeds up 1.42x (P-256) to 2.33x (secp256k1); secp256k1 now edges ahead of OpenSSL and the NIST curves close substantially (P-256 ~11.5x->8.1x, P-384 ~2.4x->1.5x, P-521 ~2.7x->1.2x). P-384/P-521 gain because they shared the same legacy verify field. secp256k1's new path measured faster than its GLV path, so it is registered unconditionally.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
ECDSA/EC-NR/Schnorr verification ran its dual-scalar u1G + u2Q combination on the legacy 32-bit-limb normal-domain field with per-op heap objects, while [d]Q and signing already use the fast value-type Montgomery field. That left verify the slowest EC operation by far.
Add an order-keyed variable-base verifier over the fast field, built on the existing RCB2016 complete (exception-free) point formulas driven by interleaved wNAF. Because the formulas are unified, every degenerate verify input (u1=0, u2=0, u1G = +/-u2Q, mid-ladder collisions) is handled with no special-case code. TECAlgorithms.SumOfTwoMultiplies picks it up through a registry keyed on the group order, gated on both scalars being non-negative (the verify domain). The seam is reachable only from signature-verify call sites, never from a secret-scalar path, so the constant-time posture of [d]Q and signing is unchanged.
Registered for secp256r1/secp256k1/secp384r1/secp521r1. Verify speeds up 1.42x (P-256) to 2.33x (secp256k1); secp256k1 now edges ahead of OpenSSL and the NIST curves close substantially (P-256 ~11.5x->8.1x, P-384 ~2.4x->1.5x, P-521 ~2.7x->1.2x). P-384/P-521 gain because they shared the same legacy verify field. secp256k1's new path measured faster than its GLV path, so it is registered unconditionally.