Re: [Cfrg] Safecurves draft

[Bodo Moeller <[e-mail]>]

Adam Back <[e-mail]>:

Clearly its partly marketing,
> but so what I dont see how a third party can go rename
> *their* curves.


Well, of course you *can*; the question is whether you *should*.  (For
example, NIST P-192 is also known as secp192r1 in Certicom's SECG
specification, and ANSI X9.62 calls it prime192v1.)

That said, http://safecurves.cr.yp.to/ doesn't appear to use "SafeCurves"
as part of the name of *curves*, but rather for selection criteria.  The
curves meeting all current criteria have names such as "Curve25519" or
"M-221", and the latter name isn't Dan's or Tanja's (because the curve is
from other researchers): if you want to include a "namespace indicator"
along with the curve name from the literature, it's not clear that all of
these should be bundled under the same prefix.

I certainly think "Curve25519" is sufficiently unique without a further
namespace prefix, to describe the curve as such in the cryptographic
context.  What we need to standardize is not just names for curves, but
also further details such as OIDs and clearly specified ways to encode
elements and keys -- names should denote that entire bundle, such that if
someone else encodes values for SafeCurves's Curve25519 differently, there
won't be confusion.  For example, note that the name "Curve25519" also
refers to a particular DH scheme *using* that curve, and "Ed25519" refers
to using the "EdDSA" scheme with an equivalent Edwards curve.  As far as
Safecurves is concerned, I don't think a distinction is made between the
two representations of the curve, but that distinction obviously is crucial
for interoperable implementations.  In that context, given that the name
"Curve25519" is already overloaded, and that we probably should make the
Edwards representation available for DH too (in addition to EdDSA), maybe
we *should* make up new name variants to avoid further possibilities for
confusion?

Bodo