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

[Adam Langley <[e-mail]>]

On Thu, Mar 12, 2015 at 1:04 PM, Andrey Jivsov <[e-mail]> wrote:
> I apologize (need more coffee). I meant to write v = SQRT(u^3 + 486662*u^2 +
> u). The SQRT can be calculated (for almost free) during X/Z calculation by
> the sender at the end of scalarmult, because the sender must do 1/Z, but
> there is no apparent way to avoid SQRT for the receiver (unless the received
> doesn't need v and only works on u). The sign is embedded in v (and v can be
> adjusted  p-v as needed for signatures; ECDH doesn't care).

Ah, thanks. That makes a lot more sense.

The point format could certainly be (u,v) and that could unify the
format for signature and DH public keys. I think the impression in the
past has been that we are willing to pay a little CPU time to
eliminate some implementation pitfalls. Here the pitfall would be
omitting to check that (u,v) is a point on the curve—something that
sending compressed points avoids.

So we could say that the format is u + the sign bit of v. The sign bit
can even be packed into the MSB of u in the case of curve25519. So we
could get a unified DH and signature point format and safety with
that, although existing implementations would only be compatible when
receiving. So I think that would lead to a lot of deployments that
would always set the sign bit to zero because they're actually an
existing curve25519 implementation underneath.

When we've had compatible DH and signature formats (i.e. ECC X.509
signatures with X9.62 encoding) it's actually been a problem, not a
blessing. CAs have had to remove the keyAgreement bit from these
certificates so that they aren't accidentally used for fixed-DH in
TLS.


Cheers

AGL