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

Hanno Böck <> Thu, 26 June 2014 22:13 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 835661B2EDD for <>; Thu, 26 Jun 2014 15:13:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.898
X-Spam-Level: *
X-Spam-Status: No, score=1.898 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, MANGLED_BACK=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Xb4NZFer_2Fy for <>; Thu, 26 Jun 2014 15:13:07 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 95FCD1A050E for <>; Thu, 26 Jun 2014 15:13:07 -0700 (PDT)
Received: from localhost ( [::ffff:]) (AUTH: LOGIN, TLS: TLSv1/SSLv3, 128bits, AES128-SHA) by with ESMTPSA; Fri, 27 Jun 2014 00:13:05 +0200 id 000000000000002E.0000000053AC9AF1.00003F38
Date: Fri, 27 Jun 2014 00:12:15 +0200
From: Hanno =?UTF-8?B?QsO2Y2s=?= <>
Message-ID: <>
In-Reply-To: <>
References: <>
X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.23; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary=""
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:13:10 -0000

On Thu, 26 Jun 2014 17:59:20 -0400
Michael StJohns <> wrote:

> 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.

I think another major argument against NIST curves was that it's hard
to implement them in constant time. DJB had this and other issues
explained in a blog post [1].

As we saw a lot of timing attacks lately (Lucky Thirteen, Comeback of
Bleichenbacher attack in Java and OpenSSL) and I'd expect we'll see
more of that I think timing safety should be a crucial feature of all
future TLS algorithms.


Hanno Böck