Ed25519 vs P-256 vs P-384 vs secp256k1 : Comparatif 2026

Quatre courbes elliptiques font tourner la quasi-totalité du chiffrement à clé publique sur Internet en 2026, et pourtant la plupart des ingénieurs ne savent pas pourquoi leur certificat TLS utilise P-256 plutôt que secp256k1, ou pourquoi leur clé SSH Ed25519 tient dans 32 octets alors qu’une clé RSA équivalente en occupe 256. Les quatre courbes, P-256, P-384, Curve25519 (avec ses variantes X25519 et Ed25519) et secp256k1, partagent le même problème mathématique de fond, le logarithme discret sur courbe elliptique, mais elles divergent sur la provenance de leurs paramètres, leur vitesse réelle et leur terrain de jeu favori.

Un benchmark publié dans l’OpenSSL Cookbook montre un écart de signature de 8,7 fois entre P-256 et P-384 sur la même machine. Un autre test, celui de la bibliothèque mirage-crypto-rng, affiche un écart encore plus large. Ces chiffres suffisent à expliquer pourquoi le choix d’une courbe n’est jamais neutre, qu’on conçoive une API bancaire, qu’on signe des transactions Bitcoin ou qu’on configure un serveur SSH pour une PME lyonnaise. Ce comparatif détaille les specs, les prix cloud, les cas d’usage réels et un chemin de migration pour les quatre courbes qui comptent vraiment en France et en Europe à l’automne 2026.

Pour une équipe technique française, la question n’est pas théorique. Un éditeur SaaS qui héberge ses serveurs chez OVHcloud ou Scaleway doit choisir une courbe pour ses certificats TLS, une banque qui expose une API DSP2 doit décider quelle courbe exiger de ses partenaires, et une start-up qui construit un portefeuille crypto doit intégrer secp256k1 qu’elle le veuille ou non. Ajoutez à cela la pression du calendrier post-quantique européen, qui pousse déjà de nombreux DSI à revoir leur inventaire de clés, et le choix d’une courbe classique en 2026 devient une décision qui engage l’architecture pour les cinq à dix prochaines années.

Google · Sources préférées

Ne manquez aucune actu tech sur Google

Ajoutez Shattered une seule fois dans l'app Google pour retrouver nos articles dans vos suggestions.

Ajouter

Quatre courbes, une seule question : laquelle choisir en 2026

P-256, aussi appelée secp256r1 ou prime256v1 selon le standard qui la décrit, a été publiée par le NIST à la fin des années 1990. Son coefficient a été généré en hachant une graine que l’agence américaine n’a jamais expliquée publiquement, ce qui alimente depuis vingt ans un débat sur la transparence des paramètres plutôt que sur une faiblesse démontrée. P-384 suit la même philosophie de conception, mais vise un niveau de sécurité classique plus élevé, environ 192 bits contre 128 pour sa petite sœur, au prix de clés et d’opérations nettement plus lourdes.

Curve25519 est née d’une démarche opposée. Le cryptographe Daniel J. Bernstein l’a publiée en 2006 avec une procédure de génération de paramètres entièrement publique, sans valeur libre à justifier après coup. Cette propriété, dite de rigidité, en fait la courbe préférée des projets qui veulent éviter tout soupçon de porte dérobée. Sa variante pour l’échange de clés s’appelle X25519, et sa variante pour les signatures numériques s’appelle Ed25519. Les deux reposent sur la même courbe mais utilisent des formes mathématiques différentes, Montgomery pour l’une, Edwards tordue pour l’autre.

secp256k1 vient d’un troisième monde, celui des standards industriels du SECG publiés autour de 2000. Elle est restée relativement marginale jusqu’à ce que Satoshi Nakamoto la choisisse pour Bitcoin en 2009, un choix qui a ensuite été repris par Ethereum et la quasi-totalité des blockchains basées sur ECDSA. En dehors de l’écosystème crypto, elle reste pratiquement absente des certificats web et des infrastructures PKI classiques, même si son niveau de sécurité est comparable à celui de P-256.

Tableau comparatif technique : les chiffres clés des quatre courbes

Le tableau ci-dessous réunit les caractéristiques techniques qui comptent pour un ingénieur devant choisir une courbe en production. Les tailles de clés et de signatures proviennent des spécifications officielles (NIST SP 800-186, RFC 7748, RFC 8032, SEC 2), les niveaux de sécurité et les estimations de qubits logiques proviennent du fieldguide de LaMarr Labs consacré à Curve25519 et P-256.

