Re: [Cfrg] Proposed requirements for curve candidate evaluation

Tanja Lange <> Fri, 08 August 2014 18:44 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id BD23A1A008C for <>; Fri, 8 Aug 2014 11:44:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id aSTzrs_N8ff9 for <>; Fri, 8 Aug 2014 11:44:18 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id D26E21A009E for <>; Fri, 8 Aug 2014 11:44:17 -0700 (PDT)
Received: (qmail 16690 invoked from network); 8 Aug 2014 18:44:07 -0000
Received: from (HELO ( by with SMTP; 8 Aug 2014 18:44:07 -0000
Received: (qmail 12809 invoked by uid 1000); 8 Aug 2014 18:44:04 -0000
Date: Fri, 08 Aug 2014 20:44:04 +0200
From: Tanja Lange <>
To: Michael Hamburg <>
Message-ID: <>
References: <> <>
Mime-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <>
User-Agent: Mutt/1.5.11
Cc: "" <>
Subject: Re: [Cfrg] Proposed requirements for curve candidate evaluation
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: Fri, 08 Aug 2014 18:44:21 -0000

On Thu, Aug 07, 2014 at 11:57:45AM -0700, Michael Hamburg wrote:
> > On Aug 7, 2014, at 7:20 AM, Brian LaMacchia <> wrote:
> > 4.	When evaluating candidate curves for use in ECDHE, "ephemeral" should be defined as "use exactly once in a key exchange" (or for TLS "use in exactly one handshake"). 
> > 
> > During the second TLS meeting in Toronto, Kenny Paterson gave a presentation summarizing where CFRG was on this question at that time and one of the points he mentioned was that there was not consensus as to what "ephemeral" should mean for purposes of evaluating candidates.  Russ Housley then commented at the microphone that "ephemeral" should mean "used in exactly one handshake".  I strongly concur with Russ's position and suggest that we formally adopt that definition now during the Requirements phase.  The concrete implication of adopting this proposed requirement is that it means when we evaluate ECDHE performance for curve candidates we must include one fixed-base and one variable-base operation. 
> I agree that this is what “ephemeral” should mean for evaluation.  But I don’t understand how this clarification could possibly change anything.

I would like to clarify that we're talking about different kinds of 
a) For performance evaluations one can argue that ephemeral means
   one handshake (or a short time or a small number of connections).
b) For security evaluations we must take into account that users
   may keep reusing the same key; this must not be a problem for the
   security of the curve or the implementation.