Re: [Cfrg] Proposed requirements for curve candidate evaluation

Michael Hamburg <> Thu, 07 August 2014 18:57 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C2D101A040E for <>; Thu, 7 Aug 2014 11:57:49 -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 dsfmHPlOCFvi for <>; Thu, 7 Aug 2014 11:57:48 -0700 (PDT)
Received: from ( []) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 07CE01A03FA for <>; Thu, 7 Aug 2014 11:57:47 -0700 (PDT)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id 8D5603AA27; Thu, 7 Aug 2014 11:56:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=sldo; t=1407437819; bh=2a/7Qesq/wspx1tYOymPlBylOAN+crwjcKQ6DY65EpA=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=Z+/EGiFOnKo1CHb0QvwTBJTVuGH29YyZHNY6lYozbJlPQtdfAFk7go4WelPEq54ym 674Bf9QVtNuzylaMlTiYqDJFjrD12mluxIaN3/ktFeL+GNSAzoGu0nlNWgTayfiaLJ voTppryqWvQHYvup8GCxymHWM+9KqDPvTtidv3KQ=
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1971.5\))
From: Michael Hamburg <>
In-Reply-To: <>
Date: Thu, 07 Aug 2014 11:57:45 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Brian LaMacchia <>
X-Mailer: Apple Mail (2.1971.5)
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: Thu, 07 Aug 2014 18:57:49 -0000

> On Aug 7, 2014, at 7:20 AM, Brian LaMacchia <> wrote:
> 2.	At each security level, the CFRG-recommended curve must be specified in a single curve model that is used for both digital signatures and key exchange algorithms (in particular ECDSA and ECDHE), without transformation to other models.

To be clear, this “requirement” means that the curve must be specified in short Weierstrass form, right?

You’re suggesting that CFRG disregard the state of the art in ECC simplicity, security and performance (Edwards curves) because it’s too complicated to compute (y+1)/(y-1) + k?

I believe that this should absolutely not be a requirement for curve candidate evaluation.

> 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.

You can use a fixed-based precomputed combset (or similar table) for any elliptic curve.  It will pretty much always cost about a third of what the variable-base scalar multiply costs.  This is true for Edwards curves, Montgomery curves, short Weierstrass curves, Hessian curves, Jacobi quartics … anything that is an Elliptic curve and not just a Kummer surface.

You’re driving awfully hard for a definition which doesn’t matter, particularly considering that the first half of your email argues strenuously against performance considerations.  Can you explain why we should care about this at all?  Is this going to turn into a convoluted argument against Curve25519?

— Mike