Caractéristique	P-256 (secp256r1)	P-384 (secp384r1)	Curve25519 / Ed25519	secp256k1
Organisme / auteur	NIST	NIST	Daniel J. Bernstein	Certicom / SECG
Année de publication	Fin des années 1990	Fin des années 1990	2006	Vers 2000
Forme mathématique	Weierstrass	Weierstrass	Montgomery (X25519) / Edwards tordue (Ed25519)	Weierstrass
Taille du champ premier	256 bits	384 bits	255 bits	256 bits
Taille de clé privée	32 octets	48 octets	32 octets	32 octets
Taille de signature (ECDSA/EdDSA)	64 octets	96 octets	64 octets (Ed25519)	64 à 65 octets
Niveau de sécurité classique	~128 bits	~192 bits	~128 bits	~128 bits
Qubits logiques estimés (whitepaper Google Quantum AI, 2026)	1 200 à 1 450	Supérieur, non chiffré publiquement	1 200 à 1 450 (ordre comparable)	Ordre comparable à P-256
Temps constant natif	Non garanti par construction	Non garanti par construction	Oui, via le clamping Montgomery	Non garanti par construction
Norme de référence	NIST SP 800-186	NIST SP 800-186	RFC 7748 / RFC 8032	SEC 2
Usage principal en 2026	TLS, certificats web, PKI, HSM	Systèmes gouvernementaux et classifiés (CNSA)	SSH, Signal, WireGuard	Bitcoin, Ethereum, signatures de transactions
Support par défaut dans OpenSSH	Oui, ecdsa-sha2-nistp256	Oui, ecdsa-sha2-nistp384	Oui, ssh-ed25519 recommandé depuis des années	Non natif

Ce qui frappe en lisant cette grille, c’est que P-256, Curve25519 et secp256k1 offrent toutes les trois environ 128 bits de sécurité classique avec une clé privée de 32 octets. La différence ne se joue donc pas sur la taille des clés mais sur la provenance des paramètres, la résistance aux erreurs d’implémentation et l’écosystème logiciel qui entoure chaque courbe. P-384 sort du lot en visant délibérément un niveau de sécurité supérieur, ce qui explique pourquoi elle reste réservée à des contextes précis plutôt que généralisée à tout le web.

Niveaux de sécurité : ce que veulent vraiment dire 128 et 192 bits

Un niveau de sécurité de 128 bits signifie qu’un attaquant doit effectuer environ 2 puissance 128 opérations pour casser la clé par la force brute la plus efficace connue. C’est un nombre tellement grand qu’aucun supercalculateur classique actuel ni prévisible n’en est capable, et c’est la raison pour laquelle P-256, Curve25519 et secp256k1 sont jugées sûres face aux ordinateurs classiques pour encore de nombreuses années. P-384 pousse cette marge à 192 bits, un niveau que recherchent les agences qui manipulent des informations classifiées ou des infrastructures critiques, au prix d’opérations cryptographiques beaucoup plus lourdes.

Le blog technique de l’auteur de la série Python sur la cryptographie elliptique rappelle un repère utile pour situer ces niveaux face à RSA : une clé ECC de 256 bits atteint une sécurité comparable à une clé RSA de 3072 bits. C’est précisément ce gain en compacité, pour une sécurité équivalente ou supérieure, qui a poussé TLS, SSH et les blockchains à migrer massivement vers les courbes elliptiques au cours des quinze dernières années plutôt que de continuer à allonger les clés RSA.

Le fieldguide de LaMarr Labs insiste sur un point souvent oublié dans les comparatifs rapides : P-256 et Curve25519 délivrent exactement la même force classique, 128 bits, avec une clé privée de la même taille, 32 octets. Leur différence ne se situe donc pas dans la robustesse mathématique mais dans deux autres dimensions. D’abord la provenance des paramètres, rigide et documentée pour Curve25519, opaque sur un détail pour P-256. Ensuite la sécurité d’implémentation, puisque l’arithmétique de Montgomery de Curve25519 tourne naturellement en temps constant et élimine plusieurs classes d’erreurs classiques, alors que l’arithmétique de Weierstrass de P-256 laisse davantage de marge d’erreur à chaque développeur qui l’implémente à la main.

Ce chiffre de 128 bits n’est pas arbitraire. Il correspond au seuil que l’industrie a fixé il y a une quinzaine d’années pour remplacer les clés RSA de 1024 et 2048 bits, jugées trop fragiles face à la puissance de calcul classique croissante. Les courbes elliptiques ont permis d’atteindre ce seuil avec des clés bien plus courtes que RSA, ce qui explique pourquoi P-256, Curve25519 et secp256k1 ont toutes convergé vers ce même niveau plutôt que de viser plus haut par défaut. Monter à 192 bits avec P-384, ou à 256 bits avec la courbe P-521 plus rarement utilisée, reste réservé à des cas où la politique de sécurité l’exige explicitement, parce que le gain de marge ne se justifie pas pour la grande majorité des usages commerciaux.

Benchmarks de performance : qui signe et vérifie le plus vite

Les chiffres de performance varient fortement selon le processeur, la version d’OpenSSL et l’activation ou non de l’accélération matérielle, mais trois sources indépendantes dessinent une tendance cohérente. Le tableau de l’OpenSSL Cookbook mesure 6 566,2 signatures ECDSA par seconde pour P-256 contre seulement 755,0 pour P-384 sur la même machine, soit un écart de 8,7 fois en faveur de P-256. En vérification, l’écart grimpe à 35 fois, avec 20 508,1 opérations par seconde pour P-256 contre 580,4 pour P-384.

Le fichier de changements de la bibliothèque mirage-crypto-rng, testé sur un processeur Intel i7-5600U avec OpenSSL 3.0.12, confirme la tendance avec des écarts encore plus marqués : 36 182 signatures par seconde pour P-256 contre 900 pour P-384, soit environ 40 fois plus rapide, et 13 383 vérifications par seconde contre 1 062, soit environ 12,6 fois plus rapide. Les valeurs absolues diffèrent fortement d’un environnement à l’autre, mais le classement reste identique : P-384 coûte toujours plusieurs dizaines de fois plus de calcul que P-256 pour un gain de sécurité qui passe de 128 à 192 bits.

Pour Curve25519 et secp256k1, les benchmarks de la bibliothèque JavaScript @noble/curves donnent des résultats plus serrés. secp256k1 signe environ 7 182 fois par seconde contre 6 849 pour Ed25519 dans la configuration testée, un écart faible de quelques points seulement. En vérification, le rapport s’inverse nettement : Ed25519 vérifie environ 1 400 signatures par seconde contre 1 188 pour secp256k1, ce qui traduit un avantage de l’ordre de 18 % pour la famille Curve25519 sur cette opération précise. Ces chiffres dépendent fortement de l’implémentation et du matériel, mais ils confirment que P-256, Curve25519 et secp256k1 restent dans le même ordre de grandeur, loin devant P-384.

Courbe	Signatures / seconde	Vérifications / seconde	Source
P-256	6 566,2	20 508,1	OpenSSL Cookbook
P-384	755,0	580,4	OpenSSL Cookbook
P-256 (Intel i7-5600U)	36 182	13 383	mirage-crypto-rng 2.4.0
P-384 (Intel i7-5600U)	900	1 062	mirage-crypto-rng 2.4.0
secp256k1	7 182	1 188	@noble/curves
Ed25519	6 849	1 400	@noble/curves

La leçon pratique est simple : si un projet a besoin du débit maximal, par exemple un serveur TLS qui négocie des milliers de connexions par seconde, P-256, Curve25519 et secp256k1 se comportent de façon comparable, et le choix doit alors se faire sur d’autres critères que la vitesse brute. P-384 ne devient intéressante que lorsque le besoin de sécurité justifie explicitement de payer ce surcoût de calcul, par exemple dans des échanges gouvernementaux soumis à la suite CNSA.

Tarifs cloud : combien coûte chaque courbe chez AWS et Google

Les fournisseurs de cloud facturent rarement une courbe plus cher qu’une autre, mais ils ne supportent pas toutes les mêmes courbes, ce qui a un effet direct sur l’architecture et donc sur la facture finale. Selon la documentation officielle d’AWS KMS, le service facture 1,00 dollar par clé asymétrique et par mois, prorata temporis, plus 0,15 dollar par tranche de 10 000 requêtes d’API, ces requêtes étant exclues du palier gratuit de 20 000 appels accordé aux autres opérations KMS. AWS KMS prend en charge ECC_NIST_P256, ECC_NIST_P384, ECC_NIST_P521 et ECC_SECG_P256K1, la dénomination officielle de secp256k1, ce qui en fait l’un des rares services cloud grand public à exposer nativement la courbe de Bitcoin.

Côté Google Cloud KMS, le tarif publié est de 0,06 dollar par version de clé logicielle active et par mois, plus 0,03 dollar par tranche de 10 000 opérations cryptographiques. La documentation officielle de Google Cloud liste explicitement EC P256 et EC P384 parmi les types de clés pris en charge, mais elle ne confirme pas de support natif pour secp256k1 ou pour Ed25519 dans l’offre KMS standard, ce qui pousse les projets liés aux cryptomonnaies ou à SSH à se tourner vers des bibliothèques logicielles plutôt que vers le service managé.

Azure Key Vault classe les clés ECC dans sa catégorie de types de clés avancés sur sa page de tarification officielle, mais n’affiche pas de prix numérique par opération pour cette catégorie à la différence des clés RSA standards, et ne détaille pas sur cette page laquelle des courbes P-256, P-384, P-521 ou secp256k1 est couverte. Un architecte qui a besoin d’un chiffrage ferme avant de lancer un projet devra donc contacter directement le support Azure plutôt que de se fier à la grille publique, contrairement à AWS et Google qui publient des chiffres exploitables immédiatement.

Fournisseur	Prix par clé / mois	Prix par opération	Courbes officiellement listées
AWS KMS	1,00 $	0,15 $ / 10 000 requêtes	P-256, P-384, P-521, secp256k1
Google Cloud KMS	0,06 $ par version de clé	0,03 $ / 10 000 opérations	P-256, P-384
Azure Key Vault	Non chiffré publiquement (catégorie « avancée »)	Non chiffré publiquement	ECC générique, détail non précisé sur la page tarifaire

Pour un projet qui manipule directement des clés secp256k1, par exemple un service de garde d’actifs numériques, AWS KMS reste aujourd’hui le seul des trois grands fournisseurs à exposer cette courbe de façon officielle et documentée, ce qui en fait un critère de choix d’infrastructure à part entière et pas seulement un détail technique.

TLS 1.3 et certificats web : P-256 toujours en tête

Sur le web public, TLS 1.3 utilise de facto l’échange de clés ECDHE avec X25519 ou P-256 comme groupes préférés par la quasi-totalité des navigateurs modernes et des bibliothèques serveur. Les autorités de certification continuent très majoritairement à délivrer des certificats ECDSA sur P-256 plutôt que sur P-384 ou sur Curve25519, parce que P-256 bénéficie de la compatibilité la plus large avec les anciens clients, les modules matériels de sécurité existants et les infrastructures PKI déjà déployées chez les grandes entreprises. Changer de courbe sur un certificat public impose de vérifier toute la chaîne de confiance, du client le plus ancien jusqu’au module matériel le plus récent, ce qui explique l’inertie observée.

X25519, en revanche, a largement gagné la bataille de l’échange de clés côté protocole plutôt que côté certificat. Il apparaît comme groupe par défaut ou prioritaire dans la configuration TLS 1.3 de la plupart des serveurs web modernes et dans QUIC, le protocole de transport qui sous-tend HTTP/3. Cette coexistence illustre bien la distinction entre deux usages différents de la cryptographie à courbe elliptique : la signature du certificat, qui reste conservatrice et s’appuie sur P-256, et l’échange de clés de session, qui a basculé plus vite vers X25519 parce qu’il ne nécessite pas de refaire valider toute une chaîne de confiance publique.

P-384 garde une présence résiduelle sur le web public, principalement sur des sites gouvernementaux ou financiers qui appliquent des politiques de sécurité renforcées, mais elle reste minoritaire face à P-256 pour une raison simple : la majorité des visiteurs d’un site grand public n’a aucun besoin de 192 bits de sécurité classique, et le surcoût de calcul mesuré plus haut, jusqu’à 35 fois plus lent en vérification selon l’OpenSSL Cookbook, se traduit directement par une latence de connexion plus élevée à grande échelle.

SSH, Signal, WireGuard : la bascule silencieuse vers X25519 et Ed25519

En dehors du web public, la tendance s’inverse presque complètement. SSH, Signal et WireGuard utilisent tous les trois X25519 pour l’échange de clés et Ed25519 pour les signatures, selon l’inventaire dressé par le blog technique consacré à l’implémentation Python de la cryptographie elliptique. Cette convergence n’est pas un hasard : ces trois protocoles ont été conçus ou largement révisés après 2013, à une période où la rigidité des paramètres de Curve25519 et sa résistance native aux erreurs d’implémentation en faisaient le choix par défaut le plus sûr pour des équipes qui n’avaient pas les ressources d’un laboratoire cryptographique national.

Pour l’administration système, cette bascule se voit très concrètement. Depuis plusieurs années déjà, générer une nouvelle clé SSH avec la commande ssh-keygen -t ed25519 est devenu la recommandation par défaut dans la plupart des guides de durcissement, devant ecdsa-sha2-nistp256 et très loin devant RSA. La clé Ed25519 est plus courte, la signature est plus rapide à vérifier et le risque d’une mauvaise implémentation côté client est structurellement plus faible.

La couche transport elle-même a évolué plus vite que la couche signature. Selon l’analyse publiée par Sesame Disk dans sa série sur la fin annoncée de la cryptographie à clé publique classique, OpenSSH propose un échange de clés post-quantique par défaut depuis la version 9.0, sortie en 2022, et la version 10.0 d’OpenSSH bascule par défaut sur mlkem768x25519-sha256, qui combine X25519 avec le mécanisme post-quantique ML-KEM-768. La version 10.1 va plus loin en avertissant explicitement l’administrateur lorsqu’une session retombe sur un échange non hybride. Les clés de signature SSH, elles, qu’elles soient RSA, ECDSA ou Ed25519, n’ont aucune exposition immédiate au scénario de récolte puis déchiffrement différé, mais devront être retirées avant qu’un ordinateur quantique suffisamment puissant n’existe, car l’algorithme de Shor casse les trois de la même manière.

secp256k1 : la courbe à part de Bitcoin et Ethereum

secp256k1 occupe une place singulière dans ce comparatif parce qu’elle est pratiquement absente de la PKI web et de TLS généraliste, mais omniprésente dans un seul secteur qui pèse plusieurs milliers de milliards de dollars de valeur sécurisée : les cryptomonnaies. Bitcoin et Ethereum signent chaque transaction avec ECDSA sur secp256k1, un choix hérité directement du design original de Bitcoin en 2009 et jamais remis en cause depuis par les deux plus grandes blockchains au monde, malgré l’émergence d’alternatives comme Ed25519 chez des blockchains plus récentes.

Cette concentration sur un seul secteur a une conséquence directe sur l’écosystème logiciel : les portefeuilles matériels, les modules HSM spécialisés dans la garde d’actifs numériques et certains services cloud comme AWS KMS exposent secp256k1 en priorité, alors que des services plus généralistes comme Google Cloud KMS ne la listent pas officiellement parmi leurs courbes supportées. Un développeur qui construit une infrastructure de signature de transactions blockchain doit donc choisir ses fournisseurs cloud et ses HSM en fonction de ce support spécifique, un critère qui n’existe simplement pas pour un projet centré sur P-256 ou Curve25519.

Sur le plan de la sécurité pure, secp256k1 n’a rien de spécial par rapport à P-256 : même niveau de sécurité classique d’environ 128 bits, même vulnérabilité totale face à un ordinateur quantique suffisamment puissant exécutant l’algorithme de Shor. La différence n’est donc pas mathématique mais entièrement liée à l’écosystème et à l’inertie historique d’un secteur qui ne peut pas changer de courbe sans casser la compatibilité avec des milliards de clés déjà en circulation sur la chaîne.

Les portefeuilles matériels vendus en France et en Europe, qu’il s’agisse de modèles grand public ou de solutions professionnelles de garde, implémentent tous secp256k1 en priorité pour la partie Bitcoin et Ethereum, souvent aux côtés de Curve25519 pour les blockchains plus récentes qui ont fait un autre choix de conception. Cette double implémentation illustre bien le statut particulier de secp256k1 : elle n’est jamais le choix par défaut d’un nouveau projet cryptographique généraliste, mais elle reste un passage obligé pour tout acteur qui touche de près ou de loin à l’écosystème Bitcoin et Ethereum, des exchanges régulés aux services de conservation d’actifs numériques destinés aux institutionnels.

La menace quantique : pourquoi Shor met fin aux quatre courbes

Les quatre courbes reposent sur le même problème mathématique, le logarithme discret sur courbe elliptique, et c’est exactement le problème que l’algorithme de Shor résout en temps polynomial sur un ordinateur quantique suffisamment grand. Le fieldguide de LaMarr Labs rappelle que casser une courbe de 256 bits a été estimé à environ 2 330 qubits logiques selon une évaluation de 2017, un chiffre révisé à la baisse à 1 200 ou 1 450 qubits logiques dans un whitepaper publié par Google Quantum AI en 2026. Cette révision ne change rien à la conclusion finale, puisque le NIST, dans son rapport interne IR 8547, interdit déjà l’usage de P-256 comme de Curve25519 après 2035, mais elle réduit la marge de temps dont dispose l’industrie pour migrer.

Passer de P-256 à P-384 n’apporte strictement aucune protection face à cette menace. Les deux courbes reposent sur le même problème de logarithme discret, et un ordinateur quantique suffisamment puissant pour casser l’une casse l’autre à un coût comparable. Augmenter la taille de la courbe classique achète de la marge contre un ordinateur classique, pas contre un ordinateur quantique, une nuance que beaucoup de feuilles de route de migration confondent encore en 2026.

Le contexte s’est encore tendu début septembre 2026, lorsque deux records de factorisation purement classique sont tombés en seize jours : RSA-260 le 3 septembre, factorisé par Eric Lu chez Cognition avec l’aide de l’agent autonome Devin pour environ 400 000 dollars de calcul GPU, puis RSA-896 le 19 septembre, factorisé par l’ingénieur Anthropic Stephen A. Weis après que Claude a adapté le crible algébrique général à des GPU et coordonné 2 048 d’entre eux. Aucune clé RSA-2048 déployée n’a été affectée dans les deux cas, et aucune de ces avancées ne concerne directement les courbes elliptiques, mais elles rappellent, selon l’analyse publiée par Sesame Disk, que le coût d’ingénierie pour casser des problèmes mathématiques déjà compris depuis des décennies continue de baisser, aussi bien côté classique que côté quantique.

Les échanges hybrides post-quantiques : X25519 + ML-KEM en production

Face à une menace quantique qui touche les quatre courbes de façon identique, l’industrie n’a pas choisi de remplacer une courbe elliptique par une courbe plus grande, mais de superposer un mécanisme post-quantique au-dessus de la courbe classique existante. Le mécanisme hybride X25519MLKEM768 combine l’échange X25519 avec le KEM post-quantique ML-KEM-768 standardisé par le NIST, de façon à conserver la protection classique déjà éprouvée pendant que la couche post-quantique se généralise et se fait auditer en conditions réelles.

OpenSSH illustre bien ce calendrier de déploiement progressif. La version 9.0, sortie en 2022, a introduit un échange de clés post-quantique par défaut. La version 10.0 a basculé par défaut sur mlkem768x25519-sha256, qui combine X25519 et ML-KEM-768 exactement comme sur le web. La version 10.1 a ajouté un avertissement explicite quand une connexion retombe sur un échange purement classique, un signal destiné aux administrateurs système qui doivent justement repérer les équipements encore en retard. Cette approche hybride a un avantage opérationnel immédiat : elle ne nécessite pas d’attendre un nouveau cycle complet de confiance publique PKI, puisqu’elle s’appuie sur des primitives classiques déjà en place, X25519, tout en ajoutant une couche post-quantique en parallèle.

Les clés de signature, elles, suivent un calendrier différent et plus lent. Ni Ed25519, ni ECDSA sur P-256, P-384 ou secp256k1 ne sont exposées au scénario de récolte puis déchiffrement différé qui menace l’échange de clés de session, puisqu’une signature n’a pas besoin de rester confidentielle. Mais elles devront toutes migrer vers des schémas post-quantiques comme ML-DSA avant l’arrivée d’un ordinateur quantique suffisamment puissant, car l’algorithme de Shor s’applique de façon identique à la signature et à l’échange de clés.

Cinq cas d’usage concrets pour choisir sa courbe

Certificat TLS d’un site web grand public : P-256 reste le choix par défaut le plus sûr pour la compatibilité, parce que la quasi-totalité des navigateurs, des CDN et des modules matériels de sécurité en circulation la supportent nativement, et qu’elle offre la meilleure vitesse de vérification du groupe selon l’OpenSSL Cookbook.
Clé d’administration SSH pour une équipe DevOps : Ed25519 s’est imposée comme la recommandation de facto, avec une clé plus courte à copier, une signature plus rapide à vérifier à chaque connexion et une résistance native aux erreurs de mise en œuvre que P-256 ne garantit pas par construction.
Messagerie chiffrée et VPN moderne : X25519 pour l’échange de clés et Ed25519 pour les signatures forment la paire par défaut de Signal et de WireGuard, un choix cohérent avec la volonté de ces deux projets de limiter la surface d’erreur d’implémentation.
Signature de transactions blockchain : secp256k1 reste incontournable pour tout ce qui touche à Bitcoin ou Ethereum, non pas pour une raison de sécurité supérieure mais parce que changer de courbe casserait la compatibilité avec l’historique complet de la chaîne.
Système gouvernemental ou classifié soumis à la suite CNSA : P-384 devient alors la seule option conforme, puisque le NIST SP 800-186 la classe au niveau de sécurité classique le plus élevé parmi les quatre courbes, malgré un coût de calcul mesuré jusqu’à 40 fois supérieur à P-256 selon le test mirage-crypto-rng.

Ces cinq cas ne sont pas exhaustifs, mais ils couvrent la très grande majorité des décisions concrètes auxquelles un ingénieur ou un architecte est confronté en 2026, des certificats web grand public jusqu’à la garde d’actifs numériques, en passant par les systèmes soumis à des exigences réglementaires renforcées.

Guide de migration : passer d’une courbe à une autre sans tout casser

Changer de courbe elliptique en production n’est jamais un simple remplacement de fichier de configuration. Voici les étapes concrètes pour sécuriser la transition, qu’il s’agisse de passer de RSA à P-256, de P-256 à Ed25519, ou de préparer l’arrivée des échanges hybrides post-quantiques.

Auditer l’inventaire existant. Lister toutes les clés, certificats et paires utilisées en production, leur courbe actuelle, leur date d’expiration et les systèmes qui les consomment, avant de décider quoi migrer en premier.
Vérifier la compatibilité des bibliothèques clientes. OpenSSL 1.1.1 et ses versions ultérieures, BoringSSL et libsodium supportent toutes Curve25519 et P-256, mais certains clients anciens ou certains modules matériels n’acceptent qu’une liste restreinte de courbes NIST.
Générer les nouvelles clés en parallèle de l’ancienne. Pour SSH, la commande ssh-keygen -t ed25519 génère une nouvelle paire sans toucher à la clé existante, ce qui permet de tester la nouvelle courbe avant toute coupure.
Mettre en place une période de double validation. Accepter simultanément l’ancienne et la nouvelle courbe côté serveur pendant plusieurs semaines, pour laisser le temps aux clients les plus anciens de se mettre à jour sans interruption de service.
Basculer progressivement les points de confiance. Mettre à jour les autorités de certification, les HSM et les clients un groupe à la fois, en commençant par les environnements de test puis en élargissant vers la production.
Révoquer les anciennes clés et documenter la rotation. Une fois la bascule confirmée, révoquer formellement les clés de l’ancienne courbe et consigner la date, la raison et le périmètre du changement pour les audits futurs.
Anticiper la couche hybride post-quantique en parallèle. Pour les échanges de clés de session, prévoir dès maintenant l’activation d’un mécanisme hybride comme X25519MLKEM768 ou mlkem768x25519-sha256, qui ajoute une protection post-quantique sans retirer la couche classique existante.

# Générer une clé Ed25519 pour remplacer une clé RSA ou ECDSA
ssh-keygen -t ed25519 -C "[email protected]"

# Générer une paire ECDSA sur P-256 avec OpenSSL
openssl ecparam -name prime256v1 -genkey -noout -out p256.key

# Générer une paire ECDSA sur P-384 avec OpenSSL
openssl ecparam -name secp384r1 -genkey -noout -out p384.key

# Vérifier quelles courbes un serveur TLS 1.3 propose en priorité
openssl s_client -connect exemple.fr:443 -curves X25519:P-256:P-384

Le point le plus souvent négligé dans ces migrations, selon l’analyse de Sesame Disk sur la gestion des clés SSH, n’est pas le choix de la courbe mais l’hygiène de clés elle-même. La plupart des déploiements d’entreprise accumulent un grand nombre de clés inutilisées et de clés disposant de privilèges root qui n’expirent jamais, un problème qui persiste quelle que soit la courbe choisie et qui rend toute migration bien plus risquée qu’elle ne devrait l’être.

Avantages et inconvénients de chaque courbe

P-256 (secp256r1)

Avantage : compatibilité maximale avec les navigateurs, les HSM et les infrastructures PKI existantes.
Avantage : meilleure vitesse de vérification mesurée du groupe selon l’OpenSSL Cookbook, 20 508 opérations par seconde.
Inconvénient : provenance du paramètre non entièrement expliquée par le NIST, ce qui alimente un débat de confiance depuis des années.
Inconvénient : arithmétique de Weierstrass qui n’impose pas nativement le temps constant, laissant plus de place à l’erreur d’implémentation.

P-384 (secp384r1)

Avantage : niveau de sécurité classique le plus élevé du groupe, environ 192 bits, requis par la suite CNSA pour les systèmes classifiés.
Avantage : standard NIST documenté dans SP 800-186, ce qui facilite la conformité réglementaire.
Inconvénient : jusqu’à 40 fois plus lent en signature que P-256 selon le test mirage-crypto-rng.
Inconvénient : aucune protection supplémentaire face à un ordinateur quantique malgré le surcoût de calcul.

Curve25519 / Ed25519 / X25519

Avantage : génération de paramètres entièrement rigide et publique, sans valeur à justifier après coup.
Avantage : temps constant natif grâce au clamping Montgomery, ce qui réduit les classes d’erreurs d’implémentation.
Avantage : choix par défaut de SSH, Signal et WireGuard, avec une large validation en conditions réelles.
Inconvénient : support encore incomplet dans certains services cloud managés comme Google Cloud KMS, qui ne la liste pas officiellement.

secp256k1

Avantage : support natif et prioritaire dans les HSM spécialisés en garde d’actifs numériques et dans AWS KMS.
Avantage : compatibilité totale avec l’historique complet de Bitcoin et Ethereum, un atout décisif pour cet écosystème précis.
Inconvénient : pratiquement absente de la PKI web et de TLS généraliste, ce qui limite son utilité en dehors des cryptomonnaies.
Inconvénient : non listée officiellement dans Google Cloud KMS, ce qui oblige à passer par des bibliothèques logicielles tierces.

Le verdict : quelle courbe pour quel projet en 2026

Il n’existe pas de courbe universellement meilleure parmi ces quatre, et les chiffres rassemblés dans ce comparatif le confirment plutôt qu’ils ne le contredisent. P-256, Curve25519 et secp256k1 offrent toutes les trois environ 128 bits de sécurité classique avec des performances comparables selon les benchmarks de l’OpenSSL Cookbook, de mirage-crypto-rng et de @noble/curves. Le choix entre elles ne dépend donc pas de la robustesse mathématique mais de l’écosystème dans lequel le projet s’inscrit : P-256 pour la compatibilité web et PKI la plus large, Curve25519 pour SSH, la messagerie chiffrée et tout projet qui privilégie une résistance native aux erreurs d’implémentation, secp256k1 pour tout ce qui touche à Bitcoin et Ethereum.

P-384 reste à part. Elle n’apporte un bénéfice réel que lorsque la politique de sécurité exige explicitement 192 bits plutôt que 128, typiquement dans un contexte gouvernemental ou militaire régi par la suite CNSA, et son surcoût de calcul, mesuré jusqu’à 40 fois supérieur à P-256 selon mirage-crypto-rng, en fait un mauvais choix par défaut pour un service grand public qui n’a aucune obligation réglementaire de ce niveau.

Le vrai basculement de 2026 ne se joue plus entre ces quatre courbes classiques mais au-dessus d’elles. Qu’un projet choisisse P-256, Curve25519 ou secp256k1, la question qui compte désormais est de savoir s’il a déjà activé une couche hybride post-quantique comme X25519MLKEM768 ou mlkem768x25519-sha256, puisque l’algorithme de Shor rendra les quatre courbes classiques également obsolètes le jour où un ordinateur quantique suffisamment puissant existera. D’ici là, le choix de la courbe reste une décision d’ingénierie pragmatique, pas une question de sécurité absolue.

FAQ : les questions les plus posées sur les courbes elliptiques

P-256 et secp256r1 sont-elles la même courbe ?

Oui. P-256 est le nom donné par le NIST, secp256r1 est le nom utilisé par le standard SECG, et prime256v1 est le nom utilisé par ANSI X9.62 et par OpenSSL. Les trois désignent exactement le même objet mathématique, une courbe de Weierstrass définie sur un champ premier de 256 bits.

Pourquoi secp256k1 n’est-elle pas plus utilisée en dehors des cryptomonnaies ?

Pas pour une raison de sécurité, puisqu’elle offre le même niveau de sécurité classique qu’une courbe P-256. L’explication est historique et logicielle : l’écosystème TLS, PKI et SSH s’est construit autour de P-256 et de Curve25519, et les bibliothèques, les HSM et les services cloud grand public ne l’ont jamais intégrée par défaut en dehors du secteur blockchain qui l’a adoptée dès 2009.

Faut-il migrer de P-256 vers P-384 pour se protéger du risque quantique ?

Non. Les deux courbes reposent sur le même problème de logarithme discret, que l’algorithme de Shor résout en temps polynomial sur un ordinateur quantique suffisamment puissant, quelle que soit la taille de la courbe. Passer à P-384 augmente seulement la marge de sécurité classique, pas la résistance quantique. La vraie protection passe par des mécanismes hybrides comme X25519MLKEM768.

Ed25519 est-elle plus sûre que ECDSA sur P-256 ?

Les deux offrent le même niveau de sécurité classique théorique, environ 128 bits. La différence se situe dans la sécurité d’implémentation : Ed25519 impose un temps constant par construction et élimine certaines classes d’erreurs qui ont déjà causé des failles réelles sur des implémentations ECDSA mal réalisées, ce qui en fait un choix généralement considéré comme plus robuste en pratique, sans que cela ne traduise une différence de force mathématique brute.

AWS KMS, Google Cloud KMS et Azure Key Vault supportent-ils toutes les mêmes courbes ?

Non. AWS KMS liste officiellement P-256, P-384, P-521 et secp256k1. Google Cloud KMS liste officiellement P-256 et P-384 sans confirmer secp256k1 ni Ed25519 dans son offre standard. Azure Key Vault classe les clés ECC dans une catégorie avancée sans préciser quelle courbe précise est couverte sur sa page de tarification publique, ce qui impose de vérifier directement auprès du support pour un usage spécifique.

Combien de temps reste-t-il avant que les courbes elliptiques classiques deviennent obsolètes ?

Le NIST, dans son rapport interne IR 8547, fixe une échéance de retrait après 2035 pour P-256 comme pour Curve25519. Cette date pourrait avancer si les estimations de qubits logiques nécessaires continuent de baisser, comme elles l’ont déjà fait entre l’estimation de 2017, environ 2 330 qubits, et celle publiée par Google Quantum AI en 2026, entre 1 200 et 1 450 qubits.

Quelle courbe choisir pour un nouveau projet en 2026 sans contrainte héritée ?

Pour un projet qui démarre sans contrainte de compatibilité héritée, Curve25519 et sa variante Ed25519 représentent généralement le meilleur compromis entre sécurité d’implémentation, performance et adoption par les protocoles modernes comme SSH, Signal et WireGuard. P-256 reste néanmoins incontournable si le projet doit délivrer des certificats TLS publics compatibles avec le plus grand nombre de clients possible.

Ces courbes fonctionnent-elles sur des objets connectés ou des cartes à puce aux ressources limitées ?

Oui, mais pas de façon équivalente. Curve25519 a été conçue dès le départ pour minimiser le code nécessaire à son implémentation et éviter les branchements conditionnels liés au temps constant, ce qui en fait un choix fréquent pour les microcontrôleurs et les objets connectés à ressources limitées. P-256 reste également largement supportée sur les cartes à puce et les éléments sécurisés grâce à des années d’optimisations matérielles dédiées, tandis que P-384 est généralement réservée aux appareils qui disposent de davantage de puissance de calcul, en raison du surcoût mesuré dans les benchmarks de ce comparatif.