Skip to content
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

Implement EllipticCurve_with_prime_order() constructor #38341

Open
wants to merge 8 commits into
base: develop
Choose a base branch
from

Conversation

JosePisco
Copy link
Contributor

@JosePisco JosePisco commented Jul 9, 2024

I suggest this diff against develop that implements the EllipticCurve_with_prime_order(N) constructor. Using the prime order N in input, this method finds another prime p and constructs an elliptic curve E/Fp with #E(Fp) = N.

It follows Algorithm 2.2 of the paper Constructing Elliptic Curves of prime order by Bröker and Stevenhagen. The running time is quite random depending on the input parameter but can turn out to be fast for some larger values (≃ 256 bits primes). It's also worth noticing that some values will make this function run for a very long time.

There had been a PR by @grhkm21 and @GiacomoPope that implements the EllipticCurve_with_order() method. This PR would intuitively fit nice into their work but I felt uncomfortable with it returning an iterator. I felt like returning a single curve was more handy so I implemented this method in a separate function that does so but I'm open to suggestions if this is of any interest to the community.

📝 Checklist

  • The title is concise and informative.
  • The description explains in detail what this PR is about.
  • I have linked a relevant issue or discussion.
  • I have created tests covering the changes.
  • I have updated the documentation and checked the documentation preview.

⌛ Dependencies

Copy link

github-actions bot commented Jul 9, 2024

Documentation preview for this PR (built with commit 11270fb; changes) is ready! 🎉
This preview will update shortly after each push to this PR.

@GiacomoPope
Copy link
Contributor

From my perspective the work was done during a Sage days and most probably can be improved but I would be interested in tracing that over flow error... I thought we tested it for larger values and it was fine and fast enough. Don't know...

@JosePisco
Copy link
Contributor Author

From my perspective the work was done during a Sage days and most probably can be improved but I would be interested in tracing that over flow error... I thought we tested it for larger values and it was fine and fast enough. Don't know...

Now that I read my comment again, I might have wrongfully expressed myself. I wanted to argue why this code that would intuitively fit inside your work is written separately.

Copy link
Contributor

@vincentmacri vincentmacri left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think I'm familiar enough with Sage or what you're doing to approve this, but hopefully this feedback helps make the review easier for someone who is more familiar.

src/sage/schemes/elliptic_curves/ell_finite_field.py Outdated Show resolved Hide resolved
# of elements of S than using a powerset. Here many multiplications are
# done multiple times.
for e in powerset(S):
D = product(e)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the paper, the algorithm takes a product of the p^* terms, not the p terms. Should there be a computation of the p^* terms somewhere? I also don't see where you do the square root mod N part of the algorithm.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The square roots are used to solve the diophantine equation for 4 * N and BinaryQF does it for us.

The p* are defined as p* = (-1)^(p-1 / 2) * p. Basically, it checks the parity of p-1 / 2 to negate or not p. This is a shady part for me because this wouldn't work and it kept yielding non-discriminants for the Hilbert polynomial. I found a hack around that seems to work but maybe I'm wrong here.

@grhkm21
Copy link
Contributor

grhkm21 commented Jul 10, 2024

This PR would intuitively fit nice into their work but I felt uncomfortable with it returning an iterator. I felt like returning a single curve was more handy so I implemented this method in a separate function that does so but I'm open to suggestions if this is of any interest to the community.

I disagree, I mean CM method inherently generates multiple curves, so it makes sense to return an iterator. If you want a single curve, just use the (builtin) next function.

@grhkm21
Copy link
Contributor

grhkm21 commented Jul 10, 2024

Also I will have to look closer at the paper and the implementation, but why don't use you just use EllipticCurve_with_order? It seems to implement the same CM stuff based on hilbert_polynomial.

Copy link
Contributor

@vincentmacri vincentmacri left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me, but someone who better understands the algorithm and paper you're working off of should take a look too.

@JosePisco
Copy link
Contributor Author

Looks good to me, but someone who better understands the algorithm and paper you're working off of should take a look too.

Agreed, I believe this work is fine but the ways around for the discriminant computation would require second, maybe deeper review.

Thanks a lot for the good review so far!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants