Is there a standardized fixed-length encoding for EC public keys?

Question

I was wondering if there was (and I hope there is) a standard for public key size for ECDH (Elliptic Curve Diffie-Hellman) and ECDSA (Elliptic Curve Digital Signature Algorithm) for every curve type over prime fields (192, 224, 256, 384 and 521).

Answer 1

If you use one of the "named curves" then the public key size is fixed and dependent on the "field size" of your underlying curve.

Compressed vs. uncompressed representation

Public key sizes further depend on whether the "uncompressed" representation or the "compressed" representation is used. In the uncompressed form, the public key size is equal to two times the field size (in bytes) + 1, in the compressed form it is field size + 1. So if your curve is defined on secp256r1 (also called NIST P-256 or X9.62 prime256v1), then the field size is 256 bits or 32 bytes. And therefore the public key would be exactly 65 bytes (32*2 +1) long in the uncompressed form and 33 bytes (32 +1) long in the compressed form.

The uncompressed form consists of an 0x04 (in analogy to the DER OCTET STRING tag) plus the concatenation of the big-endian binary representation of the x coordinate plus the binary representation of the y coordinate of the public point.

GF(p) case

If the underlying field is GF(p) where p is a a big prime (in the case of P-256, a 256-bit prime), then x and y can be thought of as elements from [0, p-1]. They are encoded in the usual way as ((log2(p)+1)/8)-byte integers, with the MSBs padded with zero if necessary.

GF(2^m) case

For GF(2^m) x and y can be thought of as polynomials a_0 + a_1x + a_2x^2 + ... + a_{m-1}x^{m-1} with coefficients a_i equal to either 0 or 1. Their binary representation is simply the concatenation of the coefficients.

Further reading

The exact details can be found in SEC1v2. (Especially section 2.3.3 Elliptic-Curve-Point-to-Octet-String Conversion on pages 10 and 11.)