Re: [Cfrg] revised requirements for new curves

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

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 812F71A8866 for <>; Mon, 8 Sep 2014 08:10:15 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id aZ6-FNF0fS-S for <>; Mon, 8 Sep 2014 08:10:12 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 948AF1A886E for <>; Mon, 8 Sep 2014 08:10:10 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1019.16; Mon, 8 Sep 2014 15:10:08 +0000
Received: from ([]) by ([]) with mapi id 15.00.1015.018; Mon, 8 Sep 2014 15:10:08 +0000
From: "Paterson, Kenny" <>
To: Stephen Farrell <>, "" <>
Thread-Topic: [Cfrg] revised requirements for new curves
Thread-Index: AQHPy07l29iFHJb+W02/iURsgQFUO5v3T7KAgAAYXYA=
Date: Mon, 08 Sep 2014 15:10:08 +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: 03283976A6
x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(199003)(189002)(24454002)(51444003)(479174003)(31966008)(79102001)(85306004)(46102001)(83506001)(74662001)(74482001)(106356001)(77982001)(105586002)(101416001)(2656002)(85852003)(106116001)(20776003)(74502001)(76482001)(107046002)(83322001)(99396002)(19580395003)(19580405001)(76176999)(54356999)(21056001)(90102001)(92566001)(95666004)(107886001)(2501002)(87936001)(66066001)(83072002)(4396001)(86362001)(80022001)(92726001)(81342001)(81542001)(97736003)(36756003)(50986999); DIR:OUT; SFP:; SCL:1; SRVR:DBXPR03MB384;; 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: Mon, 08 Sep 2014 15:10:15 -0000

Hi Stephen,

On 08/09/2014 15:42, "Stephen Farrell" <> wrote:

>Good job and good to see this progressing towards completion.
>Thanks for both.
>On 08/09/14 11:23, Paterson, Kenny wrote:
>> 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]
>A clarification question: the above reads a bit like the result
>has to be a curve that hasn't yet been documented. I assume that
>its ok if e.g. 25519 and/or one of msft's are picked and that this
>is not meant to rule those out.

That's correct - it's not meant to rule these out. The intention is that,
for a specific, existing curve like Curve25519 or one of the MSR curves,
this requirement would mean the publication of a clear selection rationale
and an evaluation of how much flexibility was exercised during the

>It might be worth stating that e.g.
>along the lines of "Note that SE5 does not rule out selection of
>an already documented curve or curves should there be consensus
>that this requirement has been met sufficiently."

OK, this could certainly be added.

>If you do mean to rule those out, then I think that really would
>need to be crystal clear.
>Other than that:
>On IN1 and IN2 I agree with William's comment. And since that
>is to the effect that those don't help or hinder selections
>I'm ok with the text as-is.

OK, good to know.

>On IP1, I do agree with the intent, but that might need to be
>reworded to keep everyone happy - one can never know for sure
>that royalty-free anything is possible. But I'm ok with the
>wording as-is, since adding the equivalent of "as far as its
>possible to know" doesn't matter so much given that CFRG cannot
>afaik yet do the impossible;-)

Understood. So some fine-tuning might be merited here.