In the y coordinate it took the bytes serialization of the point and interpreted it as the y coordinate, ignoring the fact that the serialization encodes the parity bit of the x coordinate in the most significant bit (which is the reason djb made the field elements are 255 bits)
In the x coordinate there was a bug in xrecover using (q-3)/4 instead of (q-1)/4.
when recovering the x coordinate it did not flip it to the right parity using the parity bit.
The current code had the following bugs:
ycoordinate it took the bytes serialization of the point and interpreted it as theycoordinate, ignoring the fact that the serialization encodes the parity bit of thexcoordinate in the most significant bit (which is the reason djb made the field elements are 255 bits)xcoordinate there was a bug inxrecoverusing(q-3)/4instead of(q-1)/4.xcoordinate it did not flip it to the right parity using the parity bit.I generated test vectors using https://github.com/dalek-cryptography/curve25519-dalek and fixed the issues making the test pass.
references: https://ed25519.cr.yp.to/python/ed25519.py https://datatracker.ietf.org/doc/html/rfc8032#section-5.1.3 https://github.com/dalek-cryptography/curve25519-dalek/blob/076cf34/src/edwards.rs#L193 https://github.com/dalek-cryptography/curve25519-dalek/blob/076cf34/src/edwards.rs#L518 https://github.com/dalek-cryptography/curve25519-dalek/blob/076cf34/src/field.rs#L229