Re: [Cfrg] Safecurves draft

[Watson Ladd <[e-mail]>]

On Thu, Jan 9, 2014 at 2:10 PM, Paul Lambert <[e-mail]> wrote:
> 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 ...

RTFD: It is titled simply "Additional Curves for IETF Protocols" and
has been since the beginning.
Safecurves is simply part of the filename with minimal semantic
import. I changed the registry name
in version 01.

Anyway, I'll upload a third revision sometime that addresses some of
the more substantive issues that have been
raised, such as a desire for canonical representations.

A lot of the issues that have been raised are readily resolvable with
additional drafts, should they be necessary, such
as a systemic catalog of all curves. If this really is the worst
problem you have with the draft, I think we're done.

>
>> 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
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> http://www.irtf.org/mailman/listinfo/cfrg



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin