Re: [Cfrg] Safecurves draft

[Paul Lambert <[e-mail]>]

Hi Alyssa,

> On 09/01/2014 14:42, Watson Ladd wrote:
> > The naming issue is fine: we can say "the safecurve Mxxx has been
> > found to be unsafe" without risk of being misunderstood.
> 
> I have to say, on reflection I'm definitely leaning more towards
> calling the group of curves/IANA registry something else myself.
> 
> "SafeCurves" is the set of criteria and verifiable vetting process by
> which djb and Tanja are trying to define safe curves to use: fair
> enough, keep the reference under that name, they picked it.
> 
> As Bodo points out, it's _not_ really a collective name for the curves
> that made it through that process. (Although it's tempting to use it as
> one, there really isn't one.) As Jon and Paul and Johannes Merkle and
> others have pointed out, if we did name the registry/RFC that, we're
> risk looking a bit naïve (and dangerously misleading) at least in a
> decade, or two, or whenever, when QC eventually bears fruit or
> something similar happens.
> 
> If “SafeCurves” risks being confusing, we need another name. …I have no
> idea. They're next-generation elliptic curves (NGEC?), now that we've
> found better curve forms than short Weierstrass, but I think "Next-
> Generation" always sounds a bit silly when it's the current one, or
> especially when it's the previous one. We may just as well use a
> catchy, arbitrary name… “Ellipsis”, maybe?

Good points.
Perhaps if we look at the full collection of curves as a curve catalog,
we are simply adding two more classes of curves.

There would be some value in comparing the attributes of all curves if
we treat them as a full set versus old and new.

It also happens that the new curves are using Edwards and Montgomery
equations.  For an RFC for just these new curves we could just refer 
To these terms - "Edwards and Montgomery Curves for Elliptic Curve Cryptography"
or something similar ...

> As far as the names of the individual curves: while a systematic naming
> scheme is tempting, which is why I raised it, counterbalancing that are
> that people are actually using these curves _right now_ in the wild:
> adding new names for them might just serve to confuse everyone. Not
> everyone's waiting for our informational RFC, after all:
> people need fast strong crypto badly right now, the routines are
> already available, and they're getting used. All we're really doing,
> perhaps, is documenting it consistently as a starting point for their
> adoption in internet standard protocols like TLS, DNSSEC, IPsec, PKIX
> and so on.
This need not be an issue if the new names are clearly distinguishable 
and mapped to the old names.  For example: 'secp256r1' is identical to
the later 'nistP521'

I suggest that we reuse a similar nomenclature.  It would make the new curves
look like equals in notation, provide a consistent nomenclature,
And the postfix 'r1', 'r2' notation is handy for new parameters or generator
points in the same curve/field.

Proposal:
 - first four characters define the curve type/equation/math/etc
 - next 3 or more numbers are the field size
 - next characters carry an 'r' followed by a revision indication

curve3617 -> edwp414r1


> 
> So maybe just stick with the names their respective creators gave them
> (dropping the caps and dashes as I suggested so command lines and
> config files don't hate us forever): curve1174, curve25519, curve3617,
> e511, m521, …
> 
> 
> On 09/01/2014 09:27, Manuel Pégourié-Gonnard wrote:
> > While at it, we should also document the requirements for private
> > keys, which are different from the way they are usually chosen for
> > short Weierstrass curves.
> 
> Good call.
> 
> 
> On 09/01/2014 20:01, Paul Lambert wrote:
> >> [draft doesn't specify encoding]
> > Wrong answer — we need interoperability of public key representation
> > Since a key may be used in multiple applications.
> 
> As above, given they're already in-the-wild, and we're just documenting
> them, I'm inclined to just say, use the representation specified in the
> papers already in the wild, and implemented in the software already in
> the wild. Done. Time for tea.
Better answer ... but the representation needs to be documented.

Paul
> 
> I note [draft-josefsson-tls-curve25519-02] goes with big-endian instead
> of little-endian, essentially because TLS usually uses big-endian for
> bignums. I'm probably going to go and comment against that decision,
> because the paper and every implementation already out there uses
> little-endian: in a sense, that decision's been made for us (and big-
> endian lost the commonness fight some time ago)?
> 
> - --
> /akr
> -----BEGIN PGP SIGNATURE-----
> 
> iQIcBAEBCgAGBQJSzxYzAAoJEOyEjtkWi2t6HfUP/iS0t44KYkNVJIooNhTOztZr
> 9SBPHXX7DSKzWyV5ZOZ4GtMJsPsRW74tyPZT1VniHG9ZQijdQVa59Kyadse0UKwM
> chv6Qq2atUq553VKNL7XGQdMjmPSRKuNjgPajynl7Aq096zp+2KZkObfHM/fJqAo
> l9BHym/ieTzZUJYt1n4AEPz3awEN0EYHZeQ4ABz+zHCguoRYO15UPbWWgWYz16An
> qXrr4Bsxs8cyioIDnVbnSWDrmfcMe2wAu/0flxgdBJMrrE5/vKmVCl2c16nBtyVx
> Ox41WcnY5ltj56x4a+q8ko7oSxjRlyV1PsUft+8PLYlpIzMFqE6WOAbd1Igvz+XM
> 3wPXKuSnMS6yKXryJh+ju1y+v1SERmOdRnxu5Mbu3HqoYbEmMW265AMqxTn/bDPK
> dKIzgXN+z6t3t6xeA04C3TN/wTKpMJeUL+zau+HFti4Yd5bfIy7YpfGc7moiUC4K
> RcPxBHS56ebYPNKEi9FncRDUts8OgT8nFsiUt+0MjN+Wz9vdgG5KB9tsDGhTBGnR
> tG2OYKU0FfIMnICfIoM4Goa0Vs3N8a11Scii0v6QCfABaGDH3f2Zc1AEbCYei1yT
> sByseeFB6SaSesOkOxWx1dTa4pI9LXmRYXPhhjkcKq8eF0zJNMsKb3a6NsCMZLwC
> cbtmmLqAzgIAassFudKN
> =Avz3
> -----END PGP SIGNATURE-----
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> http://www.irtf.org/mailman/listinfo/cfrg