[curves] Another try at point compression

[Trevor Perrin]

On Mon, Dec 15, 2014 at 3:36 PM, Trevor Perrin <trevp at trevp.net> wrote:
>
> I'd be more interested in seeing you align the Goldilocks encoding
> with 25519, as far as possible, so it would be easy to provide both
> curves as options.


Thought about this more:

You could argue that 25519, as conventionally used, has some "quirks"
(cofactor, different public key formats).

I think an "extra-strength" curve is likely to be used as an option
alongside 25519.  So it's OK if it has the same quirks, but it's
painful to add new quirks.  It's OK to have fewer quirks, but it
doesn't help that much.

So I don't think it's worth much added complexity to have an encoding
that "eliminates the cofactor for all practical purposes".


As a separate argument, I think it would reduce 25519's quirkiness if
new protocols used Montgomery X plus Edwards sign bit for public keys
instead of the Ed25519 format.  The DH operation would ignore the
extra bit (as implementations currently do).

Then you'd have "DH-only" keypairs (Montgomery) and "full" keypairs
(Montgomery + extra bit).  People could build DH-only systems entirely
out of the Montgomery ladder.  But since full-format keys are a
superset of DH-only keys, libraries written in terms of the "full"
format would support / interop with DH-only keys.

I don't know if people agree with that.  But that argues that an
extra-strength curve should support the same encodings, or something
simpler (a single format).

Trevor