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

["Paterson, Kenny" <[e-mail]>]

On 12/03/2015 21:23, "Nico Williams" <[e-mail]> wrote:

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

Nothing. The point is that the current text concerning the scalar
multiplication routine is very tied to Curve25519, and needs to be
modified if it is to be able to handle other curves - either by
generalising it or including separate and parallel text for each
additional curve. No-one is proposing to harm Curve25519 in any way!

>> 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
>-- 
>
>_______________________________________________
>Cfrg mailing list
>[e-mail]
>http://www.irtf.org/mailman/listinfo/cfrg