Re: [Cfrg] When's the decision?

Mike Hamburg <> Thu, 09 October 2014 03:42 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 05FC31A8AD8 for <>; Wed, 8 Oct 2014 20:42:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.555
X-Spam-Level: *
X-Spam-Status: No, score=1.555 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.982, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0bEhhwxO5hrG for <>; Wed, 8 Oct 2014 20:42:33 -0700 (PDT)
Received: from ( []) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D225E1A8AD6 for <>; Wed, 8 Oct 2014 20:42:33 -0700 (PDT)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id BE60D3AA13; Wed, 8 Oct 2014 20:41:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=sldo; t=1412826067; bh=VKAL5ZKAIu2B9g8XWaiuD73A4A4bhDJ3myo4wGm8L5E=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=cJyfmAuiyaEd82ZdScD3MvtKCHmm+Q8US3lUbkIxkmDBd8brSmZl1Dg1a8DZPrbGm w4Pjnb995uY8vPkt4RnJCn5f4REo0ysQiFQ1BsOlIXkgEU3WJHCO1LkKCNd0i2m7kr qTKHWFZ7mbVPqZjqkiq6imXCfVFTdKNpby3ENqE8=
Message-ID: <>
Date: Wed, 08 Oct 2014 20:42:32 -0700
From: Mike Hamburg <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2
MIME-Version: 1.0
To: "Parkinson, Sean" <>, Watson Ladd <>
References: <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "" <>
Subject: Re: [Cfrg] When's the decision?
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: Thu, 09 Oct 2014 03:42:35 -0000

On 10/08/2014 06:55 PM, Parkinson, Sean wrote:
> Not all curves are implemented in a common place. Comparisons need to be made between 'equal' implementations.
> Is there a complete list of curves under consideration?
Supposedly we're still in the "collecting requirements" phase.

But IIRC, these have come up:
* Curve25519
* MS NUMS ed-{256,384,512}-mers
* The untwisted Edwards curves which are isogenous to the NUMS curves, 
or some other minor variant
* Curve41417
* Ed448-Goldilocks
* E-521

> For legal reasons I'm not going to be able to look at some libraries.
> If someone can confirm one way or another it would be appreciated.
> I believe mitigating the cache attack has a significant effect on the performance of Twisted Edwards curves. If we ignore this attack then how a Montgomery curve is implemented changes and this may swing the advantage back to using Montgomery for key exchange and Twisted Edwards for signatures.
The Goldilocks microbenchmarks include measurements of a 5-bit SABS 
fixed-window algorithm with and without constant-time table lookups.  By 
those numbers, the lookup costs about 6% of the total time on Haswell, 
10% on Tegra2 (ARM Cortex-A9, no NEON) and a whopping 14% on BeagleBone 
(ARM Cortex-A8, NEON).  This is a large part of why the Montgomery 
ladder is faster, especially on NEON. But it's still not *that* much faster.
> If a larger bit length curve was as fast as or faster than a curve that is a multiple of 128 bits would this change the decision?
> Sean
This is basically the point of Ed448-Goldilocks.  It's received a mixed 
response in this forum, since some people would prefer the most 
constrained curve, for some definition of "constrained" which doesn't 
consider performance.

-- Mike

> --
> Sean Parkinson | Consultant Software Engineer | RSA, The Security Division of EMC
> Office +61 7 3032 5232 | Fax +61 7 3032 5299
> -----Original Message-----
> From: Watson Ladd []
> Sent: Thursday, 9 October 2014 11:34 AM
> To: Parkinson, Sean
> Cc:
> Subject: Re: [Cfrg] When's the decision?
> On Wed, Oct 8, 2014 at 3:51 PM, Parkinson, Sean <> wrote:
>> I have concerns about a decision being made about which curves to recommend 'before Halloween'.
>> I am unaware of 3rd parties implementing and confirming all the curves that have been proposed.
>> Making a decision on new elliptic curves based on data that hasn't been corroborated by a 3rd party is bad practice.
> As far as I can tell, the implementations are all publicly available, and I believe recent eBATS has included quite a few.
>> I have been implementing as many of the curves as I can and my performance results, so far, do not always match those that I have seen in papers.
> How good are your implementations? Being fast is hard.
>> Also, I am concerned that, while some curves are being implemented to be constant time, not all curves are being implemented to be cache attack resistant. Either all implementations need to be resistant or all implementations not. Only then can a true comparison be made.
> All of them should be: this is annoying but straightforward to check by looking at implementations.
>> Until these issues are dealt with I feel there is not sufficient information to make a decision.
> Most of this information is independent of which parameters are picked.
>> Sean
>> --
>> Sean Parkinson | Consultant Software Engineer | RSA, The Security
>> Division of EMC Office +61 7 3032 5232 | Fax +61 7 3032 5299
>> _______________________________________________
>> Cfrg mailing list
> --
> "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither  Liberty nor Safety."
> -- Benjamin Franklin
> _______________________________________________
> Cfrg mailing list