Re: [Cfrg] Safecurves draft

Bodo Moeller <> Thu, 09 January 2014 12:27 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4816C1AE237 for <>; Thu, 9 Jan 2014 04:27:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 2.432
X-Spam-Level: **
X-Spam-Status: No, score=2.432 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FB_CIALIS_LEO3=3.899, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6XU5h5ur1OMh for <>; Thu, 9 Jan 2014 04:27:55 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 1C1A61AE223 for <>; Thu, 9 Jan 2014 04:27:55 -0800 (PST)
Received: from ( []) by (node=mrbap4) with ESMTP (Nemesis) id 0M3SaW-1VAN0a3XYO-00r1ml; Thu, 09 Jan 2014 13:27:45 +0100
Received: by with SMTP id vb8so3163554obc.35 for <>; Thu, 09 Jan 2014 04:27:43 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/JBLtoT/H28bpUmR7C2bDNC3EmrvDgSh0kNtN5TTO94=; b=B3ZP3/1Uuutb0tS8RmlqKhVHAClJCeqQre1Cr/UKZUiQlLpcS9mHNPQvrfq1CkKAx8 Wa5jzlJT9dVI+Gvy2kxQwhaFo/SfiTxoppXHLLnm+7Xf4sfRpk02JbPDvvYR1Ve/ANSA R5M8Na22VaQjAbXgpxbubWdi6DLqapqX1BSBiFc3cDDoOMC5yKrZ9Dhi0LktbVPBNsrO 53DPzp+BDLzwh2nypxKT9jiifHVA6XUD8DSa67WiaUOn2j2tkK4hEg65t5qFPF5PK4ij /O1BqCRXIa+saGu7/P6sB6i2gGMTvcASLmam/7oCl6ropxumH8FTe8TQyohDuV1EBqa2 rZ5g==
MIME-Version: 1.0
X-Received: by with SMTP id vd9mr73894obb.87.1389270463562; Thu, 09 Jan 2014 04:27:43 -0800 (PST)
Received: by with HTTP; Thu, 9 Jan 2014 04:27:43 -0800 (PST)
In-Reply-To: <>
References: <> <>
Date: Thu, 09 Jan 2014 13:27:43 +0100
Message-ID: <>
From: Bodo Moeller <>
To: Adam Back <>
Content-Type: multipart/alternative; boundary="089e013a10467a4ec604ef88bc2c"
X-Provags-ID: V02:K0:tL0vwH7U1lh0IHlq7Zs2eeFIEtBMtdAtJhYHYcAeS5S qDs0Q2i9xiPOf84KmRP09LAxjzAserXy8XxzTBs+gMq5C3g58M unBEwJUfyVagQV0AbAzmYT0sDDNirUXKvT33wr9Q294+HutSf5 jG0Zi/dQWeX2/yPGeaO/pckeMHbGNw7vZMr+k83Nr3vtXSTJnH gdF8ZfdAM8a44TVphAX0eknbP1GOABTEHalnlZ6KbuUSrMY6NM UDqJg2btWld14BYPfAtPhKtkuC1CNrnORzxZsdmi+rIixAXOYo BlAveB3kdLyadPoRUPb3Dh22rZc5mB2x2z35KB1C5DegsilF7c AsGNGIzznDdnCDSEjDpNC+2AxnFumRNiLEFfHeAlWkFaD4XLu3 kllPPnr7SaQnzM1x71p1vQa3qfsHrDNSI0zeuv/qbAV/KDJ3e+ pqrDU
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 12:27:57 -0000

Adam Back <>:

Clearly its partly marketing,
> but so what I dont see how a third party can go rename
> *their* curves.

Well, of course you *can*; the question is whether you *should*.  (For
example, NIST P-192 is also known as secp192r1 in Certicom's SECG
specification, and ANSI X9.62 calls it prime192v1.)

That said, doesn't appear to use "SafeCurves"
as part of the name of *curves*, but rather for selection criteria.  The
curves meeting all current criteria have names such as "Curve25519" or
"M-221", and the latter name isn't Dan's or Tanja's (because the curve is
from other researchers): if you want to include a "namespace indicator"
along with the curve name from the literature, it's not clear that all of
these should be bundled under the same prefix.

I certainly think "Curve25519" is sufficiently unique without a further
namespace prefix, to describe the curve as such in the cryptographic
context.  What we need to standardize is not just names for curves, but
also further details such as OIDs and clearly specified ways to encode
elements and keys -- names should denote that entire bundle, such that if
someone else encodes values for SafeCurves's Curve25519 differently, there
won't be confusion.  For example, note that the name "Curve25519" also
refers to a particular DH scheme *using* that curve, and "Ed25519" refers
to using the "EdDSA" scheme with an equivalent Edwards curve.  As far as
Safecurves is concerned, I don't think a distinction is made between the
two representations of the curve, but that distinction obviously is crucial
for interoperable implementations.  In that context, given that the name
"Curve25519" is already overloaded, and that we probably should make the
Edwards representation available for DH too (in addition to EdDSA), maybe
we *should* make up new name variants to avoid further possibilities for