Coordinates in Elliptic Curves used in cryptography

Question

I have noticed that points on a NIST curve (secp256, secp384, etc.) or some other elliptic curves used in cryptography, when represented as 04 | x coordinate | y coordinate in hexadecimal, the coordinates appear to have a fixed length. Is this something that is proved somewhere ? As far as the math goes, I do not see any obvious reason why would this be true.

Answer 1

The coordinates of points on Elliptic Curves used in cryptography are in a finite field, thus can be expressed in bounded length, thus in fixed length. That ends the "proof". The field is $\mathbb F_p$ with some prime $p$ for all the secp curves.

The convention used in the question's notation is described in sec1v2 §2.3.3, case 3 (point compression is not being used), with each coordinate converted per §2.3.5, case 1 for secp curves, thus with conversion per §2.3.7, that is using big-endian convention over fixed number of bytes $\lceil(\log_2 p)/8\rceil$.

Answer 2

The X9/SECG formats (uncompressed, compressed, and now-dropped hybrid) for public-key (and sometimes other) points are widely used but are not the only ones.

• JWA/JOSE represents each coordinate as fixed-length big-endian unsigned (same as X9/SECG for GF(p) fields which are the only ones JWA uses) then converts each coordinate separately to base64url and uses it as a field in the JSON object for the key

• COSE also uses only GF(p) fields and starts with the SECG(/X9) coordinates, then puts in a CBOR map, in addition to generic members and the curve identifier, label -2 for the x coordinate and label -3 for either the y coordinate or a boolean value equivalent to the X9/SECG compressed parity but represented differently

• the first version of ECDSA for XMLDSIG has separate XML elements (X and Y) each containing an integer for GF(p) fields or an octetstring for GF(2^m) fields; XMLDSIG2 supersedes this with the X9/SECG uncompressed format encoded in base64