Re: [Cfrg] Safecurves draft

Alyssa Rowan <> Thu, 09 January 2014 21:35 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 0AD641AE108 for <>; Thu, 9 Jan 2014 13:35:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rgxoO8cmqn4G for <>; Thu, 9 Jan 2014 13:35:45 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 65BFA1AE0C4 for <>; Thu, 9 Jan 2014 13:35:45 -0800 (PST)
Received: from [] ( []) by (Postfix) with ESMTPSA id 651D76028C for <>; Thu, 9 Jan 2014 21:35:34 +0000 (GMT)
Message-ID: <>
Date: Thu, 09 Jan 2014 21:35:48 +0000
From: Alyssa Rowan <>
MIME-Version: 1.0
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
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 21:35:49 -0000

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

- --