Add field square root algorithms Shanks, Atkin, and Kong

[alexander-zw]

Description

• I'll add tests next PR since the new code is currently unused
• I'm thinking to add a changelog entry later as well since there will be multiple PRs on the same issue

closes: #543 (finishes task #1 but not whole issue)

---

Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

• Targeted PR against correct branch (master)
• Linked to GitHub issue with discussion and accepted design OR have an explanation in the PR that describes this work.
• Wrote unit tests
• Updated relevant documentation in the code
• Added a relevant changelog entry to the Pending section in CHANGELOG.md
• Re-reviewed Files changed in the GitHub PR explorer

[alexander-zw]

I didn't know if this variable had a name

[alexander-zw]

Didn't find any name for this algorithm so I just called it "power"

[alexander-zw]

Just realized my naming is a bit inconsistent with some existing names, this says modulus but I say characteristic. I feel like "characteristic" is more accurate though. Let me know if you think that should be changed.

[Antonio95]

Hello! I've been doing some work trying to get the algorithms @alexander-zw implemented to actually be called during sqrt calls on the fields - so far they are implemented, but never called. This is proving very difficult for a couple of reasons that you might have easy solutions to (especially @Pratyush). I'll explain how I view the situation

• The method sqrt_precomputation is generic on a T: MontConfig<N>, which corresponds to a prime field F_p (p prime). However, the algorithms cited in the paper are eminently for nontrivial extensions of prime fields F_q with q = p^m a prime power and, crucially, m > 1. Since I saw this caused some confusion above, the modulus of such an F_q is q, whereas its characteristic is p. The two only coincide for prime fields.
• To support my last claim about the requirement m > 1, cf. the main paper https://eprint.iacr.org/2012/685.pdf and have a look at p. 8, which cointains precisely that condition. For instance, algorithm 3 (Atkin's, for the case q = 5 mod 8) contains an m - 3 (which should be positive). Cf. equation (3) too. In my new tests, this causes the program to crash, since m - 3 overflows as an unsigned integer: since MontConfig corresponds to F_p, m is automatically 1.
• My approach was to make the sqrt_precomputation generic on a Field, which does represent a (finite) extension of a finite field. Infact, it is Field that the enum SqrtPrecomputation is generic on. This change gives us access to things like characteristic (p) and extension_degree (m). However, it does not give us access to other necessary elements such as the modulus q. Of course, we could just compute q = p^m, but doing so requires switching between [u64] and BigInt, and the access to methods to do so, and pow is a) partially unavailabie in Field and b) unavailable at compile time, where we can only use const fn and static.

What is the way to go?

• a) Try to make those methods static so that precomputation can be done at compile time. This would be difficult for me and might introduce breaking changes.
• b) Compute things at runtime. This would be less efficient, although it could be done so that, e.g., q is only calculated once (by e.g. keeping it inside an Option)
• c) Some other suggestion?