Re: [Cfrg] When's the decision?

"Parkinson, Sean" <> Thu, 09 October 2014 04:13 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id CF0471A8BC3 for <>; Wed, 8 Oct 2014 21:13:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4EYLflVe5HPF for <>; Wed, 8 Oct 2014 21:13:27 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 94B021A8AE3 for <>; Wed, 8 Oct 2014 21:13:27 -0700 (PDT)
Received: from ( []) by (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s994DOwh027575 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Oct 2014 00:13:25 -0400
X-DKIM: OpenDKIM Filter v2.4.3 s994DOwh027575
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed;; s=jan2013; t=1412828005; bh=P+YDGIapy6ptIdVv/feKGxXyh1Q=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=TKmsUizWgE2loMMhzWavGn8nZEBSNK6M82MGoBOv6aHYpWM0bRlVuIvX7va5wpA3Q PKTJQtZsDrieTUJjqrfSQnyupG+mKI3dqma293czCKtyBq5e2Yn09TQwVl75Yfmji5 FRq7RnYsbaZHvGfdib09UX/r9WIwOdeA7QHWePL0=
X-DKIM: OpenDKIM Filter v2.4.3 s994DOwh027575
Received: from ( []) by (RSA Interceptor); Thu, 9 Oct 2014 00:12:44 -0400
Received: from ( []) by (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s994D83u020740 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 9 Oct 2014 00:13:08 -0400
Received: from ([]) by ([]) with mapi; Thu, 9 Oct 2014 00:13:08 -0400
From: "Parkinson, Sean" <>
To: Mike Hamburg <>, Watson Ladd <>
Date: Thu, 9 Oct 2014 00:13:04 -0400
Thread-Topic: [Cfrg] When's the decision?
Thread-Index: Ac/jcxMtwd6yY766TvWuqe8d9B3vqwAAHAMQ
Message-ID: <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-RSA-Classifications: DLM_1, public
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 04:13:31 -0000

Thanks Mike. These are the curves I was thinking are under consideration.

I thought the mitigation to the cache side-channel attack in OpenSSL was to read/write all entries rather than to use an index that is data dependent. Please correct me if I'm wrong.

Sean Parkinson | Consultant Software Engineer | RSA, The Security Division of EMC
Office +61 7 3032 5232 | Fax +61 7 3032 5299

-----Original Message-----
From: Mike Hamburg [] 
Sent: Thursday, 9 October 2014 1:43 PM
To: Parkinson, Sean; Watson Ladd
Subject: Re: [Cfrg] When's the decision?

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