grittygrease
commented
6 years ago - [x] 1. Definitely. I suggest we remove r and say that q is the largest prime factor.
- [x] 2. Also true. Generally, we use curves over prime fields as examples in this document but I don't see why these algorithms wouldn't apply to, say extension fields. We can add the Hasse-Weil bound here as well, but maybe it's better to ask if we need to say anything about the order of the curve group vs the field. I don't think we do. Consider dropping this paragraph?
- [x] 3. Yes. We should state that this is true in Weierstrass form, and that every curve is isogenous to a curve that can be expressed in Weierstrass form. (side note: "Elliptic curves come in many variants" should also be rephrased appropriately as "Elliptic curves can be represented by equations of different standard forms" or something)
- [x] 4. Right. Binary curves (p=2) are a thing, and more common than the extension field curves defined for pairing-based cryptography. The good thing about elements of binary curves is you can express them as bit strings pretty easily. A line about that should resolve this.
- [x] 5. #59 takes care of this
- [x] 6. TODO?
- [x] 7. The first lines are still confusing here
- [x] 8. Resolved?
- [x] 9. Needs to be changed to scalar point multiplication
- [x] 10. #59
- [x] 11. Yes
- [x] 12. To be fixed?
Section 2 states that n = qh + r, where n is order of the group of elliptic curve points, q is a prime order of a subgroup of the group of elliptic curve points, h is a cofactor and r is a remainder. Is there any sense to use value r? Every nonzero r directly violates Lagrange's theorem.
In the sixth paragraph of Section 2 states that n can be estimated using Hasse's theorem as |n-p| < 2 * sqrt(p). This is true for the prime field case, otherwise we have to use Hasse-Weil theorem.
The same paragraph refers that if point (x, y) belongs to some curve, then (x, -y) also does. It must be stated explicitly, that it is true for certain curve forms – because this is not true for some coordinate forms like twisted Edwards.
The second paragraph of Section 2.1.1 states that "In most cases, the curve E is over a finite field GF(p^k), with p > 2.". Are you sure about it? The vast majority of standardized curves defined over extension fields seems to have p = 2.
Some clarifications about two separate HashToBase implementations should be added into Section 5.2.2.
Section 5.2.2, paragraph 6. Add word <> before <>.
Section 5.2.4. Description of Elligator2 method uses f(x) function and returns its value instead of a pair of coordinates.
Appendix B, paragraph 1. “Section Section”.
Appendix B, algorithm description, step 4E. Does symbol ^ stay here for scalar point multiplication?
I believe that the HashToBase function has to be described as explicitly as it is possible (including byte order, possible hash function sets for different curves) (the same issue with “be as explicit as possible” applies to our “Randomness improvements …” draft also J
Appendix A.5. “∪” instead of cup symbol?
Misprints: “artbirary”, “simplified”.