Re: [Cfrg] big-endian short-Weierstrass please

Phillip Hallam-Baker <> Thu, 29 January 2015 00:38 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1C4C01A8927 for <>; Wed, 28 Jan 2015 16:38:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ekiyQaKodujp for <>; Wed, 28 Jan 2015 16:38:02 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4010:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A21261A8915 for <>; Wed, 28 Jan 2015 16:38:01 -0800 (PST)
Received: by with SMTP id p9so22814656lbv.8 for <>; Wed, 28 Jan 2015 16:37:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=CBLf3a92m6Pu6PUWNOQGMbEVErohkuDrkV+/IIcs17I=; b=GbMHjsvgwrON5rDkT58FW0TB4PulH4p7EcJfV+2P3+UwXaN/zJeHx8Z8ap9T16zKvg Q178xAXmSyQH9J+ZtBoI4S7qDTRLCi6fyDRKpkXYBcQu3ZuFx4uh60fdbzi264pDr2Qv b1kwZ61a0tuL3aJ8eZ9nLKAWMSXykYgpL9NPOlxhTwGpYIQ71WNgbYMTpXIjsGKBSbk7 URqZaOeojkEHes1fZb95rJJ8R2f53JdWDFa1eNwNj6WFi5gaff2mYbIcksx/AGOeOjrr ukJFd6itU/nd1Tp0axO/LLhQQeR5eSx14+SqDNe+KnL0C+h4Bf48bn7ZOgdx/Kl42mc7 D2Cg==
MIME-Version: 1.0
X-Received: by with SMTP id dl3mr11512771lac.24.1422491879740; Wed, 28 Jan 2015 16:37:59 -0800 (PST)
Received: by with HTTP; Wed, 28 Jan 2015 16:37:59 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <>
Date: Wed, 28 Jan 2015 19:37:59 -0500
X-Google-Sender-Auth: 4hAxfhCfUFB7KfAld_byOPZPGK8
Message-ID: <>
From: Phillip Hallam-Baker <>
To: Daniel Kahn Gillmor <>
Content-Type: multipart/alternative; boundary="001a11345a7a301cce050dbfb37e"
Archived-At: <>
Cc: "" <>
Subject: Re: [Cfrg] big-endian short-Weierstrass please
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, 29 Jan 2015 00:38:04 -0000

On Wed, Jan 28, 2015 at 5:30 PM, Daniel Kahn Gillmor <>

> On Wed 2015-01-28 16:23:27 -0500, Dan Brown wrote:
> > For example, RFC 4492 allows curves to be specified in Weierstrass
> > form, not just as named form.  I don't know if any TLS implementations
> > support the specified curve option, but if they do, then it would be
> > nice if the new implementations could talk to them, using the new
> > curves.
> Over in the TLS WG, we're working on actively deprecating the custom
> curve selection mechanism and moving strictly toward pre-named curves
> (this is true for finite-field DH as well).  Custom curve and FFDHE
> group selection will be gone in TLS 1.3.

Right. The objective here is to dump all the existing code in the trash and
start again. Because we want the implementations to have constant time
implementations and to preclude the possibility of malicious point attacks
by choosing curves that allow us to easily compute y from an x, and only
sending the x.

What we want to avoid at all costs is patent encumbrances. Dumping
Weierstrass is a pretty good start because that was the favorite curve of
the folk who applied for most of the patents.

The only area where I did have concerns is that to be able to deploy crypto
on these platforms I have to be able to buy FIPS certified hardware or
equivalent. But I think we can probably put pressure on our vendors to
deliver in time. Before the new curves can be used in browsers for certs,
the browser providers are going to have to be satisfied.

In the near term, the application for this will be to make the use of an
ECDH ephemeral essentially cost free and the certified hardware issue is
not a show stopper. But I don't want to do that in a way that makes it
difficult to move to EC certificates in the future.

I don't accept that big endian is more error prone. The existing code for
X.509v3 crypto is all big endian. Changing that will introduce a new code
path and opportunity for error.

> oThe over-flexibility in EC group selection isn't widely used, and when
> it is used, there is no clear way for a receiving implementation to have
> confidence in the structure of the arbitrary curves provided (even
> simple primality-testing is probably too expensive for most to do at
> runtime), or to have a reasonable (efficient, constant-time)
> implementation.
> I don't think this is a particularly useful half-measure.  I'd rather
> see implementations pick up new, reasonably-vetted curves than try to
> muddle through supporting arbitrary curves provided by the peer.

I don't see how we can reasonably use custom groups in IETF protocols
because both sides have to agree to use the same group. And when one side
can propose the use of a malicious curve, the opportunity for perfidy is

The Web PKI has never permitted the use of arbitrary curves in certs:


CAs SHALL confirm that the RSA Public Key is at least 2048 bits or that one
of the following ECC curves is used: P-256, P-384, or P-521.

Now it should be quite easy to add the new curves to the list. I suspect
that unless the browser providers are feeling really generous, they will
expect us to end of life our existing ECC certs to get the new ones added.