Re: [Cfrg] Point format for Edwards curves

[Watson Ladd <[e-mail]>]

On May 18, 2015 10:39 AM, "Nico Williams" <[e-mail]> wrote:
>
> 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.

But I'm proposing we solve that right now, rather then adopt a workaround.
There is no reason not to decide now.

>
> 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).

That is extra byte for sign bit, little endian?
>
> Nico
> --