Re: [Cfrg] generic curves ... RE: big-endian short-Weierstrass please

"Paterson, Kenny" <> Tue, 03 February 2015 17:42 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1AEA51A7030 for <>; Tue, 3 Feb 2015 09:42:47 -0800 (PST)
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 n77ZEpL7rokG for <>; Tue, 3 Feb 2015 09:42:39 -0800 (PST)
Received: from ( [IPv6:2a01:111:f400:fe00::661]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4A1471A1BAF for <>; Tue, 3 Feb 2015 09:39:54 -0800 (PST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Tue, 3 Feb 2015 17:39:30 +0000
Received: from ([]) by ([]) with mapi id 15.01.0075.002; Tue, 3 Feb 2015 17:39:30 +0000
From: "Paterson, Kenny" <>
To: Watson Ladd <>, Kurt Roeckx <>
Thread-Topic: [Cfrg] generic curves ... RE: big-endian short-Weierstrass please
Thread-Index: AQHQP9hdoSfMzYiUAU2nTDUuGEdzxA==
Date: Tue, 03 Feb 2015 17:39:30 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-GB, en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
authentication-results:; dkim=none (message not signed) header.d=none;
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DBXPR03MB381;
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:DBXPR03MB381;
x-forefront-prvs: 0476D4AB88
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(479174004)(377454003)(51704005)(24454002)(2900100001)(92566002)(2950100001)(76176999)(54356999)(50986999)(86362001)(77096005)(102836002)(87936001)(106116001)(2656002)(15975445007)(19580405001)(19580395003)(66066001)(83506001)(46102003)(74482002)(36756003)(122556002)(40100003)(62966003)(77156002)(41533002); DIR:OUT; SFP:1101; SCL:1; SRVR:DBXPR03MB381;; FPR:; SPF:None; MLV:sfv; LANG:en;
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Feb 2015 17:39:30.6190 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR03MB381
Archived-At: <>
Cc: Dan Brown <>, "" <>
Subject: Re: [Cfrg] generic curves ... RE: big-endian short-Weierstrass please
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, 03 Feb 2015 17:42:47 -0000

Dear Watson,

On 03/02/2015 16:50, "Watson Ladd" <> wrote:

>On Mon, Feb 2, 2015 at 2:29 PM, Kurt Roeckx <> wrote:
>> On Thu, Jan 29, 2015 at 10:09:18PM +0000, Dan Brown wrote:
>>> New thread name ... should have done so earlier.
>>> When TLS asked CFRG for new curves, I didn't interpret that to mean
>>> generic curves would be banned. Banishing generic curves adds slightly
>>> weight to the TLS request, because users cannot easily opt out of the
>>> few elite curves.
>> If it's unclear what the TLS WG wants exactly, maybe it's best to
>> ask them?
>> My understanding is that they want fixed named curves.
>Let me get this right:
>There are no security concerns with Curve25519.

That is the consensus.

>For the entire 12 months we've been piddling away, we could have
>written Curve25519 in Weierstrass form, and the TLS specification
>would already have included it as an option.

It could, but then we would not have delivered what we were asked to
deliver by TLS WG. That was: to recommend curve or curves (and by
implication, algorithms using those curves) at a variety of security
levels. That required a more considered evaluation of the broader space,
not a single recommendation on Curve25519.

>We've still got signatures and the choice of primes at higher security
>levels to worry about, with about 10 emails total on these topics.

If you take the total discussion we've had over the last 9 months, then
there's significantly more than 10 e-mails. I think this has established a
pretty good understanding in the RG around the key issues. Making progress
should not require rehashing all of that (please!).

>Instead we've spent 90+ emails debating whether an opaque byte vector
>should be big or little endian, after the TLS WG already had this

Did you count how many of those 90+ e-mails you sent yourself? On a blog
post elsewhere [1], you describe CFRG as being "more dysfunctional than
usual". I suggest it's incumbent on you to reflect carefully on the
reasons why that might be....

>We've exceeded a previously announced deadline by a month. We're still
>picking editors for a draft that has a hard deadline coming up in
>March (several hard deadlines),

The editors are in place. The chairs needed some time to appoint the
editors because of the initial document from Adam essentially being a
merge of other authors' documents.

>despite dropping several deliverables
>to make it, and knowing that X25519 is going to be what is in the
>eventual RFC.

It's not. It's going to be part of it, but we need more than X25519 to
meet the request from the TLS WG.

Right now, Alexey is out of action, but as soon as he is back, the chairs
will be moving the technical discussion forward and seeking consensus on
the key issues that still face us before we can deliver to TLS WG.

More soon.