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

Watson Ladd <> Fri, 27 June 2014 01:24 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 6FD331B30B1 for <>; Thu, 26 Jun 2014 18:24:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BobyYfZWxTuz for <>; Thu, 26 Jun 2014 18:24:51 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c07::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C09FB1B298B for <>; Thu, 26 Jun 2014 18:24:51 -0700 (PDT)
Received: by with SMTP id 19so2488045ykq.33 for <>; Thu, 26 Jun 2014 18:24:51 -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; bh=wn3+JG68P1xTARog5JReH2DXc/hPw0yN8VmTI4rufRE=; b=dRb5q2uGuvgdY/Z4F9Z3SeN6ORZVqVKJS567MtERq+hkrKQGzTi5SE1pxExvzePFK+ EGSUOnjUwi6dYHOgReChRyHMq/hwXq/xVMv6WD1Q3KV/fscRajw/Xr2ZB9BXleSBnvrp F6UkJqTWAUn4lTv4pk21Mz8/PmoOA7nIhPfwyb/Qqv5tM5lxDCIb3x+IrQH69qT6+MoD gXhjEqKzlXQ+6SWQRV7ePdz92BGByKA3jcAo9vFsSIOJkDbZWh5odX1eieu/hj1c3oWt a6T9xbpkxxYR8L61xPhKMoiBoMXn0s+77cvB6I2/612J2AckEFNWgB/fIdYxJAf0/agX lU5A==
MIME-Version: 1.0
X-Received: by with SMTP id g79mr26644962yhi.86.1403832291161; Thu, 26 Jun 2014 18:24:51 -0700 (PDT)
Received: by with HTTP; Thu, 26 Jun 2014 18:24:51 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Thu, 26 Jun 2014 18:24:51 -0700
Message-ID: <>
From: Watson Ladd <>
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: Fri, 27 Jun 2014 01:24:54 -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.

And RC4 meets them? The fact is that we understand ECC very, very
well: the issues involved with changing curves are akin to those in
changing primes in Diffie-Hellman: most choices are terrible, but they
are easy to avoid. Furthermore, TLS has many options that are
little-used: I don't see the harm with adding another curve,
particularly when it will not be little used.

> There are also possible IPR issues, definite infrastructure issues (e.g. no
> off the shelf, commercial hardware or software AFAIK), documentation issues
> (not the base curve, but how to incorporate curve data into certificates and
> other protocol messages, and the fact it's key agreement only (vs the
> current EC curves which can be used for both signature and agreement).  A
> long list of items that probably, but not definitely, can be resolved.

IPR issues: Montgomery curves were developed in 1985. Any patents
would have expired in 2005.

The key agreement only issue doesn't affect the currently envisioned
use as a faster and more secure key
negotiation mechanism. There is a signature variant Ed25519, but yes,
this cannot go into x509 certificates right now,
and likely due to legacy software, for a long time.

As for software, there are many mature, well tested, and secure implementations.
> 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).   The argument against the "provably random" creation claim
> with respect to those curves appears to be that many "seed" values could
> have been generated to generate curve parameters and those curves tested to
> find "weak" curves of a particular flavor and the seeds for weak curves
> retained.  In other words, we don't know how the seed values were generated
> and it could be nefarious.  I haven't as yet found any argument against the
> generation process, nor specifically against the elliptic curve math.

Other than slow speed, exceptional cases, and primes that are painful
on 64 bit processors (P256 specific)
there are no problems. Oh, and the lack of point validation in some
widely deployed software.

> 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:
> 1) 20 organizations publicly contribute random/pseudo-random strings of
> 1kbits - they get to decide exactly which bits to send.
> 1a) discard any of these with detectable bias.
> 2) Randomly select 10 sets of contributed bits from those remaining (using
> public randomness sources to select those to be retained).
> 3) Concatenate the bits in a random order (using public randomness sources
> such as stock prices etc to select the order).
> 4) Run the concatenated data through an entropy extraction process (e.g.
> hash, hmac, other PRF) to produce a seed value of sufficient length. (or
> seed values if all the curves come from this one pass).
> 5) Generate the curve data and generator points from the seed.
> 6) Assign IETF OIDs to each curve generated this way.
> 7) Permanently record ALL the data used to generate the curves so we don't
> have future conspiracy theories.

What does this get us that Brainpool did not?

> 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.  I'd recommend that we generate curves
> equivalent in strength to the current NIST curves in all of prime, binary
> and koblitz flavors.

You do realize there is only koblitz curve for each binary field size, right?
For prime koblitz it's a similar story.

Why? What do these curves have to offer above Brainpool or NIST?
There's a strong case for including Curve25519 for performance and
implementation quality reasons. For another Weierstrass curve, those
don't exist.

Watson Ladd
> Mike
> _______________________________________________
> TLS mailing list

"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin