P-256 vs P-384 : quand ECDSA à 192 bits en vaut la peine

P-256 vs P-384, c’est un choix entre deux courbes du NIST de la même famille : mêmes algorithmes (ECDSA et ECDH), mêmes encodages, mêmes outils. P-384 porte la sécurité classique d’environ 128 à environ 192 bits ; P-256 est plusieurs fois plus rapide et prise en charge par davantage de matériel. Pour la plupart des systèmes, la décision relève de la politique plutôt que du risque.

Vue d’ensemble

Vitesses mesurées sur un cœur d’un Apple M4 Max avec openssl speed ; le script de mesure des tailles ci-dessous a été exécuté avec OpenSSL 3.6.5.

De quel niveau de sécurité avez-vous besoin ?

NIST SP 800-57 Part 1 place les courbes de 256 à 383 bits au niveau de sécurité de 128 bits, et celles de 384 à 511 bits au niveau de 192 bits. 128 bits dépassent de loin toute attaque classique prévisible : la meilleure attaque connue contre P-256 demande de l’ordre de 2¹²⁸ opérations de groupe. La marge supplémentaire de P-384 protège contre des progrès inattendus de la cryptanalyse des courbes elliptiques, pas contre la recherche exhaustive, et elle ne change rien face à l’algorithme de Shor, qui casse les deux courbes avec un effort comparable. NIST IR 8547 (un projet initial soumis à consultation publique) les traite donc de la même façon : aucune des deux n’est dépréciée en 2030 (cela ne concerne que les algorithmes à 112 bits comme RSA-2048 et P-224), et toutes deux sont interdites après 2035.

Le vrai moteur, c’est la politique. La Commercial National Security Algorithm Suite d’origine de la NSA (CNSA 1.0) exigeait P-384 pour ECDH et ECDSA : les produits destinés aux systèmes de sécurité nationale des États-Unis et à leurs chaînes d’approvisionnement l’utilisent donc par défaut. CNSA 2.0 remplace P-384 par ML-KEM-1024 et ML-DSA-87. Les autorités de certification choisissent souvent P-384 pour les clés racines et intermédiaires qui doivent rester dignes de confiance pendant dix ans ou plus ; ISRG Root X2 de Let’s Encrypt et ses intermédiaires ECDSA sont en P-384, tandis que les certificats des abonnés peuvent utiliser l’une ou l’autre courbe.

Coût en performances et en taille

OpenSSL fournit pour P-256 du code assembleur optimisé à la main, d’où l’ampleur de l’écart : environ 87 000 signatures P-256 par seconde contre environ 9700 pour P-384 sur un cœur d’Apple M4 Max, et environ 29 000 vérifications contre 4500. Sur un serveur TLS, la clé du certificat signe une fois par handshake complet : P-384 multiplie donc cette part du coût du handshake par neuf environ. Pour une autorité de certification qui signe quelques certificats par seconde, c’est sans importance.

Les tailles augmentent modérément : de 32 octets pour les signatures brutes, de 32 octets pour les clés publiques et d’environ 60 octets pour les certificats.

#!/bin/sh
dir=$(mktemp -d)
cd "$dir" || exit 1
printf 'hello' > msg
for curve in P-256 P-384; do
  openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:$curve -out key.pem 2>/dev/null
  openssl req -new -x509 -key key.pem -subj "/CN=example.com" -days 90 -outform DER -out cert.der 2>/dev/null
  openssl dgst -sha256 -sign key.pem -out sig.der msg
  printf '%s: SPKI %s bytes, DER signature %s bytes, self-signed certificate %s bytes\n' "$curve" \
    "$(openssl pkey -in key.pem -pubout -outform DER | wc -c | tr -d ' ')" \
    "$(wc -c < sig.der | tr -d ' ')" \
    "$(wc -c < cert.der | tr -d ' ')"
done
cd / && rm -rf "$dir"

P-256: SPKI 91 bytes, DER signature 71 bytes, self-signed certificate 388 bytes
P-384: SPKI 120 bytes, DER signature 102 bytes, self-signed certificate 451 bytes

Prise en charge

Les deux courbes figurent dans FIPS 186-5 et SP 800-186, dans toutes les bibliothèques TLS, dans WebCrypto, dans JOSE et COSE, dans les cartes à puce PIV et dans la liste des clés de certificat autorisées par le CA/Browser Forum (P-256, P-384 et P-521). Les lacunes concernent le matériel sécurisé et les authentificateurs : la Secure Enclave d’Apple ne propose que P-256 pour les clés classiques, les clés d’accès utilisent ES256 de façon quasi universelle, et certains éléments sécurisés IoT n’implémentent que P-256. Côté serveur, les HSM et les services KMS cloud prennent en charge les deux.

Quand choisir l’une ou l’autre

• Certificats TLS publics : P-256. Cette courbe est plus rapide pour les handshakes et acceptée partout ; un certificat feuille P-384 n’apporte rien qu’un client puisse vérifier.
• Clés racines et intermédiaires d’AC : P-384 est un choix courant et raisonnable pour des clés à longue durée de vie ; une telle clé peut signer des certificats feuilles P-256.
• JWT et jetons d’API : ES256, sauf si un profil, comme certaines spécifications gouvernementales ou financières, exige ES384.
• Clés d’accès et clés d’appareil : P-256, car c’est ce que propose le matériel.
• Systèmes CNSA 1.0 et leurs fournisseurs : P-384 avec SHA-384, et AES-256 ; prévoyez le passage à ML-KEM-1024 et ML-DSA-87 dans le cadre de CNSA 2.0.
• TLS hybride post-quantique : X25519MLKEM768 pour un usage général ; SecP384r1MLKEM1024 lorsqu’une politique de type CNSA impose des courbes du NIST et des paramètres de catégorie 5.

Notes de migration

Changer de courbe implique de nouvelles clés, mais les outils restent les mêmes.

1. Générez la nouvelle clé avec openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-384 (ou P-256) dans le HSM ou le KMS où elle sera conservée.
2. Associez la bonne fonction de hachage. P-384 s’utilise normalement avec SHA-384 (ES384, ecdsa-with-SHA384) ; ECDSA tronque les condensats plus longs à la longueur de l’ordre, mais les paires mal assorties perturbent les contrôles de politique et certains vérificateurs.
3. Mettez à jour les identifiants : alg et crv JOSE, algorithme COSE, schéma de signature TLS et profils de certificat. Publiez les deux clés dans un JWKS avec des valeurs kid distinctes pendant la rotation.
4. Redimensionnez les tampons de taille fixe : les signatures brutes passent de 64 à 96 octets, les coordonnées de 32 à 48 octets.
5. Mesurez les performances des handshakes avant de passer à un certificat P-384 sur un point de terminaison TLS très sollicité ; la plupart des déploiements qui adoptent P-384 pour des raisons de politique conservent P-256 là où la politique ne s’applique pas.

Références

• NIST SP 800-186 (§3.2.1.3 P-256, §3.2.1.4 P-384)
• FIPS 186-5, norme de signature numérique
• NIST SP 800-57 Part 1 Rev. 5, tableau 2
• Projet public initial de NIST IR 8547
• RFC 7518 §3.4, ES256 et ES384
• Avis de la NSA sur les algorithmes CNSA 2.0
• Baseline Requirements du CA/Browser Forum, §6.1.5
• Chaînes de confiance de Let’s Encrypt