Re: [Cfrg] revised requirements for new curves

"Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk> Tue, 09 September 2014 18:54 UTC

Return-Path: <Kenny.Paterson@rhul.ac.uk>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEF661A00C2 for <cfrg@ietfa.amsl.com>; Tue, 9 Sep 2014 11:54:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P9OxP7Q9-68E for <cfrg@ietfa.amsl.com>; Tue, 9 Sep 2014 11:54:31 -0700 (PDT)
Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0697.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::697]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6A111A0099 for <cfrg@irtf.org>; Tue, 9 Sep 2014 11:54:30 -0700 (PDT)
Received: from DBXPR03MB383.eurprd03.prod.outlook.com (10.141.10.15) by DBXPR03MB383.eurprd03.prod.outlook.com (10.141.10.15) with Microsoft SMTP Server (TLS) id 15.0.1015.19; Tue, 9 Sep 2014 18:54:07 +0000
Received: from DBXPR03MB383.eurprd03.prod.outlook.com ([10.141.10.15]) by DBXPR03MB383.eurprd03.prod.outlook.com ([10.141.10.15]) with mapi id 15.00.1015.018; Tue, 9 Sep 2014 18:54:07 +0000
From: "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk>
To: "D. J. Bernstein" <djb@cr.yp.to>, "cfrg@irtf.org" <cfrg@irtf.org>
Thread-Topic: [Cfrg] revised requirements for new curves
Thread-Index: AQHPy07l29iFHJb+W02/iURsgQFUO5v3kQSAgAGn9YA=
Date: Tue, 9 Sep 2014 18:54:06 +0000
Message-ID: <D034FCFB.2CA7B%kenny.paterson@rhul.ac.uk>
References: <D0333B6F.2C8CF%kenny.paterson@rhul.ac.uk> <20140908183635.18192.qmail@cr.yp.to>
In-Reply-To: <20140908183635.18192.qmail@cr.yp.to>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.4.3.140616
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [92.4.67.211]
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; H:DBXPR03MB383.eurprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
Content-Type: text/plain; charset="us-ascii"
Content-ID: <9EA01318C33B044A9E15013377CC758D@eurprd03.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: rhul.ac.uk
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/ikEN9SbKT4EiDXIz_7SuZKOnEIA
Subject: Re: [Cfrg] revised requirements for new curves
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Sep 2014 18:54:34 -0000

Hi

In-line.

On 08/09/2014 19:36, "D. J. Bernstein" <djb@cr.yp.to> 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".

Cheers

Kenny 


>
>---Dan
>
>_______________________________________________
>Cfrg mailing list
>Cfrg@irtf.org
>http://www.irtf.org/mailman/listinfo/cfrg