Re: [Cfrg] Safecurves draft

Paul Lambert <> Thu, 09 January 2014 22:10 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 7C89C1ACCE5 for <>; Thu, 9 Jan 2014 14:10:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.567
X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0bivm0lzrt07 for <>; Thu, 9 Jan 2014 14:10:40 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id CDFCE1AC828 for <>; Thu, 9 Jan 2014 14:10:39 -0800 (PST)
Received: from pps.filterd ( []) by (8.14.5/8.14.5) with SMTP id s09MAR9U003790; Thu, 9 Jan 2014 14:10:27 -0800
Received: from ([]) by with ESMTP id 1h9ydbrwka-46 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 09 Jan 2014 14:10:27 -0800
Received: from ([]) by ([]) with mapi; Thu, 9 Jan 2014 14:10:26 -0800
From: Paul Lambert <>
To: Alyssa Rowan <>, "" <>
Date: Thu, 09 Jan 2014 14:10:26 -0800
Thread-Topic: [Cfrg] Safecurves draft
Thread-Index: Ac8NgsITbQofXW74Syym0Bu011TbfQAAipsA
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14, 0.0.0000 definitions=2014-01-09_07:2014-01-09, 2014-01-09, 1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1401090160
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:10:41 -0000

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.

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

> 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
> _______________________________________________
> Cfrg mailing list