Les clés sont un scalaire privé d compris entre 1 et n−1 et le point public Q = d·G, où G est le point de base de la courbe et n son ordre premier. Pour signer un condensat z, le signataire choisit un nonce secret k, prend pour r la coordonnée x de k·G modulo n et calcule s = k⁻¹·(z + r·d) mod n ; le vérificateur calcule u₁ = z·s⁻¹ et u₂ = r·s⁻¹ et vérifie que la coordonnée x de u₁·G + u₂·Q est égale à r (FIPS 186-5 §6.4). Le condensat est tronqué à la longueur en bits de n : avec P-256, SHA-512 n’utilise donc que ses 256 bits de poids fort.
Identifiants courants : en X.509, ecdsa-with-SHA256 correspond à 1.2.840.10045.4.3.2 (SHA-384 : …4.3.3, SHA-512 : …4.3.4) ; en JOSE, ES256, ES384, ES512 et ES256K ; en COSE, −7, −35, −36 et −47 ; en TLS 1.3, ecdsa_secp256r1_sha256 (0x0403). Les courbes habituelles sont P-256, P-384, P-521 et, pour les blockchains, secp256k1.
Une même signature circule sous deux encodages : r‖s brut de longueur fixe (64 octets pour P-256 ; JOSE, WebCrypto, COSE) et une SEQUENCE ASN.1 DER de deux INTEGER (70 à 72 octets pour P-256 ; X.509, TLS, OpenSSL, Java). Pour toute paire (r, s) valide, la paire (r, n − s) passe elle aussi la vérification, c’est pourquoi les blockchains exigent des signatures low-S.
Le nonce est le point faible : un k répété ou légèrement biaisé révèle la clé privée, c’est pourquoi les bibliothèques modernes le dérivent de façon déterministe (RFC 6979, approuvée par FIPS 186-5 §6.3.2) ou y ajoutent de l’aléa (hedging). Sur un cœur d’Apple M4 Max, OpenSSL 3.6.5 produit environ 87 000 signatures P-256 et 29 000 vérifications par seconde. Le NIST IR 8547 (premier projet public) propose d’interdire ECDSA à tous les niveaux de sécurité après 2035, car l’algorithme de Shor le casse.