Wim Lewis wiml@hhhh.org writes:
Point compression is easy enough, but point decompression requires some curve math, potentially dependent on the specific curve, and some of it is redundant with what's already done in ecc_point_set().
I think what's needed is basically a mod p square root. See RFC 6090 for one way to do it. (Btw, it might make sense to adopt the name "compact representation" from that document; the name "point compression" was probably invented to make the good old math sound more technical and impressive in patent filings).
So I was thinking about moving this functionality into Hogweed as a function along the lines of ecc_point_set_compressed(), which would take, instead of a y-coordinate, an int containing the sign/parity of the y-coordinate.
For the details, it's good to have a specific reference to follow. There'a also been a feature request to convert points to and from ANSI x9.62, possibly related? Maybe converting to and from octest strings according to some specification is more useful as an advertised interface, than x coordinate + sign (not ruling out having both).
So my question for the list and for the maintainers is, is this a reasonable API to add to Hogweed? Is there interest in including it in Hogweed if I were to take the time to turn it into a tidy patch?
It could make sense. Do you have any concrete use cases?
Regards, /Niels