crypto: BN254 pairing line eval following Beuchat 2010 literally#1543
Draft
chfast wants to merge 1 commit into
Draft
crypto: BN254 pairing line eval following Beuchat 2010 literally#1543chfast wants to merge 1 commit into
chfast wants to merge 1 commit into
Conversation
Alternative to the ipsilon-convention line eval on master (PRs #1541 + #1542): reimplement lin_func_and_dbl, lin_func_and_add, and lin_func to follow Beuchat 2010 Algorithms 26 and 27 (https://eprint.iacr.org/2010/354.pdf) literally. lin_func_and_dbl (Alg 26): t[0] = -4·y·z³ (negated to compensate for -P.y at the call site; Beuchat uses +y_P) t[1] = -6·x²·z² t[2] = 6·x³ - 4·y² T_out = standard Jacobian doubling (X3, Y3, Z3) lin_func_and_add (Alg 27): t[0] = +4·Z3 (Z3 = z0·H; call site uses +P.y) t[1] = -4·R (R = y1·z0³ - y0) t[2] = 4·(R·x1 - y1·Z3) T_out RESCALED by λ=2 to (4·X3, 8·Y3, 2·Z3) — Beuchat's Alg 27 output Jacobian. Same affine point, different Jacobian Z; required for the line scaling to compose consistently across Miller-loop iterations. lin_func: Alg 27 line eval without the T update. Per Miller-loop step, this line equals -2 × the line on master (a uniform F_p factor absorbed by final exponentiation). Both produce the same pairing — the three discrepancies the ipsilon HackMD note enumerates between its derivation and Beuchat's published formulas are not correctness bugs, just a uniform F_p scaling difference that vanishes under FE. The third claim ("tmp6 = -3X² + 3X³ + 9X⁴ - 4Y² which is not close to 2Y² - 3X³") is an arithmetic slip in the note: Beuchat's line 14 expansion needs the (a+b)² - a² - b² = 2ab identity (which the algorithm uses earlier), and gives 6X³ - 4Y² = -2·(2Y² - 3X³) — the same uniform -2 factor. Bench (build/clang-tt, 100 reps × 1s, ecpairing precompile): master (ipsilon factored): 2892598 ns mean, 2872961 ns median this branch (Beuchat lit.): 2861296 ns mean, 2862051 ns median Δ: -31k ns mean (-1.1 %), within ~7 % stddev — statistically indistinguishable. The DBL-side cost (3 extra Fq2 doublings per call × 64 iter/pair) and the ADD-side savings (2 Fq2 muls per ~9 ADD steps/pair) roughly cancel. Kept as a branch for reference / future comparison, not intended to land on master. Tests: 53/53 unit, EEST state tests 11/11 on every stable fork (Byzantium / Istanbul / Cancun / Prague / Osaka).
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #1543 +/- ##
=======================================
Coverage 96.97% 96.98%
=======================================
Files 163 163
Lines 14455 14478 +23
Branches 3385 3385
=======================================
+ Hits 14018 14041 +23
Misses 307 307
Partials 130 130
Flags with carried forward coverage won't be shown. Click here to find out more.
🚀 New features to boost your workflow:
|
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.
Alternative to the ipsilon-convention line eval on master (PRs #1541
crypto: Trivial reuse of computed values in pairing helpers #1542): reimplement lin_func_and_dbl, lin_func_and_add, and lin_func to follow Beuchat 2010 Algorithms 26 and 27
(https://eprint.iacr.org/2010/354.pdf) literally.
lin_func_and_dbl (Alg 26):
t[0] = -4·y·z³ (negated to compensate for -P.y at the
call site; Beuchat uses +y_P)
t[1] = -6·x²·z²
t[2] = 6·x³ - 4·y²
T_out = standard Jacobian doubling (X3, Y3, Z3)
lin_func_and_add (Alg 27):
t[0] = +4·Z3 (Z3 = z0·H; call site uses +P.y)
t[1] = -4·R (R = y1·z0³ - y0)
t[2] = 4·(R·x1 - y1·Z3)
T_out RESCALED by λ=2 to (4·X3, 8·Y3, 2·Z3) — Beuchat's Alg 27
output Jacobian. Same affine point, different Jacobian Z; required
for the line scaling to compose consistently across Miller-loop
iterations.
lin_func: Alg 27 line eval without the T update.
Per Miller-loop step, this line equals -2 × the line on master (a uniform F_p factor absorbed by final exponentiation). Both produce the same pairing — the three discrepancies the ipsilon HackMD note enumerates between its derivation and Beuchat's published formulas are not correctness bugs, just a uniform F_p scaling difference that vanishes under FE. The third claim ("tmp6 = -3X² + 3X³ + 9X⁴ - 4Y² which is not close to 2Y² - 3X³") is an arithmetic slip in the note: Beuchat's line 14 expansion needs the (a+b)² - a² - b² = 2ab identity (which the algorithm uses earlier), and gives 6X³ - 4Y² = -2·(2Y² - 3X³) — the same uniform -2 factor.
Bench (build/clang-tt, 100 reps × 1s, ecpairing precompile):
master (ipsilon factored): 2892598 ns mean, 2872961 ns median
this branch (Beuchat lit.): 2861296 ns mean, 2862051 ns median
Δ: -31k ns mean (-1.1 %), within ~7 % stddev — statistically
indistinguishable. The DBL-side cost (3 extra Fq2 doublings per
call × 64 iter/pair) and the ADD-side savings (2 Fq2 muls per ~9
ADD steps/pair) roughly cancel.
Kept as a branch for reference / future comparison, not intended to land on master.
Tests: 53/53 unit, EEST state tests 11/11 on every stable fork (Byzantium / Istanbul / Cancun / Prague / Osaka).