Re: [Cfrg] Hardware requirements for elliptic curves

Robert Ransom <> Fri, 05 September 2014 03:18 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 3D29A1A0270 for <>; Thu, 4 Sep 2014 20:18:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.149
X-Spam-Status: No, score=0.149 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id unvkr-WjMqbb for <>; Thu, 4 Sep 2014 20:18:49 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 475D11A01DC for <>; Thu, 4 Sep 2014 20:18:49 -0700 (PDT)
Received: by with SMTP id i17so11522264qcy.5 for <>; Thu, 04 Sep 2014 20:18:48 -0700 (PDT)
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=rJdr0f09aFpXEFLO0ED548hIcI7OKiZyTh9zZ3AoIP0=; b=bQFboAf1dBBfmxNlstP919LQgmwJMdpzs9kxO+BknCCr8XcDhQwdLsG6O2cNz5iND/ DLdCf0MrUc0Zm2nTgZRAbjhE9bz5jW2eXU+CViiz0wEyaeWtbPLlSe7H2d7utKPewIBA XwDza/VZ3rkiodGbs9bNSayAhQS6B6P2VbNCP48x+c84+KKhAiERHO62bJIzLPmnBTP9 KSwAHrnQvyi72R4EAwWV1QxpGAuvutOBqftqXWSjcvdjvefPrTfLtCo89QQFCxddMT5+ 1XpaUTnKAbbTnrYUiIK5bcpNOE30chXwHSLHXZMtyf3Fb6gNGnIZ1xigZxRcHdlqx9C3 jJFQ==
MIME-Version: 1.0
X-Received: by with SMTP id m5mr14272030qcg.19.1409887128380; Thu, 04 Sep 2014 20:18:48 -0700 (PDT)
Received: by with HTTP; Thu, 4 Sep 2014 20:18:48 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Thu, 04 Sep 2014 20:18:48 -0700
Message-ID: <>
From: Robert Ransom <>
To: Joppe Bos <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: "" <>
Subject: Re: [Cfrg] Hardware requirements for elliptic curves
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: Fri, 05 Sep 2014 03:18:58 -0000

On 9/2/14, Joppe Bos <> wrote:

> Selecting new curves in a transparent fashion, which are more secure
> compared to the current set of standardized curves by NIST, is the right
> thing to do.

I don't see why you are presupposing that new curves must be selected
-- surely the IETF should not rule out the use of previously chosen
curves such as Curve25519 and the ‘Brainpool’ curves merely because
they have multiple independent, interoperable implementations.  In
particular, the rest of your message argues for a set of curves which
(a) are defined over random-prime-order coordinate fields, and (b)
have prime order, and the Brainpool curves satisfy both of those
criteria *and* are already implemented.

(I'll leave the question of whether those properties are as desirable
in hardware implementations as you claim they are to people who have
studied those, but having prime order is the most important security
risk of the NSA curves in software implementations, so I don't see why
you are criticizing those curves' security in the same message in
which you propose retaining that security risk in newly chosen

Perhaps you don't consider the Brainpool curves to have been chosen
‘in a transparent fashion’?  If that is your concern, I'm sure that
someone from the Brainpool consortium would be interested in
commenting on exactly how transparent their process was.

Additionally, you're raising the issue that new curves should be
chosen ‘in a transparent fashion’.  Since you are one of the authors
of <>, which ‘select[s] new curves’,
would you, and the rest of Microsoft Research, be willing to publish
all of your internal communications and records (e-mails, memoranda,
meeting notes, phone conversations, etc.) regarding that paper and
your efforts to promote adoption of the curves, algorithms, and
software described in that paper?  That would allow people who share
your concern about the transparency of the selection process to
seriously consider the curves specified in your paper.

(I don't consider transparency of the selection process to be nearly
as important as other criteria such as cross-platform performance,
efficiency of constrained implementations, support for simple
algorithms, support for efficient, simple constant-time
sum-of-scalar-multiple algorithms, and the availability of multiple
independent, interoperable implementations, all of which argue against
the curves specified in that paper.  But you, and other members of
Microsoft Research, have raised ‘transparency’ as a concern, and other
people may indeed consider transparency to be important.)

Robert Ransom