Re: [Cfrg] Proposed requirements for curve candidate evaluation

[Michael Hamburg <[e-mail]>]

> On Aug 7, 2014, at 7:20 AM, Brian LaMacchia <[e-mail]> 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?

Cheers,
— Mike