Re: [Cfrg] 25519 naming

["D. J. Bernstein" <[e-mail]>]

The ANSI ECDSA standard specifies elliptic curves mod p to have short
Weierstrass form y^2 = x^3+ax+b (see the "elliptic curves and points"
section), specifies ECDSA public keys as points on such curves ("key
pair generation"), specifies required encodings ("conversions between
data types that SHALL BE USED in the algorithms specified in this
Standard"---emphasis added), and in particular specifies the string
encodings of curve points (x,y) ("point-to-octet-string conversion").

The NIST ECDSA standard simply copies the ANSI formats (e.g., requiring
signatures to be "verified as specified in ANS X9.62"). As for Internet
wire formats, RFC 4492 states that its point formats "are specified in
[7]"; [7] is a normative reference, the ANSI ECDSA standard. RFC 4492
requires exactly these formats to be used on the wire in TLS. An
implementation using a different format wouldn't interoperate with
standard TLS ECDSA. Similar comments apply outside the TLS context.

I'm not saying that these are good standards. I'm also not saying that
it would be difficult for IETF to deviate from the previous standards
and specify a better wire format (as I recommend). I'm simply saying
that various claims here regarding ECDSA compliance are incorrect.

Last month I had already pointed out several serious errors in Microsoft
claims regarding compliance with existing standards such as ECDSA. I was
expecting a response to help move the discussion forward---for example,
withdrawing the claims, or perhaps pinpointing an area of legitimate
dispute if there is one. Instead some of the errors were simply
repeated. This is a disappointingly unproductive pattern. I would hope
to see more responsiveness in the future.

David Leon Gil writes:
  [ regarding short-Weierstrass coordinates, Montgomery coordinates, etc. ]
> I'd suggest that talking in this way is better than talking about
> different curves as 'coordinate systems'.

The word "coordinates" is broader than you think. See, e.g., polar
coordinates.

The distinction between, e.g., short-Weierstrass coordinates and Edwards
coordinates for Curve25519 is much more superficial than the distinction
between, e.g., Curve25519 and NIST P-256. The change of coordinates for
Curve25519 has no effect on field arithmetic (which is most of the code
in a good implementation), has only a small effect on overall efficiency
(since the implementor can change coordinates internally), and has a
provably negligible effect on important security metrics such as
discrete-logarithm difficulty.

It's important for curves to _support_ Montgomery coordinates and
(complete) Edwards coordinates, and there's an extra gain in simplicity
from choosing wire formats carefully (as in X25519 for DH and Ed25519
for signatures), but there are many other issues that transcend the
choice of coordinates and that should be discussed without the
distraction of specifying coordinates.

---Dan