Open alinush opened 2 years ago
Coincidentally I recently hit something similar in a slightly different context.
The precompute functions all appear to assume non-identity elements. They immediately convert to affine form and extract the X and Y coordinates (which does not account for the case Z=0). For example: https://github.com/scipr-lab/libff/blob/develop/libff/algebra/curves/mnt/mnt6/mnt6_pairing.cpp#L479
Unless I'm completely off track (which is perfectly possible), if you work around this with is_zero
checks of the G1 and G2 elements, no other cases should be affected.
In terms of fixes (short of alternative implemenations of the pairing), the preecompute functions should probably assert that the input elements are not the identity, and the high level pairing functions could be extended with the workaround to check for identity elements.
Intriguing. The math is a bit above my pay grade, but I guess I can wrap my own pairing function to check for & prevent this bug. Thank you!
Hi all,
I believe I found a small bug in libff on the
develop
andmaster
branches, where e(g_1^0, g_2) != e(g_1, g_2^0), but they should be equal.I am able to reproduce it with the following test:
And then building and running the tests as per the README:
I discovered this while using BN128 from the
master
branch in one one of my projects and then reproduced it in thedevelop
branch above.Specifically, in my project, if I compare e(g_1^0, g_2) with e(g_1, g_2^0), which it should be equal to, I get:
As you can see, the LHS begins with a [1,0] while the RHS with a [0,0].