On Mon, Dec 15, 2014 at 3:36 PM, Trevor Perrin <[email protected]> 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 _______________________________________________ Curves mailing list [email protected] https://moderncrypto.org/mailman/listinfo/curves
