Re: [Cfrg] Safecurves draft

Watson Ladd <> Thu, 09 January 2014 22:25 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 79B5E1A1F7C for <>; Thu, 9 Jan 2014 14:25:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yh1OpvNbZBYa for <>; Thu, 9 Jan 2014 14:25:55 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c03::22d]) by (Postfix) with ESMTP id A0A061A1F71 for <>; Thu, 9 Jan 2014 14:25:55 -0800 (PST)
Received: by with SMTP id t60so3362652wes.18 for <>; Thu, 09 Jan 2014 14:25:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=VjA4MMc03lpxABliS/F7jJgCL+LZwY40IuLyODDIR5w=; b=KHZQak1gq3BnHss2TEN3cWdFafkFqdq6GCw99q9QcoEiSstBNPfAsmXCj1rqqZ3IF2 /Io7qg2UkzSsceiqrdgTf0y4l4iyKSaXmBPRhbyxPTCZhaaydR0EN0R1w9GuBKj02YYW HUUp/j5AKVc6ykueRXh7itxvpiX/sk+Ugf/XngrHwlH/rpAJHE/f7xqb5b4U43W7IjKJ Gxo0MBpehFI8RtI0do536Elk6egaui7cO7OLDZH0AzhjcFlGy5kVFkq9sA8tfVnqxV4r 14BlRtu82kIQCXntlaVABTZxwr952wfQMXF/MehZUeGiElWixrYXh6K+wBS399ATThzj r/DA==
MIME-Version: 1.0
X-Received: by with SMTP id l9mr5485471wiz.20.1389306345469; Thu, 09 Jan 2014 14:25:45 -0800 (PST)
Received: by with HTTP; Thu, 9 Jan 2014 14:25:45 -0800 (PST)
In-Reply-To: <>
References: <> <> <>
Date: Thu, 09 Jan 2014 14:25:45 -0800
Message-ID: <>
From: Watson Ladd <>
To: Paul Lambert <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: "" <>
Subject: Re: [Cfrg] Safecurves draft
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 09 Jan 2014 22:25:58 -0000

On Thu, Jan 9, 2014 at 2:10 PM, Paul Lambert <> 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
>> 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
> _______________________________________________
> Cfrg mailing list

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