-
-
Notifications
You must be signed in to change notification settings - Fork 452
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
.set_order
is deterministically incorrect in rare cases
#38617
Comments
I mark it as major since the method is quite useful. For example if we want to find the twist of the curve with a given order, we can use this (or rather |
Okay the trace test thing is stupid because Another option is to also check the order on the quadratic twist, but that's also probabilistic and I highly suspect it's also deterministically incorrect in rare cases. One more observation is that the number of "fake orders" should be very few - I believe at most 5 - because of uh I will fill this in later I need to get off the train |
The reason for the number of fake orders is that with the current implementation of I don't know how to use it to our advantage though 😓 Also @GiacomoPope I think you would also be interested |
This bug only applies when the curve is non-cyclic. |
Technically it's not a bug… since The only "bug" I can find is with the documentation making claims such as the following
Anyway, here are some other ideas to possibly fix it. Of course, any additional checking will slow down the Theorem: The set of points in Which implies, by the fundamental theorem of finite Abelian group, we can write Theorem: Which means the current algorithm checks if Theorem: Which implies, if there's a Conjecture: generic group operations cannot, in polynomial time, distinguish between the following, given
Note that computing a basis involves factorizing the order (see Assume the above conjecture, we're in trouble. Nevertheless: Theorem: In the case above, pick two random points in the curve,
So, Conjecture: If we also check the Weil pairing is zero for the provided I guess. (Sounds about right, but I'm lazy to prove it.) Now the question is, is the Weil pairing fast enough to compute to justify the change? This is another idea, building on grhkm21's work above. Assume As shown above, we have that As such, if we're given a fake order If the root is an integer, then we check if it's highly likely that every point has order Claim: in this case Proof: We have An example where both a curve and its quadratic twist has a fake order is given below. It is not sufficient though. It might make an interesting exercise to prove that when the degree of the finite field is odd then there is no solution, or find a counterexample. F = GF(257^2)
assert [*F.modulus()] == [3, 251, 1]
E = EllipticCurve([F.gen()^13111, 1])
assert E.order() == 256*256
E.set_order(256*257)
E.set_order(256*256)
G = E.quadratic_twist()
assert G.order() == 258*258
G.set_order(258*257)
G.set_order(258*258) |
Steps To Reproduce
I don't know if "deterministically incorrect" is the correct term, but the method is probabilistic, and I am claiming that it does the wrong thing with probability 1.
Expected Behavior
ok
Actual Behavior
It should give an error. In a separate session, you see that
Additional Information
The bug is obvious from the code, but I am not sure about a fix that doesn't involve computing
.order
directly. For more test cases just brute force. In essence we want a methodE.has_order(N)
that doesn't involve computingE.order()
.Here's a stupid idea that doesn't work: derive
\tr(E)
then verify the Frobenius quadratic equation is correct.@JosePisco @yyyyx4 might be interested.
Environment
Checklist
The text was updated successfully, but these errors were encountered: