Re: [Cfrg] Elliptic Curves - curve form and coordinate systems (ends on March 12th)

[Nico Williams <[e-mail]>]

On Thu, Mar 05, 2015 at 11:31:01PM +0000, Alexey Melnikov wrote:
> CFRG chairs are starting discussion of the next topic:
> 
> Q4: draft-irtf-cfrg-curves-01 currently contains curves in both
> Montgomery form and Edwards form. The scalar multiplication routine
> is specified using Montgomery form (and is specific to Curve25519,
> which will need to be changed given our decision to include a higher
> security level curve). Its input is a scalar and the u-coordinate of

I don't understand the parenthetical.  What does including a higher
security-level curve have to do with whether Curve25519 uses Montgomery
form?

> a point on a Montgomery-form curve; its output is the u-coordinate
> of a point on a Montgomery-form curve. The DH function builds on
> this routine. Do we want to stay with specifying the inputs and
> outputs in Montgomery form for these routines? Or do we want to
> switch to an alternative curve form and coordinate system for
> defining the routines? If so, which form and coordinate system?

Stay, not switch.

Yesterday I posted an extended reply about this as a follow-up to
Watson's reply about this:

http://www.ietf.org/mail-archive/web/cfrg/current/msg06438.html

> [Chairs are aware that it is possible to switch back and forward
> between different curve forms and coordinate systems, with
> associated costs, no matter which form is specified for the inputs
> and outputs of the routines. But we now have to decide *which* form
> we want to use for inputs and outputs, so as to ensure
> interoperability between Alice and Bob. Chairs did not want to
> implicitly force the choice of Montgomery form/coordinates without
> polling the group first.]

There is no need to switch back and forth between code representations
unless one wishes to use a private key both for ECDH *and* other ECC
purporses (e.g., signatures) where Montgomery is a pessimization.  Even
should such a use-case arise, as you point out, conversions are
possible.

> Once this issues is settled, we will be discussing (in no particular
> order. Chairs reserve the right to add additional questions) wire
> format, byte order and signature schemes. Please don't discuss any
> of these future topics at this time.

Sure, though of course, if we accept that each curve can dictate what
point representation to use [up to and including separately for each use
type, ECDH, signatures, ...], then there's no point getting exercised
about Curve25519's choice of marshalling format (including endianness)
(but there would be a point to getting exercised about changing that).

Nico
--