Support compressed and uncompressed point serialization #43
Conversation
…ric vector serialization.
| { | ||
| g.X = tX; | ||
| g.Y = tY; | ||
| g.Z = alt_bn128_Fq::one(); |
There was a problem hiding this comment.
Why don't we check that the point is on the curve first?
Seems to me that the deserialization logic of a point in the affine space should be:
- Recover
x,y - Check that the tuple
(x, y)is on the curve, i.e. satisfies the curve equation - Either do the "safe subgroup membership test" or mult by cofactor to make sure we have a point in G1 and not a point (which may be of low order) in the E/Fq group
Do I miss something? (Note: this code initially originates from the library, and has just been moved around in this PR - so this question applies to the current state of the library, as in master, for the deserialization of uncompressed points)
There was a problem hiding this comment.
Note, it seems to me that, the same assumption is made in the deserialization of compressed points, since I can read here that the sqrt function does not terminate if the element is a quadratic non-residue in the field: https://github.com/scipr-lab/libff/blob/master/libff/algebra/fields/fp.hpp#L108
We can "skip" the bullet 3. above here since cofactor = 1, but why skipping bullet 2.? I'd be in favor to test for quadratic residuity using Euler's criterion (and the euler exponent defined here: https://github.com/scipr-lab/libff/blob/master/libff/algebra/fields/fp.hpp#L54) first, and only proceed if the test is valid.
These functions act as I/O with the backend of the library, so I would be in favor to make no assumption about their input, and the parsed points.
As such, I would be in favor to add these checks. @dtebbs @madars @ValarDragon thoughts?
This is related to #50
Allows compressed / uncompressed points to be used in different situations, independently of the build configuration.