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

Alyssa Rowan <> Fri, 27 June 2014 06:46 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 9E6C61B3165 for <>; Thu, 26 Jun 2014 23:46:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.003
X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Inbbb3StqugO for <>; Thu, 26 Jun 2014 23:46:37 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B72691B3168 for <>; Thu, 26 Jun 2014 23:46:36 -0700 (PDT)
Message-ID: <>
Date: Fri, 27 Jun 2014 07:46:38 +0100
From: Alyssa Rowan <>
MIME-Version: 1.0
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
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: Fri, 27 Jun 2014 06:46:39 -0000

Hash: SHA512

On 26/06/2014 22:59, 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).

CFRG have selected Curve25519 as the preferred elliptic curve for use
in IETF protocols, as Rich has pointed out.

That is because it is very, very good: it is 8 years old, extremely
fast, and simpler and faster to implement in constant-time, with _far_
fewer special cases, than any Weierstrass-form curve.

> possible IPR issues

"Total number of IPR disclosures found: 0"

As per IETF/IRTF IPR policy, kindly _reference_ any relevant IPR you
are aware of.

To the best of my knowledge, Curve25519 is patent-free: all relevant
patents have expired. No-one has stated anything to the contrary, as
far as I can see, including those at Certicom who are on CFRG (who
would have had to have raised anything relevant, I gather?).

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

Please note the extremely liberal license of the very high quality
open-source software implementation in NaCl. It is public domain: you
can take it and use it right now if you want, with zero IPR issues.

Hardware implementations always lag new technologies: ARMv8 only just
got SHA-256, and Intel and AMD don't have anything which specifically
accelerates any crypto except AES.

This is alright, as the software performance of Curve25519 is
extraordinarily good.

It is of course unreasonable to demand implementations exist _before_
specifications. However, adoption has already begun (OpenSSH, Tor,
OpenBSD, Chromium), and perhaps in some places that may surprise you
(the Apple iPhone!).

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

Curve25519 can be used with signatures, in twisted Edwards form:
please see Ed25519. That has not yet been codified with CFRG or the
PKIX WG, as far as I know, but exists and works very well (OpenBSD
uses it, for example): discussion is still ongoing about details, and
probably needs a refresh/reminder over there.

The use of Curve25519 with ECDHE is covered by the josefsson draft, as
you may remember, back from September 2013:

> [Re: potential trapdoors in NIST curves]

Already very widely discussed, but obviously not relevant to Curve25519.

I know of no backdoors in NIST P256 (secp256r1) or P384 (secp384r1);
but yes, the possibility one exists is alarming, and investigations
into the curve-generation process still leave things remarkably murky.

> how about we just generate new curves:

With blackjack and hookers? :-)

Perhaps the paper at <> would be
of interest to you. I would recommend reading it before proceeding any
further with that discussion, especially down to the "Notes on
terminology and security" section.

Brainpool has already generated a set of 'random' primes, but random
primes are extremely slow to implement - and in the case of Brainpool,
the 256-bit curve has extremely unfortunate lack of twist security, so
any implementation that tries to skip validation is in really big trouble.

By adopting Curve25519, we have the opportunity to take advantage of
what we've learned about EC _since_ the engineers at Certicom
generated the NIST curves.

Obviously, I'm part of the 'vocal minority' here, as I'm planning to
use it very soon, because it makes ECDHE both secure and really,
really fast - and that's a huge win for both TLS 1.2 & TLS 1.3!

- --