Re: [Cfrg] revised requirements for new curves

"Paterson, Kenny" <> Tue, 09 September 2014 18:54 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id DEF661A00C2 for <>; Tue, 9 Sep 2014 11:54:33 -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 P9OxP7Q9-68E for <>; Tue, 9 Sep 2014 11:54:31 -0700 (PDT)
Received: from ( [IPv6:2a01:111:f400:fe00::697]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B6A111A0099 for <>; Tue, 9 Sep 2014 11:54:30 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1015.19; Tue, 9 Sep 2014 18:54:07 +0000
Received: from ([]) by ([]) with mapi id 15.00.1015.018; Tue, 9 Sep 2014 18:54:07 +0000
From: "Paterson, Kenny" <>
To: "D. J. Bernstein" <>, "" <>
Thread-Topic: [Cfrg] revised requirements for new curves
Thread-Index: AQHPy07l29iFHJb+W02/iURsgQFUO5v3kQSAgAGn9YA=
Date: Tue, 09 Sep 2014 18:54:06 +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: 0329B15C8A
x-forefront-antispam-report: SFV:NSPM; SFS:(10009018)(6009001)(24454002)(51704005)(479174003)(199003)(189002)(54356999)(90102001)(86362001)(19580395003)(85852003)(76176999)(2656002)(99396002)(50986999)(46102001)(74662001)(64706001)(80022001)(15975445006)(97736003)(15202345003)(74502001)(2501002)(20776003)(92566001)(92726001)(77982001)(83506001)(85306004)(83072002)(74482001)(21056001)(101416001)(36756003)(31966008)(83322001)(107886001)(107046002)(76482001)(105586002)(106116001)(4396001)(66066001)(87936001)(81342001)(79102001)(81542001)(19580405001)(95666004)(106356001); 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: Tue, 09 Sep 2014 18:54:34 -0000



On 08/09/2014 19:36, "D. J. Bernstein" <> wrote:

>I have two clarification questions regarding SE6:
>> 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]
>Background for question 1: E-521 was proposed by three teams
>independently. It appears to be faster on typical platforms than
>Microsoft's 2^512-569, despite the higher security level. It's also
>supported by various arguments from other people, such as "a lot of
>effort has gone into optimization of modular reduction for the NIST
>primes". E-521 reuses the NIST P-521 prime, the only NIST prime that's
>immune to Adam Langley's "What a difference a prime makes" critique.
>Question 1: Does SE6 formally exclude E-521 as being above the "commonly
>understood" 256-bit security level?

Let me restate SE6 here and than answer your question.

"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]"

Answer to your first question: no. Because if we adopt this requirement
then we would still need to reach consensus on the exact meaning of "match
to a good approximation". I've made a suggestion for this in my covering
rationale, but, recognising the "[NC]" status of this requirement, I
consider it in need of further discussion.

>Background for question 2: There are also proposals for faster 414-bit
>and 448-bit curves. This intermediate range is backed by a variety of
>arguments from a variety of people: e.g., clear improvements over the
>larger option in Suite B (NIST P-384 with AES-256); deployment by Silent
>Circle; and the argument "What benefit do you derive from including a
>stronger algorithm in a chain made of weaker algorithms?" combined with
>undisputed evaluations of the AES-256 security level.
>Question 2: Does SE6 formally exclude Curve41417 etc. as being above the
>"commonly understood" 192-bit security level but below the "commonly
>understood" 256-bit security level?

Again, no, not formally, but here I think it'd be harder to argue for
"match to a good approximation".



>Cfrg mailing list