[Cfrg] Status of draft-ladd-safecurves-03

[Watson Ladd <[e-mail]>]

Dear all,

Currently we do not know what point format to use if we want a unified
one . Robert Ransom has a suggestion for one which is somewhat
reasonable, but I still need to dig up formulas, check they work, etc
to put it into the draft. Anyone can send me a diff if they so desire.
The endianness issue is as stupid as it is important: I'm not attached
to big endian and can change it if there is consensus, but given that
IETF protocols use big-endian all the time, I was hesitant to do so.
(There is also a private key coding issue with existing
implementations) Some proposed representations aren't total: I really
don't like that.

We also need to reduce the number of curves.

These are the technical issues I can deal with.

The name and formatting have generated a vast amount of unimportant
controversy, and I have zero desire to encourage the propagation of
this fencepainting. Hex v. dec is somewhat more reasonable, except my
favorite CAS for number theory doesn't support hex. Someday I suppose
I'll switch to Sage.

The major issue from a non-normative perspective is that people want
pseudocode that implements the algorithms safely, or an explanation of
how to do DH in groups with large prime order subgroups. Fine, I'll
add it. The explanation of signatures wasn't going to be a part of
this draft: I wanted it to be in a separate document.

The bigger problem is people want things like "these curves aren't
Weierstrass curves" or "here is the double-and-add formula found in
every elementary book on computation". I've added much of this, but 1)
it's completely non-normative, and 2) you should know it already if
you are an implementor.

Lastly, just because this says encoding should be done one way,
nothing stops a protocol from doing it another way for whatever
reasons. I don't see why we should consider things like existing
implementations etc. here, when they can be considered much closer to
the pointy end where other considerations show up. In particular
Elligator has not featured in this draft, but some protocols will want
to use it.

Sincerely,
Watson Ladd