Re: [Cfrg] Safecurves draft

[Alyssa Rowan <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

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?


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.

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.

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-----