Re: [Cfrg] revised requirements for new curves

"Paterson, Kenny" <> Wed, 10 September 2014 10:15 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 293131A06DA for <>; Wed, 10 Sep 2014 03:15:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id If3aytowQr0t for <>; Wed, 10 Sep 2014 03:15:43 -0700 (PDT)
Received: from ( [IPv6:2a01:111:f400:fe00::689]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 89D431A06DE for <>; Wed, 10 Sep 2014 03:15:42 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1015.19; Wed, 10 Sep 2014 10:15:19 +0000
Received: from ([]) by ([]) with mapi id 15.00.1015.018; Wed, 10 Sep 2014 10:15:19 +0000
From: "Paterson, Kenny" <>
To: Adam Langley <>, "" <>
Thread-Topic: [Cfrg] revised requirements for new curves
Thread-Index: AQHPzGvd29iFHJb+W02/iURsgQFUO5v6OCGA
Date: Wed, 10 Sep 2014 10:15:19 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-GB, en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:;
x-forefront-prvs: 033054F29A
x-forefront-antispam-report: SFV:NSPM; SFS:(10009019)(6009001)(199003)(479174003)(189002)(24454002)(51444003)(51704005)(52604005)(76482001)(105586002)(31966008)(107046002)(19580405001)(107886001)(95666004)(106356001)(4396001)(106116001)(81542001)(87936001)(81342001)(66066001)(99396002)(79102001)(36756003)(64706001)(15975445006)(76176999)(74662001)(46102001)(80022001)(50986999)(97736003)(86362001)(90102001)(54356999)(85852003)(19580395003)(85306004)(21056001)(101416001)(2656002)(83072002)(83322001)(83506001)(15202345003)(20776003)(74502001)(2501002)(92566001)(74482001)(92726001)(77982001); DIR:OUT; SFP:1101; SCL:1; SRVR:DBXPR03MB383;; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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 10:15:45 -0000


Thanks for interrupting your holiday to participate in this discussion.

On 09/09/2014 21:23, "Adam Langley" <> wrote:

>(I'm commenting with my Google hat on. I'm on vacation at the moment
>and haven't circulated this around internally but I believe that this
>reflects our position. Where I'm less sure I've used "I".)
>> SE5. Required: each set of curve parameters should be generated by a
>> well-defined procedure that allows only a limited and quantified amount
>> flexibility. If the selected procedure involves the choice of an initial
>> seed, then the seed will be selected by multiple independent parties
>> a procedure having the property that no collusion of all but one or
>> of the parties can exert any control over the chosen seed. [RC]
>Although flexibility should be eliminated where possible, we believe
>that forgoing sensible optimisations because of a fear that someone
>might know a magic attack on a subset of curves and might be guiding
>the selection them that would be a mistake. We are not looking for a
>replacement for P-256 because we seriously worry that the NSA
>backdoored it. We're looking for a replacement because we think that
>we can get something much faster and simpler.
>Past a point, constraining the curve based on that fear isn't valuable to

It's good to get Google's view on what is the main driver for this

>> SE6. Required: the selected curves should provide levels of security
>> match to a good approximation 128-bit, 192-bit and 256-bit security
>> levels, as these levels are currently commonly understood in the wider
>> security community. [NC]
>We don't want three curves. I'm not completely convinced that we even
>want two, but two is plausible. For symmetric primitives, matching
>powers of two makes sense because it fits well with software
>implementation. For curves that motivation is much weaker.

Should we infer, then, that Google would prefer at most a single curve at
each security level (rather than, say, two)?

>Above the 120ish bit level one is no longer fighting stronger
>attackers, but hedging against a breakthrough (but not too much of
>one). Matching 192 or 256 bit security levels is a *misunderstanding*
>in the wider community, and is thus of the lowest priority.
>> IP2. Desired: securely, simply and efficiently implementable world-wide
>> a patent-free manner. [RC]
>This is probably a requirement for us, unless the "royalty-free" was
>legally strong, didn't include registration etc. I cannot specify
>exactly what we would require in that case because it's not my area.


>> IN2. Required: minimise work needed to generate suitable OBJECT
>> IDENTIFIERs for Subject Public Key Information Fields, as defined in RFC
>> 5480 (PKIX). [C]
>I don't think that I understand what this means, or rather, I can't
>imagine how a curve could fail it. By having a name so long that it
>caused tooling problems perhaps?

William Whyte pointed out more or less the same thing. This was intended
more as a placeholder to remind us that we will have some PKIX work to do,
and as a contrast to the starting requirements (from David McGrew) which
looked more onerous (to me) at first. Some rewording of this requirement
would clearly be helpful.

>> IN2. Desired: usable with minimal changes to existing IETF RFCs for CMS,
>> SSH, IKE, IKEv2, Kerberos PKINIT. [RC]
>The cost of making a change in these systems is largely fixed. I think
>that trading off too much to make the change smaller is often a false
>economy. If the thinking here was to try and reuse ECDSA with new
>curves for reasons of easy of patching then I think that would be an
>example of such a false economy.

Thanks for sharing this perspective. My feeling is that a bit more work is
needed (possibly by me, but maybe others already did it) to dig into these
RFCs and see what work would be implied with different levels of change to
curves and algorithms.

Enjoy the rest of your holiday,



>Adam Langley
>Cfrg mailing list