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

Nick Mathewson <> Wed, 11 September 2013 15:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A2CCE21E8118 for <>; Wed, 11 Sep 2013 08:10:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3DNOzKCeTXEi for <>; Wed, 11 Sep 2013 08:10:25 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c02::230]) by (Postfix) with ESMTP id 1C1B711E81B3 for <>; Wed, 11 Sep 2013 08:10:24 -0700 (PDT)
Received: by with SMTP id nd7so4518517qeb.21 for <>; Wed, 11 Sep 2013 08:10:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=ldjMmi/gC69s9X66kpD9oge2Ky+yVpS8UKitQM0Mmlc=; b=E0opElzNAma0ZqATe3ZA/PWwI3b9LjA3ZXbJBagNmLAb8veGALGZiVj6uWJwhNZmfS qc9pIxWjpNorI9p3N5bInw0nKaVPCKl8EBK/fnsib6Z8564M1d7NBG9yg5mRdQk3Cxkb 0veAryAACQEnHSK1Y8IQVvozjKRcpuWgOL+/vOgDDj/CecvbFEuBoqCYFxRnINlpSKUu SwjQHMav6p1xbizWTkDs+eMsDzfkkkNkXxTKkyIsOUUJUOlxTjYJWfrXyDktMGbMzazo 4I+XhduI13SVdwwSELm0DA9RFhLR3UnbvuX8Kr9O65352xLg83hdav9u7qEOuu7NNDnI mw5A==
MIME-Version: 1.0
X-Received: by with SMTP id 9mr3920832qei.51.1378912224515; Wed, 11 Sep 2013 08:10:24 -0700 (PDT)
Received: by with HTTP; Wed, 11 Sep 2013 08:10:24 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <>
Date: Wed, 11 Sep 2013 11:10:24 -0400
X-Google-Sender-Auth: tuRikIhrx4iarglgWAPMaK4tkVY
Message-ID: <>
From: Nick Mathewson <>
To: Dan Brown <>
Content-Type: text/plain; charset="ISO-8859-1"
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: Wed, 11 Sep 2013 15:10:25 -0000

On Mon, Sep 9, 2013 at 9:22 PM, Dan Brown <> wrote:
> 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.

That's true, so long as "large fraction" and "rare" are defined
appropriately.  But I think what most of the people who worry about
this are worried about is something like:

3) A small-ish fraction of elliptic curves (say, one in every
quadrillion or quintillion or so) has some as-yet-unknown weakness,
and building a sha1 brute-forcing engine to find seeds that would
produce such curves was economically viable the late 1990s.

After a little time investigating SHA1 speeds on late-1990s FPGAs,
special-purpose chips, and general purpose CPUs, a
back-of-the-envelope calculation suggests that, given about ten
million dollars of hardware and about half a year's worth of
processing time, searching quintillions of seeds to find curves with
desired properties wouldn't have been unrealistic.

Now, none of this means that the seeds in question actually _were_
chosen in any hostile way, of course. But it would make it more
comforting if anybody could point out where the seeds actually came

best wishes,
Nick Mathewson