Re: [Cfrg] draft-ladd-safecurves-02

[Manuel Pégourié-Gonnard <[e-mail]>]

Hi,

Notes taken while reading -02 (in order of reading, so mixing typos with more
important comments).

- abstract: why mention the Jacobian rather than say "elliptic curves" (as you
do in the intro)? Maybe say that DDH is *believed* to be hard, too.

- end of the intro: "then short Weierstrass curves": then -> than

- section 2 "Validation information is given at [SAFECURVES]." What do you mean
exactly? Is it a repeat of "Proofs of all properties claimed exist in
[SAFECURVES]." in the intro, or do you mean something else?

- as an implementer, I'd have a preference for constants in hex. Also, I don't
like the formatting very much. Starting each constant on a new line might help.

- I second Alyssa's suggestion to split the content in two sections, too.

- formulas for Montgomery curves: I think "P_i = [i] P_1" is not what you want
to say. Also, I'm not sure the reference to the Kummer curve is of any help.

- why give the formulas for Edwards with common sub-expressions already
eliminated, but not for Montgomery?

- point encoding "GF_p point on E(GF_p)" isn't that a bit redundant?

- "Formulas for decompression are left as an exercise to the reader." You can't
be serious. The goal should be to actually help people write correct
implementations, which this kind of funny (?) non-reference does not.

- security considerations: "some checks in some protocols": which and which?
"certain attacks": which ones? Again, please, this should be a technical
document giving precise, actionable information.

- IANA: sorry if this is a dumb question, but I'm not sure I see the need for a
IANA register here (an would it be only for the "chicago" curves or all known
curves)? So far, there are protocol-specific registries (eg, TLS Named Curves)
and it seems to me it has been enough.

- OTOH, it would probably be good to have OIDs for the curves here, since they
could be used by many protocols.

Manuel.