Re: [Cfrg] Elliptic Curves - curve form and coordinate systems

[Andrey Jivsov <[e-mail]>]

On 03/13/2015 09:33 AM, Nico Williams wrote:
> On Fri, Mar 13, 2015 at 10:50:08AM -0400, Rene Struik wrote:
>> a) use of public key in computations.
>> Here, Andrey Jivsov's point was that receipt of a full point (x,y)
>> on a curve, rather than a compressed point or simply the
>> x-coordinate, does not artificially impose a performance penalty on
>> all implementations except x-coordinate-only ones (Montgomery).
> A "penalty" of some sort is involved in *all* possible choices, and
> there isn't one that is ideal for all use-cases.  Others have pointed
> this out.
>
> ECDH-only applications will exist and will be a/the common case.  Add to
> this the simplicity arguments, and clearly x-only Montgomery is a better
> choice for ECDH.
>
> Some trade-offs:
>
>   - x-only -> you must either have a Montgomery ladder implementation
>               *and* other implementations if you *also* support
>               signatures
>
>               or
>
>               you must have point conversion code *and* use it for ECDH
>               (10% penalty)
>
>     Obviously (I think), the first choice is better: it's a development-
>     and compile-time cost, with the small additional run-time cost of
>     extra text footprint IF you need both around (point coversion also
>     has this extra text footprint at run-time).
>
>   - (x,y)  -> bandwidth waste Montogmery ladder implementations

Is "wasting" of 32 extra per TLS/SSH session that important?

Considering average TLS session reuse rate today, this is 16 bytes per 
TLS session (and is likely to be fewer bytes than this).

>
>     This is not nothing (see Mike H.'s posts).
>
> Similarly for (x,sign(y)).
>
>> b) representation of public key in white list.
>> Here, one can use many methods to map a public key Q to a condensed
>> (perhaps, even human-recognizable) format f(Q).
>> This condensed format could take the form affine format curve point,
>> compressed format, hash, leftmost n-octets, hash value, etc.
> For (b), I don't see why x-only isn't good enough.  Can you elaborate?
>
> Nico