Re: [Cfrg] Point format for Edwards curves

[Nico Williams <[e-mail]>]

On Mon, May 18, 2015 at 09:57:31AM -0700, Watson Ladd wrote:
> On May 18, 2015 8:49 AM, "Nico Williams" <[e-mail]> wrote:
> > On Sun, May 17, 2015 at 08:56:20PM -0700, Andrey Jivsov wrote:
> > > The sign bit of T can also be implicit when T=wM+xG in your draft is
> > > required to have the positive 't_x' for T={t_x, t_y}  (or
> > > "compliant" T). The "encoding" of T can be done very efficiently
> > > because the sender chooses a random x.
> >
> > Even better.
> >
> > > https://tools.ietf.org/html/draft-jivsov-ecc-compact-05#section-4.2.3
> > > describes the algorithm for the sum of points.
> >
> > There's a timing variation, but it's entirely to do with the sums of
> > randomly selected points, not the fixed point derived from the password,
> > which means there's no side channel.  Very nice.
> 
> And this proposal will not work with batchable signature schemes. It also
> never gets to the byte level.

I didn't take Andrey's proposal as a generic point encoding for a
signature scheme, just for the SPAKE2.  That's convenient mainly because
there are implementors who might ship SPAKE2 with Curve255129 and
Goldilocks, but they can't do it without a point encoding for addition
-- Andrey's proposal saves them having to wait for CFRG to specify it.

For the signature scheme I agree we need a generic point encoding that
permits addition, and for that I support your proposal (y plus sign of x).

Nico
--