Re: [Cfrg] revised requirements for new curves

Adam Langley <> Tue, 09 September 2014 20:23 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4D9031A010A for <>; Tue, 9 Sep 2014 13:23:13 -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 LufmNyl2zrFo for <>; Tue, 9 Sep 2014 13:23:11 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 081151A00FA for <>; Tue, 9 Sep 2014 13:23:09 -0700 (PDT)
Received: by with SMTP id q1so605151lam.20 for <>; Tue, 09 Sep 2014 13:23:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=TmF9kXlfw1Gy4iEOaPHTF3+uVpF0zdy7v0Vz8lMbmm0=; b=Z+t9yVF60QPj0X3b6nxvQIq/0WZ2XN883JgSpP5BaMaaPmSrRIHM1mFn3h43pfosNY t+RTd/xhwLFE7zW69ggT/3b/+gp1hOjn58gR1FKnfj9A3cGeXUkXNRM5BZw1xpI1QqNH M2fCIWx9xBuTATBiC2Yuy7JglV1JKVaeJ4lQBroijcwEOsCVwSsv3lcvC8F0JEqZDnD+ k5odDPHm6oEQ36z0tFo3Jedw6kQwrysMA8SYhpgy0M8HmpYZlrGv8iQhSBQr95hVrQjh UXt14PTxPZo62we6dp2IE1FiWXXtd8Vhllugvtq08EkfK0Jcz9gzJMG5L9lk3CtG/ink 1gdA==
MIME-Version: 1.0
X-Received: by with SMTP id pv6mr4522225lbb.105.1410294186771; Tue, 09 Sep 2014 13:23:06 -0700 (PDT)
Received: by with HTTP; Tue, 9 Sep 2014 13:23:06 -0700 (PDT)
Date: Tue, 09 Sep 2014 13:23:06 -0700
X-Google-Sender-Auth: BGh18AUVH6V6mk0SK7xKwgoCU3w
Message-ID: <>
From: Adam Langley <>
Content-Type: text/plain; charset="UTF-8"
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: Tue, 09 Sep 2014 20:23:13 -0000

(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 of
> flexibility. If the selected procedure involves the choice of an initial
> seed, then the seed will be selected by multiple independent parties using
> a procedure having the property that no collusion of all but one or fewer
> 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 us.

> SE6. Required: the selected curves should provide levels of security that
> 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.

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 in
> 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?

> 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.



Adam Langley