SEC 1 §2.3.3 définit les chaînes d’octets utilisées presque partout : la forme non compressée 0x04 ‖ x ‖ y (65 octets pour P-256 et secp256k1, 97 pour P-384, 133 pour P-521) et la forme compressée 0x02 ‖ x ou 0x03 ‖ x, où le préfixe donne la parité de y (33, 49 et 67 octets). Le décodage d’un point compressé résout l’équation de la courbe en y, et un décodeur doit rejeter un x qui n’a aucun y valide.
La forme que vous rencontrez dépend de l’écosystème : la SubjectPublicKeyInfo X.509 contient presque toujours des points non compressés (la RFC 5480 en exige la prise en charge et rend les points compressés facultatifs), l’import raw de WebCrypto accepte les deux formes pour les clés ECDSA dans les navigateurs modernes, Bitcoin utilise des clés compressées de 33 octets depuis 2012 environ, et Ethereum dérive les adresses des 64 octets de x ‖ y sans le préfixe 0x04. Les JWK portent toujours des membres x et y distincts.
Les encodages d’Edwards et de Montgomery sont compressés par construction : une clé publique Ed25519 est la coordonnée y sur 32 octets, avec le signe de x dans le bit de poids fort, et X25519 ne transmet que u. Une confusion entre une clé de 33 octets et une clé de 65 octets est une cause fréquente des erreurs « invalid public key » et « point is not on the curve ».