Re: [Cfrg] revised requirements for new curves

Adam Langley <> Wed, 10 September 2014 16:53 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 020221A8A7F for <>; Wed, 10 Sep 2014 09:53:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JGgaTbAUYpU3 for <>; Wed, 10 Sep 2014 09:53:01 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6A26E1A8A80 for <>; Wed, 10 Sep 2014 09:53:01 -0700 (PDT)
Received: by with SMTP id el20so1348752lab.33 for <>; Wed, 10 Sep 2014 09:52:59 -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=4/MGuC6tM+aooKCx3zSOtqiX28uCtZQY/B/PSQRSrjY=; b=H9lDhvKBGKcOBGgyLG2by0dyHFiAjsBNNNAsgbLuhhQdDiE7EzNcsMJOjYRoKoRZsm IQ/xj2gMoyF1PQvUOWdS5vrpzhmcd6niPUX4Haj+YCgSZzzRvk5SnKIr/lgKMecGiAOP jsPtzvyrcAhtgG0Iw6ps6rOi/3I6JKrMJNFI6lESDcm/R+WM6PnbE3IVmUF0Z9+w63Om PrwoSDPWoCkcOpi33I7est2BYXVYSL8jYqsvyOZL8BaGS/5t0OzsEkOl39DXLeeJ8DhE jIhZf23dcdfGCBAc201nfhbR41h+RXEmXNVfvRco+P7VSCMmcuaD0vFYt1DoBAFm3sg6 TG6g==
MIME-Version: 1.0
X-Received: by with SMTP id pv6mr3423815lbb.105.1410367979357; Wed, 10 Sep 2014 09:52:59 -0700 (PDT)
Received: by with HTTP; Wed, 10 Sep 2014 09:52:59 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Wed, 10 Sep 2014 09:52:59 -0700
X-Google-Sender-Auth: 3-42D_3XcnhD6Rj6RLELa-gavgQ
Message-ID: <>
From: Adam Langley <>
To: "Paterson, Kenny" <>
Content-Type: text/plain; charset="UTF-8"
Cc: "" <>
Subject: Re: [Cfrg] revised requirements for new curves
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 10 Sep 2014 16:53:03 -0000

On Wed, Sep 10, 2014 at 3:15 AM, Paterson, Kenny
<> wrote:
> Should we infer, then, that Google would prefer at most a single curve at
> each security level (rather than, say, two)?

I was suggesting that only one or two curves be approved in total.

Consider the current situation: in terms of having a good
implementation base, P-{256|384|521} are significantly above the rest.
Of those, P-256 is the workhorse. There is some use of P-384,
generally, from what I've seen, for long-lived ECDSA keys (with
dubious justification). P-521 is hugely less common than either of the
other two.

In order to get a performant, solidly constant-time implementation,
one needs, in practice, to hand craft the field operations for an
elliptic curve, which is quite a lot of work. That's been done for
P-256 in many cases, but much less so for P-384. (Since P-384 is
substantially used for ECDSA verification, constant-time is less of a
worry there.)

Diversity of curves dilutes the capacity for building, auditing and
verifying good implementations. Also, the precomputed tables for high
speed signing take too much space in some clients if there are several
of them, and then implementations need to support and test two build
modes: fast and small.

Many systems will never be able to drop support for P-256 and 384, so
these new curves can only add to the implementation burden. I think
that a single curve to replace P-256 can pay its way by being faster
and simpler. I'm much less sure about a second, and pretty confidently
against a third.