Re: [Cfrg] Rerun: Elliptic Curves - preferred curves around 256bit work factor (ends on March 3rd)

Phillip Hallam-Baker <> Wed, 25 February 2015 15:28 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B13B01A03A1 for <>; Wed, 25 Feb 2015 07:28:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.123
X-Spam-Status: No, score=0.123 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YK-UpkZ587gk for <>; Wed, 25 Feb 2015 07:28:56 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4010:c03::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5A5BF1A19F4 for <>; Wed, 25 Feb 2015 07:28:52 -0800 (PST)
Received: by labhs14 with SMTP id hs14so4664136lab.1 for <>; Wed, 25 Feb 2015 07:28:50 -0800 (PST)
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=PXKtwiVcD4gmKW9etoMCHdsen3iwbrSRNJ5cW9mvx1g=; b=KmcnlU1BDbUZSEFOhvjrI3QOS5E5CrKsVfmu5wHr9GdGhmMkrRyMIwVBbIoJmtraw1 3Dte+8TA91fhaogs72MME/mDQALC45L7SP7IkrdRfpCTmU8sIXuG/8M0z1eLLu+kNJn/ FYWQ1NDrj7PUeGrlmbu7qZOHJGqEy9Lmy8a5FWrvLW+Y6xE2yR00tG7nRl9Jv4DaFGDR 8SIzLQshtxv8vSwwtK+WScaiWKgfC5AQh6iZCa3utrsglqa0gnMwCUnbafuNSdvn9voa l3bpru7ZTY/SS1HrpuGM2cmj8iCszSeh4bMwuaPLXkD4Wo5RzaECyHwQ9prDRap5zdVa Ucvw==
MIME-Version: 1.0
X-Received: by with SMTP id ti2mr3315476lbb.124.1424878130688; Wed, 25 Feb 2015 07:28:50 -0800 (PST)
Received: by with HTTP; Wed, 25 Feb 2015 07:28:50 -0800 (PST)
In-Reply-To: <>
References: <>
Date: Wed, 25 Feb 2015 10:28:50 -0500
X-Google-Sender-Auth: QZCVMznxpKiB7elTWN6xlDuYip0
Message-ID: <>
From: Phillip Hallam-Baker <>
To: Alexey Melnikov <>
Content-Type: multipart/alternative; boundary="047d7b3a8690d3fb33050feb4a39"
Archived-At: <>
Cc: "" <>
Subject: Re: [Cfrg] Rerun: Elliptic Curves - preferred curves around 256bit work factor (ends on March 3rd)
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, 25 Feb 2015 15:28:57 -0000

On Wed, Feb 25, 2015 at 9:27 AM, Alexey Melnikov <>

> CFRG chairs are starting another poll:
> Q3: This is a Quaker poll (please answer one of "preferred", "acceptable"
> or "no") for each curve specified below:
> 1) 448 (Goldilocks)
> 2) 480
> 3) 521
> 4) other curve (please name another curve that you "prefer" or "accept",
> or state "no")
> If you stated your curve preferences in the poll that ended on February
> 23rd (see the attachment), you don't need to reply to this poll, your
> opinion is already recorded. But please double check what chairs recorded
> (see the attachment).
> If you changed your mind or only answered the question about performance
> versa memory usage for curves 512 and 521, feel free to reply.

521 Preferred
480 OK-ish
448 Not acceptable

My problem with 521 versus 512 is the oddness factor. What I want to be
able to do is to be able to carry the argument that the IETF has specified
the best performance curve and the best security curve.

I don't want to have 20+2 curves as a result of this process, I want 2
curves and use them for absolutely everything without exception. One of the
reasons RSA is so dominant is that as far as developers are concerned, RSA
is RSA. You don't need to have an expert to pick between two dozen
different flavors.

One piece of data I had not been aware of is that NIST actually proposed
some 521 curves back in the day though not in suite B.. While not endorsing
their specific curves, it does provide a data point and an argument against

Let us imagine that you are deciding between the IETF curve and the NIST
521 curve

If the IETF curve is 521, then we win against the NIST curve on performance.

If the IETF curve is 512. The NIST curve has 16 times the work factor so it
is a little stronger. So we would be arguing higher performance against
their random prime curve. It is a colorable argument but more folk know who
NIST are than IETF. We can only really win the argument if NIST agrees to
let us. And that would take them a year or more.

If the IETF curve is 480 then we are much less secure. We are giving up
2^30 worth of work factor, a billion times. Now even though we are talking
a billion, billion, billion, billion, billion, billion, billion, billion,
versus a billion, billion, billion, billion, billion, billion, billion,
billion, billion, we are still talking about a factor of a billion.

If the IETF curve is 448 then we are giving up a billion billion times the
work factor.

My desired outcomes here are

1) NIST recommends our new curves
2) NIST recommends our new curves as preferred

If we go for 512 then we might get 2 but it is a somewhat harder sell. I
can't see us winning that argument for Riding Hood (480) or Goldilocks (448)