Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p,

Adam Langley <> Thu, 26 June 2014 22:22 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id BFF221B2EEE for <>; Thu, 26 Jun 2014 15:22:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.156
X-Spam-Status: No, score=-0.156 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, SPF_PASS=-0.001, URI_HEX=1.122] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PNxeiL927Sq5 for <>; Thu, 26 Jun 2014 15:22:06 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B1AED1B2EF5 for <>; Thu, 26 Jun 2014 15:22:05 -0700 (PDT)
Received: by with SMTP id u10so3412516lbd.19 for <>; Thu, 26 Jun 2014 15:22:03 -0700 (PDT)
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=k0vTkUcGltv1TIIGEd5FhK/yoboRUdfFSbmX2CAjZw4=; b=BPm6LC7rZf+Z8TOUfKilMgT4KrVwHH22Yq1OwpOlrlLF0RJt8OVjNj2+7DCyKFMakW iXsCwPMx0pe19Hz6V8giDJNVy8MD+WkzknIJkMBf8OuxW/eZ1EH3t3F3GlJxEbBih39W /oCchbupTE3L4QgWPTcszXA27NiJXJ4uoL09l1pn3BwEY+QLD4iJg1PHDUkxluIiyO1l G2oJPUPRec5NIofYXeC1mrDs+NmXEJh5+f9GBOrRXIFSPr2nlhjEHSKS/Mp2uBRNZJXM HANYr18nH9VJ8EHh/TOsqDKCNZF2GH9xDYOfi0z8KTbDD17cCuOmg2BmNv6KAR/ppcDs KfcA==
MIME-Version: 1.0
X-Received: by with SMTP id eb3mr4086923lbb.67.1403821323836; Thu, 26 Jun 2014 15:22:03 -0700 (PDT)
Received: by with HTTP; Thu, 26 Jun 2014 15:22:03 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Thu, 26 Jun 2014 15:22:03 -0700
X-Google-Sender-Auth: rMaha81PejUSm4k2OUIf3Wh_x8E
Message-ID: <>
From: Adam Langley <>
To: Michael StJohns <>
Content-Type: text/plain; charset=UTF-8
Cc: "" <>
Subject: Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p,
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 26 Jun 2014 22:22:08 -0000

On Thu, Jun 26, 2014 at 2:59 PM, Michael StJohns <> wrote:
> There's been a small but vocal minority agitating for the adoption of
> Curve25519 for use in TLS (and other IETF protocols).  As the discussion has
> gone on, what I haven't seen is compelling evidence that this technology has
> been vetted sufficiently that it would meet the "Best Commercial Practices"
> threshold for safe harbor status for encryption.  It may eventually get
> there, but for at least the next few (5-10??) years, I would expect
> businesses to avoid the use in privacy sensitive, or financially sensitive
> operations.

I assume that such organisations are not going to adopt any newer
curves either then.

> There are also possible IPR issues

I don't believe that there's any basis to this (beyond the level of
any other ECC).

> definite infrastructure issues (e.g. no
> off the shelf, commercial hardware or software AFAIK)

There are plenty of software implementations with a higher general
quality than any of the NIST curves, although certainly there isn't
any hardware. However, hardware support is the result of demand and
time. There's no hardware support for any curves that the IETF might
come up with either.

> documentation issues
> (not the base curve, but how to incorporate curve data into certificates and
> other protocol messages

Again, I feel that this applies equally to anything new.

> and the fact it's key agreement only (vs the
> current EC curves which can be used for both signature and agreement).

The curve is not key-agreement only. Many implementations provide only
a Montgomery ladder, which does only provide key agreement, but it
works fine for signatures too:

(In fact, I'm not sure if any elliptic curve could be key-agreement
only. Signature schemes fall out of any suitable group, no?)

> AFACT, one of the main reasons for looking at Curve25519 (possibly more
> important than performance or security) is that there is a fear that the US
> Government has placed trapdoors in the current set of curves (NIST P256,
> P384, P521 etc).

Although some certainly subscribe to that, my main motivation for
moving away from P-{256,384} is that they simply aren't good curves.
They are difficult to implement correctly and have many pitfalls.
Elliptic curve design has advanced significantly since then.

> Given that the EC math in FIPS186, X9.62, X9.63, SP800-56A, SEC1, and the
> various ISO documents is pretty much identical, instead of throwing away all
> that implementation and standardization, how about we just generate new
> curves:

Let's just take is as read that new parameters (with the same field?)
could be generated. I'd suggest that the approach in [1] would be
better, but that's not important.


> For most of libraries and hardware devices with which I work, the curve data
> is pretty much static configuration (external table referenced by OID) or
> compilation (ditto but compiled in), or provided as a library argument and
> most libraries have a mechanism to insert or use new curves fairly easily -
> at least within the same family.

In my experience, the cost of a change is mostly fixed. I believe that
the development work that goes into the change is small compared to
the effort to update all the software.

Even if that's not true, we would have to be very careful to
understand the range of easy reconfiguration of these libraries. Do
they specialise the field reduction? (Probably) Thus that would be
fixed. I assume that a=-3 is fixed too. They might be other
limitations in code that would be hard to discover, meaning that the
cost of implementing the change ends up being about the same as any
new curve anyway.



Adam Langley