Re: [TLS] Testing consensus for adding curve25519 to the EC named curve registry

Douglas Stebila <> Mon, 09 September 2013 11:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5C8A311E81A8 for <>; Mon, 9 Sep 2013 04:09:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id L2W1pRs9EKnT for <>; Mon, 9 Sep 2013 04:09:04 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id DF3ED21E8187 for <>; Mon, 9 Sep 2013 04:08:20 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Mon, 9 Sep 2013 21:08:18 +1000
Received: from ([]) by ([]) with mapi; Mon, 9 Sep 2013 21:08:18 +1000
From: Douglas Stebila <>
To: Patrick Pelletier <>
Date: Mon, 9 Sep 2013 21:08:15 +1000
Thread-Topic: [TLS] Testing consensus for adding curve25519 to the EC named curve registry
Thread-Index: Ac6tTONQncniNwPBT/qxrsYMCNaYkg==
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US, en-AU
Content-Language: en-US
acceptlanguage: en-US, en-AU
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailman-Approved-At: Mon, 09 Sep 2013 08:04:25 -0700
Cc: "" <>
Subject: Re: [TLS] Testing consensus for adding curve25519 to the EC named curve registry
X-Mailman-Version: 2.1.12
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: Mon, 09 Sep 2013 11:09:16 -0000

Recent news has highlighted doubts on a particular elliptic curve-based pseudorandom number generation algorithm, Dual_EC_DRBG, in which a particular point is used for which no explanation is given on how the point was generated. If it was generated so that its discrete logarithm is known with respect to another point, then a backdoor exists that can recover the seed.  (

The NIST-standardized elliptic curves p256/p384/p512 are not related to this particular issue. 
- The prime p for each field has a special form chosen for efficiency (, not entirely unlike how the prime 2^155-19 was chosen for efficiency in curve25519.  There are no results that suggest that one prime is weaker than another prime for elliptic curve cryptography.
- The curve parameters were generated "verifiably at random", meaning a seed was chosen, and then the curve parameters a and b were generated by hashing the seed a pre-determined number of times using SHA-1.  (Appendix 4 of, or Section of SEC1, or ANSI X9.62)  
- I don't think it's specified how the generator was chosen, but the Diffie-Hellman problem is self-reducible, so there are no weak generators.

There are other reasons to support curve25519, including efficiency and resistance to side-channel attacks because constant-time implementations.  But not because of concerns over backdoors in p256/p384/p512.


On 2013-09-09, at 11:34 AM, Patrick Pelletier <> wrote:

> Given the doubt that's recently been cast on the NIST curves, is it time to revive the idea of adding curve25519 as a named curve?
> --Patrick
> On 3/1/10 4:20 PM, Adam Langley wrote:
>> We would like to start testing EC DHE in order to give our users
>> forward-secrecy.
>> In order to do this cheaply, one of the curves that we would like to
>> test with is curve25519[1]. There are several implementations of it
>> [2][3][4] and it's 3-4x faster than NIST's p256 (as implemented in
>> OpenSSL), while being constant-time.
>> Curve25519 doesn't currently appear on IANA's list of named curves[5]
>> and we would like to see it included.
>> As a first step I'd like to ask if there are any objections?
>> Cheers
>> AGL
>> [1]
>> [2]
>> [3]
>> [4]
>> [5]
> _______________________________________________
> TLS mailing list