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

Dan Brown <> Tue, 10 September 2013 01:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A3B3111E816D for <>; Mon, 9 Sep 2013 18:22:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ED-GXs6dhGX9 for <>; Mon, 9 Sep 2013 18:22:55 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5DA6811E813D for <>; Mon, 9 Sep 2013 18:22:51 -0700 (PDT)
X-AuditID: 0a412830-b7f576d00000095e-78-522e74639fc5
Received: from ( []) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by (SBG) with SMTP id 88.15.02398.3647E225; Mon, 9 Sep 2013 20:22:43 -0500 (CDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Mon, 9 Sep 2013 21:22:42 -0400
Received: from ([fe80::24f3:cc30:b596:7ca0]) by ([::1]) with mapi id 14.03.0123.003; Mon, 9 Sep 2013 21:22:42 -0400
From: Dan Brown <>
To: Douglas Stebila <>, Nick Mathewson <>
Thread-Topic: [TLS] Testing consensus for adding curve25519 to the EC named curve registry
Thread-Index: AQHOrPzUSgKBdqWRokmt5ggMXGJ/7Zm9g/qAgABVnwCAAHtwAIAAHIYA
Date: Tue, 10 Sep 2013 01:22:41 +0000
Message-ID: <>
References: <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-CA, en-US
Content-Language: en-CA
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
content-transfer-encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrIKsWRmVeSWpSXmKPExsXC5bjwtG5yiV6QwZ8XkhYXjm5gtzi36T2T xafzXYwOzB5Llvxk8tiz/gubx+b1l9kCmKMaGG0S8/LySxJLUhVSUouTbZV8UtMTcxQCijLL EpMrFVwyi5NzEjNzU4uUFDJTbJVMlBQKchKTU3NT80pslRILClLzUpTsuBQwgA1QWWaeQmpe cn5KZl66rZJnsL+uhYWppa6hkp0uEkj4x53xrXsKc8Ec5Yr55+QaGFcodTFyckgImEg0Hz/D DmGLSVy4t56ti5GLQ0ignUni0fxuRghnBaPE+ZcXWSCc2YwSJ/5vZgNpYRNQlbh/9BxzFyMH h4hAoMSEK1YgYWYBRYn3l+axgNjCAtESv/43MYHYIgIxEmv/rIEqd5O4sa0axGQBmnJsYRhI Ba+AjcStSS9YITYtZJJ4+L0ZbBOngJ3Eh0e7wUYyCshK7D57nQlilbjEvvm7mSEeEJBYsuc8 lC0q8fLxP1aQ+cwCmhLrd+lDlJtJ7Do6iRnmyindD9kh9gpKnJz5BGy8kICCxJXr+1gmMErM QrJhFsKkWUgmzUIyaRaSSQsYWVcxCuZmFBuYGSbnJesVZebq5aWWbGIEJx8Ngx2M799bHGIU 4GBU4uHl8NMLEmJNLCuuzD3EKMHBrCTCu4EZKMSbklhZlVqUH19UmpNafIjRFRhWE5mluJPz gYkxryTe2MAAN0dJnNdV5UOgkEA6MNllp6YWpBbBzGHi4JRqYNz7+dtipq3rJTd0XuNdE/+i 5PaCe6daqvxn6O3muGgq9HyRSkdH4m8PQeaObzkS5q2KgpPe+Z9hlX90W+JezwV3/n21X5Y8 PXt030yJE1rTkmRLYnSjVhpIfzu4s3dtd+0Ge8sdZaseGv0/vO39pyeP7c3KJeptzecc/KzD bVhw6MnFxphvzbOVWIozEg21mIuKEwHtQg1eZAMAAA==
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: Tue, 10 Sep 2013 01:22:58 -0000

I'm the current editor of ANSI X9.62 and X9.63, but joined X9F1 a little later than the‎ time in question, so am not the best historical source.

‎Anyway, I had thought the 15 NIST curves were included in ANSI X9.63 in 2001, but most were not in X9.62 in its first 1998 version, and only added in the 2005 version.

The curve seed sources were not documented in ANSI or NIST docs. I've wondered about it a few times, but could never see a concrete problem. At least intuitively, it would only be a problem if:

1) a large fraction of elliptic curves were weak, or

2) sha1 preimages are easy to find and some unknown but rare class of elliptic curves are weak.

‎Both of these would undermine more than just the curve choice, and seem extremely unlikely.

An alternative would have been to select the seeds in a canonical way, eg as the smallest integer above some math constant causing the curve generated via the hash to be good. In this case, the curve could be said to be pseudorandom‎, but not random.

I welcome any points or info I've missed, and will gladly forward to the rest of X9F1.


The generators for the NIST curves are not verifiably random, but X9.62-2005 added a method to generate them that way, for new curves or algorithms (eg X9.92 uses this method).

ECDSA does not share the random self-reducibility property with ECDH‎, hence the check that r is not zero (and vr gens for new curves to supplement the r check ).


The ECRNG standards in question do have options for users to select verifiably random constants, which removes any doubts, unless sha512 is weak.

Given the importance of key generation, some might consider the cost of using an ECRNG. Others just need keys faster. Hence the options in standards, eg HMAC and AES based RNGs.

Sent from my BlackBerry 10 smartphone on the Rogers network.
From: Douglas Stebila
Sent: Monday, September 9, 2013 7:41 PM
To: Nick Mathewson
Subject: Re: [TLS] Testing consensus for adding curve25519 to the EC named curve registry

On 2013/09/10, at 02:18, Nick Mathewson <> wrote:

> On Mon, Sep 9, 2013 at 7:12 AM, Douglas Stebila <> wrote:
> [...]
>> - 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)
> A possibly foolish question, but I couldn't find the answer in any of
> the documents you listed:
> Is it documented how the seeds were chosen?

I haven't found any information on how the seeds were chosen. The earliest reference I have listing the seeds is a September 1998 draft of ANSI X9.62, a copy of which is available here:, but this provides no reason for the choice of seeds. Maybe there's someone from X9F on this mailing list who has some historical insight?


TLS mailing list

This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.