Deux courbes elliptiques se disputent la même place dans la quasi-totalité des systèmes de sécurité modernes : Ed25519 et ECDSA sur la courbe P-256. OpenSSH, WireGuard, Signal, Tor et une bonne partie du web sécurisé s’appuient sur l’une ou l’autre, parfois sur les deux à la fois. Pourtant, quand vient le moment de générer une clé ou de configurer un certificat, la question revient sans cesse : laquelle choisir en 2026, et pourquoi les deux survivent-elles alors qu’elles répondent au même problème mathématique ?

La réponse tient en une phrase que ce comparatif va détailler avec des chiffres : Ed25519 gagne presque partout où le protocole peut être modifié librement, tandis qu’ECDSA P-256 reste incontournable là où la compatibilité X.509, les certifications FIPS et le matériel existant imposent leurs contraintes. Entre les deux, il y a des benchmarks concrets, des tailles de clés mesurables en octets, une adoption réelle chez OpenSSH, Cloudflare ou Let’s Encrypt, et une échéance commune : la migration post-quantique. Ce guide passe en revue chaque angle, avec des tableaux, un plan de migration et un verdict par cas d’usage.

Le sujet n’a rien d’académique. Une équipe qui génère aujourd’hui des milliers de clés SSH, configure un mesh de microservices en mTLS, ou choisit l’algorithme de signature d’un jeton JWT, prend une décision qui restera en place plusieurs années. Se tromper coûte cher : réémettre des certificats en urgence, migrer une flotte de serveurs, ou justifier un choix non conforme devant un auditeur FIPS. Ce comparatif s’appuie uniquement sur des benchmarks publiés, des standards officiels (RFC, FIPS, ANSSI) et des cas d’adoption vérifiables, sans extrapolation.

Ed25519 et ECDSA P-256 : deux courbes, deux philosophies

ECDSA P-256 (aussi appelée secp256r1 ou prime256v1) appartient à la famille des courbes de Weierstrass standardisées par le NIST dans les années 2000. Elle hérite de trois décennies de spécifications, de bibliothèques auditées et d’intégrations dans quasiment tous les frameworks TLS, PKI et HSM du marché. Sa signature repose sur un nombre aléatoire k généré à chaque opération, ce qui a causé plusieurs incidents historiques quand ce générateur aléatoire était défaillant (le cas Sony PS3 en 2010 reste l’exemple le plus cité de la profession).

Ed25519 est plus récent. Conçu par Daniel J. Bernstein, Niels Duif, Tanja Lange, Peter Schwabe et Bo-Yin Yang, il repose sur EdDSA (Edwards-curve Digital Signature Algorithm) appliqué à Curve25519, une courbe de Edwards tordue publiée dès 2005 pour l’échange de clés puis reprise pour la signature. Sa spécification est figée par la RFC 8032 de l’IETF. Contrairement à ECDSA, Ed25519 est déterministe : la même clé et le même message produisent toujours la même signature, sans générateur aléatoire à sécuriser lors de chaque opération. C’est la différence structurelle qui explique une bonne partie de l’écart de performance et de fiabilité entre les deux systèmes.

Comment fonctionne Ed25519 (EdDSA sur Curve25519)

Ed25519 combine trois choix de conception qui simplifient l’implémentation. D’abord, la courbe elle-même (Curve25519, un premier proche de 2^255) a été choisie pour éviter les faiblesses connues des courbes plus anciennes et pour permettre une arithmétique rapide en logiciel pur, sans instruction matérielle spécialisée. Ensuite, la signature est déterministe : la valeur habituellement aléatoire (le nonce) est dérivée du message et de la clé privée par hachage, ce qui supprime toute une classe de vulnérabilités liées à un générateur aléatoire compromis ou biaisé. Enfin, les tailles sont fixes : une clé publique tient sur 32 octets et une signature sur 64 octets, sans encodage variable.

Ce choix de conception a un effet direct sur la sécurité pratique. Là où ECDSA doit être implémenté avec un luxe de précautions (temps constant, protection contre les fuites de cache, génération aléatoire de qualité pour chaque signature), Ed25519 réduit mécaniquement la surface d’erreur pour les développeurs de bibliothèques cryptographiques. C’est aussi pour cette raison que Google, Signal, Tor et l’équipe WireGuard l’ont adopté dès que leurs protocoles ont pu être conçus sans contrainte de rétrocompatibilité X.509.

Sur du matériel contraint, comme un microcontrôleur IoT ou une carte à puce bas de gamme, la simplicité arithmétique d’Ed25519 se traduit aussi par un code plus compact et plus facile à auditer manuellement, un avantage réel pour les équipes qui doivent faire certifier leur firmware sans disposer d’un budget d’audit cryptographique important. C’est un argument que l’on retrouve régulièrement dans les choix d’architecture des fabricants de clés de sécurité matérielles, où chaque kilooctet de code embarqué et chaque cycle processeur économisé comptent directement dans le coût de fabrication.

Comment fonctionne ECDSA sur la courbe P-256

ECDSA P-256 applique l’algorithme de signature à courbe elliptique standard (ECDSA) sur la courbe NIST P-256, normalisée dans la norme FIPS 186-5 du NIST. Chaque signature nécessite un nombre aléatoire éphémère k, propre à chaque opération. Si ce nombre est réutilisé, biaisé ou partiellement prévisible, un attaquant peut reconstruire la clé privée à partir de deux signatures seulement, c’est le mécanisme exact qui a permis de casser la clé de signature de la PS3 en 2010. Les bibliothèques modernes corrigent ce risque avec un mode déterministe défini par la RFC 6979, mais toutes les implémentations ne l’activent pas par défaut.

En contrepartie, P-256 profite d’un écosystème que peu d’algorithmes égalent : elle est intégrée nativement dans quasiment tous les HSM du marché, certifiée FIPS 140-3, acceptée par tous les navigateurs et autorités de certification, et supportée par les cartes à puce gouvernementales depuis plus d’une décennie. C’est la courbe par défaut de la PKI web actuelle, et elle représentait 49,7 % des certificats TLS analysés par les logs de Certificate Transparency en juillet 2026, contre 34,5 % huit mois plus tôt, un basculement rapide au détriment de RSA plutôt que d’Ed25519.

Tableau comparatif technique complet

Voici la comparaison technique ligne par ligne entre les deux courbes, sur les critères qui comptent réellement au moment de choisir un algorithme pour un nouveau projet.

CritèreEd25519ECDSA P-256
Type de courbeEdwards tordue (Curve25519)Weierstrass (secp256r1)
Norme de référenceRFC 8032 (IETF)FIPS 186-5 (NIST)
Niveau de sécurité classique≈ 128 bits≈ 128 bits
Taille de clé publique32 octets fixes65 octets non compressée / 33 compressée
Taille de signature64 octets fixes≈ 70-72 octets (encodage DER variable)
Signature déterministeOui, nativementNon par défaut (sauf RFC 6979)
Dépendance à un générateur aléatoire par signatureAucuneOui, critique pour la sécurité
Approuvé FIPS 140-3Non, à ce jourOui
Support HSM et cartes à pucePartiel, en progressionQuasi universel
Défaut dans OpenSSHOui, depuis la version 6.5 (2014)Toujours supportée, plus rarement recommandée
Usage dominant en certificats TLS publicsMarginal (compatibilité X.509 limitée)Dominant, 49,7 % des certificats mi-2026
Résistance à l’ordinateur quantiqueAucune (Shor casse la courbe)Aucune (Shor casse la courbe)

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

Les chiffres de performance varient selon le matériel, la bibliothèque et l’année de mesure, ce qui explique pourquoi il faut croiser plusieurs sources plutôt que se fier à un seul benchmark. Sur un cœur x86 récent, une synthèse de performance 2026 mesure environ 30 000 signatures par seconde pour ECDSA P-256 contre 50 000 pour Ed25519, soit un gain d’environ 1,7 fois en faveur d’Ed25519 côté signature. Sur la vérification, l’écart se resserre nettement : un jeu de benchmarks portant sur la période 2023-2026 relève environ 10 499 vérifications par seconde pour P-256 contre 11 870 pour Ed25519, un avantage plus modeste d’environ 13 %.

Un troisième point de mesure, publié fin 2025 sur architecture ARM, donne cette fois ECDSA P-256 à 53 009 signatures par seconde, avec EdDSA dans la même bande de performance, preuve que l’écart se réduit avec les implémentations récentes et optimisées. Un travail plus ancien réalisé lors d’un atelier de standardisation ECC du NIST comparait une implémentation OpenSSL optimisée de P-256 (NISTZ256), mesurée à 29 938 signatures et 11 842 vérifications par seconde, aux meilleures implémentations d’Ed25519 disponibles à l’époque, jusqu’à 3,7 fois plus rapides en signature et 6,8 fois en vérification. Ce dernier chiffre, plus ancien, illustre surtout à quel point la qualité de l’implémentation pèse davantage que la théorie mathématique brute.

Un cas où P-256 va plus vite : le DNSSEC

Tous les benchmarks ne penchent pas du côté d’Ed25519. Une étude opérationnelle sur la signature de zones DNSSEC mesurait un temps de signature de 3 200 secondes pour RSA 2048, 450 secondes pour ECDSA P-256 et 810 secondes pour Ed25519 sur une même zone volumineuse. Dans cette chaîne d’outils précise, P-256 se montrait 1,8 fois plus rapide qu’Ed25519, un résultat qui reflète des choix d’implémentation dans les logiciels DNS de l’époque plutôt qu’une limite intrinsèque de la courbe. Ce contre-exemple rappelle une règle simple : le benchmark qui compte est celui de votre propre pile logicielle, pas celui d’un papier de recherche générique.

Un dernier facteur pèse rarement dans les comparatifs mais influence directement la latence perçue par un utilisateur final : l’accélération matérielle. Les processeurs Intel et AMD récents intègrent des instructions dédiées à l’arithmétique modulaire utilisée par les deux courbes, mais l’écosystème logiciel autour d’ECDSA P-256 (OpenSSL NISTZ256, BoringSSL) bénéficie d’un travail d’optimisation plus ancien et plus large que celui d’Ed25519, ce qui explique en partie pourquoi l’écart mesuré varie autant d’une bibliothèque à l’autre. Sur des puces ARM récentes ou du matériel embarqué sans optimisation poussée, Ed25519 conserve généralement l’avantage grâce à une arithmétique plus simple à vectoriser correctement.

Source du benchmarkECDSA P-256Ed25519Avantage mesuré
Synthèse performance 2026, x86 mono-cœur~30 000 sign/s~50 000 sign/sEd25519, 1,7x en signature
Jeu de benchmarks 2023-2026, vérification~10 499 verif/s~11 870 verif/sEd25519, +13 % en vérification
Benchmark ARM, fin 202553 009 sign/sMême bande de performanceÉcart réduit sur ARM récent
Atelier NIST, OpenSSL NISTZ256 optimisé29 938 sign/s, 11 842 verif/sJusqu’à 3,7x / 6,8x plus rapide (implémentations optimisées)Ed25519, écart historique important
Étude opérationnelle DNSSEC (signature de zone)450 s pour la zone testée810 s pour la zone testéeP-256, 1,8x plus rapide dans cette pile

Taille des clés et des signatures : l’avantage structurel d’Ed25519

Sur le papier, les deux courbes offrent un niveau de sécurité comparable, autour de 128 bits. La différence se joue sur la taille effective des objets manipulés. Une clé publique Ed25519 tient toujours sur 32 octets. Une clé publique P-256 non compressée occupe 65 octets, ou 33 octets sous forme compressée, un format que tous les logiciels ne savent pas décoder correctement. Côté signature, Ed25519 produit systématiquement 64 octets, quel que soit le message. ECDSA encode sa signature en ASN.1 DER, ce qui donne une taille variable, généralement comprise entre 70 et 72 octets selon les valeurs r et s obtenues.

Cet écart paraît anecdotique à l’unité, mais il compte à grande échelle. Un serveur DNS qui signe des millions d’enregistrements, un registre de certificats transparents qui archive des milliards de signatures, ou un protocole embarqué avec un budget de quelques kilooctets par paquet, ressentent directement l’effet cumulé d’une taille fixe et prévisible face à un encodage variable qu’il faut analyser avant de savoir combien d’octets réserver.

La prévisibilité du format compte autant que la taille brute. Un développeur qui alloue un tampon mémoire pour une signature Ed25519 sait qu’il en aura toujours besoin de 64 octets, ni plus ni moins. Avec ECDSA, il doit soit allouer une taille maximale par prudence, soit parser l’encodage DER pour connaître la taille exacte avant de la stocker, une étape supplémentaire qui a déjà été source de bugs d’analyse syntaxique (parsing) dans plusieurs bibliothèques historiques. Ce n’est pas un hasard si les formats de jetons modernes, pensés pour être légers et faciles à valider côté client mobile ou objet connecté, privilégient de plus en plus les signatures à taille fixe.

Sécurité, canaux auxiliaires et CVE 2025-2026

Aucune faille structurelle n’a été rendue publique en 2025 ou en 2026 contre le problème mathématique sous-jacent d’Ed25519 ou d’ECDSA P-256. Les incidents recensés sur cette période concernent presque exclusivement des bugs d’implémentation dans des bibliothèques (OpenSSL, NSS, libgcrypt, BoringSSL, libsodium) : multiplication scalaire non exécutée en temps constant, fuite via le cache processeur, ou validation incorrecte des paramètres de signature. Ces vulnérabilités touchent en général plusieurs courbes à la fois, RSA, P-256 et X25519 compris, parce qu’elles résident dans le code partagé plutôt que dans les mathématiques de la courbe elle-même.

La différence de conception reste néanmoins déterminante en pratique. Le caractère déterministe d’Ed25519 élimine par construction toute la classe de vulnérabilités liées à un nonce k faible ou réutilisé, celle qui a historiquement coûté leur clé privée à plusieurs éditeurs ayant mal implémenté ECDSA. À l’inverse, une implémentation ECDSA qui ne suit pas la RFC 6979 (signature déterministe) reste exposée à ce risque si son générateur aléatoire est défaillant, sous-alimenté en entropie, ou partagé entre plusieurs opérations. Le risque n’est donc pas théorique : c’est un défaut d’ingénierie qui reste possible avec P-256 et structurellement écarté avec Ed25519.

Ed25519 dans les jetons JWT et les API modernes

Au-delà du SSH et du TLS, la troisième bataille se joue dans les jetons d’authentification. La spécification JOSE (JSON Object Signing and Encryption) définit l’algorithme EdDSA pour signer des JWT avec Ed25519, formalisé dans la RFC 8037 de l’IETF, aux côtés d’ES256, l’identifiant standard pour ECDSA P-256 combiné à SHA-256. La majorité des fournisseurs d’identité et des plateformes OAuth 2.0 / OpenID Connect proposent encore ES256 comme algorithme par défaut, hérité de la norme historique et de la compatibilité avec les bibliothèques JOSE les plus anciennes, mais le support d’EdDSA progresse dans les SDK récents à mesure que les développeurs cherchent des jetons plus compacts et plus rapides à vérifier côté client.

Pour une API qui vérifie des milliers de jetons par seconde, la différence entre ES256 et EdDSA se traduit directement en charge CPU sur les passerelles d’authentification. Un jeton signé en Ed25519 reste plus court de quelques octets une fois encodé en Base64URL, un gain marginal à l’unité mais mesurable à l’échelle d’un trafic API à fort volume. La contrepartie reste la même que pour le TLS : certains clients mobiles anciens ou certaines bibliothèques JWT peu maintenues ne savent pas encore vérifier une signature EdDSA, ce qui pousse la plupart des équipes à proposer ES256 par défaut et EdDSA en option pour les nouveaux clients qui le supportent explicitement.

Adoption réelle : qui utilise quoi, et depuis quand

La théorie ne suffit pas à trancher un choix d’architecture, alors regardons qui a effectivement déployé chaque courbe, et pourquoi.

  • OpenSSH propose Ed25519 comme type de clé par défaut depuis la version 6.5, publiée en 2014, et continue de le recommander en 2026 pour les nouvelles clés utilisateur et hôte.
  • WireGuard utilise Curve25519 (X25519) pour l’échange de clés depuis sa conception initiale, un choix documenté directement dans la spécification du protocole, en production depuis environ 2018.
  • Signal repose sur Curve25519 et Ed25519 pour son protocole X3DH d’établissement de session chiffrée, en place depuis le lancement du protocole vers 2014 et toujours au cœur du chiffrement de bout en bout de l’application.
  • Tor a migré ses services onion vers des identifiants Ed25519 avec la version 3 du protocole (v3 onion services), déployée autour de 2015-2016. L’adresse .onion à 56 caractères que l’on croise aujourd’hui dérive directement de la clé publique Ed25519 du service, contre 16 caractères pour l’ancien format basé sur RSA.
  • Cloudflare a été l’un des premiers grands CDN à déployer massivement des certificats ECDSA P-256 pour réduire le coût de la poignée de main TLS par rapport à RSA, un choix toujours dominant sur son infrastructure en 2026.
  • Let’s Encrypt a ajouté le support d’ECDSA P-256 pour les clés de compte et les certificats après son lancement en RSA, et P-256 reste aujourd’hui le principal choix ECC de la PKI web publique, faute d’un support universel d’Ed25519 côté navigateurs et clients TLS.
  • GitHub et GitLab acceptent et recommandent les clés SSH Ed25519 pour l’accès développeur depuis plusieurs années, en plus du support historique de RSA et d’ECDSA.
  • Les fournisseurs cloud majeurs (AWS, Google Cloud, Azure) héritent du comportement par défaut d’OpenSSH sur leurs images Linux, ce qui pousse Ed25519 comme choix naturel pour l’accès administrateur aux machines virtuelles.

Le motif qui ressort de cette liste est net : chaque fois qu’un protocole a pu être dessiné sans contrainte de compatibilité X.509, Ed25519 s’est imposé. Chaque fois que la contrainte PKI web ou la certification réglementaire pèse dans la balance, P-256 garde l’avantage.

Conformité réglementaire : NIST, ANSSI, BSI, FIPS

Le statut réglementaire reste le facteur le plus concret pour trancher dans un environnement contraint. Le NIST maintient P-256, P-384 et P-521 comme courbes de référence pour ECDSA dans la FIPS 186-5, le standard fédéral américain de signature numérique. Ed25519 et EdDSA ne figurent pas, à ce jour, parmi les algorithmes approuvés FIPS : ils sont largement utilisés dans les protocoles IETF et par l’industrie, mais restent hors du périmètre FIPS 140-3 exigé par de nombreux marchés publics et secteurs réglementés aux États-Unis.

En France, l’ANSSI publie son référentiel de mécanismes cryptographiques et a historiquement recommandé les courbes Brainpool avant d’accepter plus largement les courbes NIST et les courbes modernes de type Curve25519 selon le contexte d’usage. L’agence allemande BSI suit une logique similaire. Concrètement, en 2026, un acteur public français ou soumis à des obligations de certification a plus de chances de devoir justifier l’usage d’Ed25519 que celui de P-256, même si aucune des deux agences ne considère Ed25519 comme faible sur le plan cryptographique. C’est une question de statut administratif, pas de solidité mathématique.

Cette distinction administrative a un effet concret sur les appels d’offres publics et les audits de conformité. Un prestataire qui répond à un marché soumis à un référentiel de sécurité doit généralement démontrer que ses mécanismes cryptographiques figurent sur une liste validée, ce qui favorise mécaniquement ECDSA P-256 tant qu’Ed25519 n’y apparaît pas explicitement. Cette réalité administrative explique pourquoi certaines entreprises technologiques, pourtant convaincues de la supériorité technique d’Ed25519 pour leurs usages internes, continuent de proposer P-256 comme option par défaut sur leurs offres destinées au secteur public ou aux clients réglementés.

Coût réel : HSM, KMS et outillage

Le choix de courbe a un impact direct sur la facture cloud et le matériel à acheter, un angle rarement documenté alors qu’il pèse sur le budget d’une équipe sécurité. Les grands fournisseurs de gestion de clés facturent en général le même tarif quel que soit l’algorithme, mais le support d’Ed25519 reste plus limité selon le service choisi.

ServiceTarif indicatifSupport Ed25519
AWS KMS (clé asymétrique)1 $ par clé et par mois, même tarif pour toutes les familles de clésNon disponible nativement en 2026, ECDSA P-256/P-384 supportées
Google Cloud KMS, clé EC logicielle≈ 0,000082 $/heure, soit environ 0,06 $/moisECDSA P-256 supportée, Ed25519 non listée dans les courbes KMS
Google Cloud KMS, clé EC protégée HSM≈ 0,00137 $/heure jusqu’à 2 000 mois-versions, soit environ 1 $/moisECDSA uniquement
Azure Key Vault, clé protégée HSMFacturation par clé active et par version, montant précis publié sur la page officielle MicrosoftECDSA P-256/P-384/P-521 en priorité
Certificat Let’s EncryptGratuitECDSA P-256 supportée, Ed25519 non proposée en ACME public à ce jour
Certificat commercial ECC (Sectigo, gamme revendeur)Environ 20 $/an pour un domaine simple, jusqu’à 100 $/an pour un wildcardECDSA uniquement pour les certificats X.509 publics
YubiKey série 5À partir de 58 $Oui, signatures Ed25519 supportées
Nitrokey 3À partir de 49 €Oui, famille Curve25519 supportée

Les statistiques publiques de Let’s Encrypt confirment ce constat : côté certificats TLS publics et gestion de clés cloud managée, l’écosystème reste construit autour d’ECDSA. Côté clés SSH personnelles et clés d’authentification matérielle (YubiKey, Nitrokey), Ed25519 est parfaitement supporté et souvent recommandé par défaut par les fournisseurs eux-mêmes.

Le coût affiché sur une page tarifaire ne raconte qu’une partie de l’histoire. Une migration d’algorithme entraîne aussi un coût caché : temps d’ingénierie pour auditer les dépendances, formation des équipes support, et parfois renouvellement anticipé de matériel qui ne supporte qu’une seule famille de courbes. Pour une PME qui gère quelques dizaines de serveurs, ce coût reste marginal. Pour une organisation avec un parc de plusieurs milliers de machines ou une PKI interne complexe, le choix initial de courbe mérite d’être posé une seule fois, avec une marge de manœuvre pour la coexistence des deux algorithmes plutôt qu’un pari sur un seul.

Migration post-quantique : quel avenir pour chaque courbe

Aucune des deux courbes ne résiste à un ordinateur quantique suffisamment puissant. L’algorithme de Shor casse le problème du logarithme discret sur courbe elliptique, qu’il s’agisse de P-256 ou de Curve25519, avec la même efficacité théorique. La distinction entre les deux algorithmes ne joue donc aucun rôle dans la résistance post-quantique : ni Ed25519 ni ECDSA P-256 n’ont d’avantage décisif l’un sur l’autre face à cette menace.

Ce qui diffère, c’est la facilité de migration vers des schémas hybrides. Red Hat a par exemple documenté l’intégration d’échanges de clés post-quantiques hybrides dans OpenSSH 9.9, livré avec RHEL 10, sous la forme de sntrup761x25519-sha512 et mlkem768x25519-sha256, deux mécanismes qui combinent X25519 avec un algorithme post-quantique (NTRU Prime ou ML-KEM). Ce choix confirme que X25519 continuera d’exister comme brique classique au sein de constructions hybrides, plutôt que de disparaître d’un coup. Côté PKI web, la migration post-quantique des certificats X.509 s’appuiera très probablement sur ECDSA P-256 en configuration hybride avec un algorithme de signature post-quantique standardisé par le NIST, pour préserver la compatibilité avec l’écosystème existant.

Guide de migration : passer d’ECDSA P-256 à Ed25519

La migration ne se fait jamais en une seule étape sur l’ensemble d’un système d’information. Voici la marche à suivre par domaine, dans l’ordre où elle pose le moins de risques.

Migration des clés SSH

C’est le terrain le plus simple, car OpenSSH accepte Ed25519 depuis plus de dix ans et la compatibilité côté client est quasi totale en 2026. Générez d’abord une nouvelle paire de clés :

ssh-keygen -t ed25519 -a 100 -C "[email protected]"

Ajoutez ensuite la clé publique aux fichiers authorized_keys des serveurs concernés, en conservant l’ancienne clé ECDSA en parallèle jusqu’à validation complète. Testez la connexion avec la nouvelle clé sur un serveur non critique, vérifiez la compatibilité de vos outils de déploiement (Ansible, Terraform, agents CI/CD), puis révoquez progressivement les anciennes clés ECDSA une fois la bascule confirmée sur l’ensemble du parc.

Migration des certificats TLS et X.509

Sur ce terrain, la prudence s’impose. Le support d’Ed25519 dans les certificats X.509 publics reste inégal selon les navigateurs, les bibliothèques TLS embarquées et les anciens clients qui doivent encore se connecter à vos services. La recommandation pratique en 2026 consiste à conserver ECDSA P-256 pour tout certificat exposé publiquement, tout en surveillant l’évolution du support Ed25519 chez les autorités de certification et dans les navigateurs majeurs avant d’envisager une bascule. Pour un usage interne, entre services que vous contrôlez entièrement (mTLS interne, mesh de microservices), Ed25519 peut déjà être déployé sans risque de rupture de compatibilité, à condition que toute la chaîne logicielle interne le supporte.

Checklist avant la bascule complète

  • Inventoriez tous les clients qui se connecteront aux clés ou certificats concernés, y compris les outils d’automatisation et les intégrations tierces.
  • Vérifiez la version des bibliothèques cryptographiques utilisées côté client (OpenSSL, LibreSSL, BoringSSL) pour confirmer le support d’Ed25519.
  • Déployez en parallèle plutôt qu’en remplacement direct, avec une période de cohabitation des deux types de clés.
  • Surveillez les journaux d’authentification pour détecter les échecs de connexion liés à un client incompatible avant de couper l’ancien algorithme.
  • Documentez la procédure de rollback pour revenir à ECDSA P-256 en cas de blocage sur un système legacy.

Cas d’usage recommandés : quelle courbe pour quel projet

  • Clés SSH de serveurs et pipelines CI/CD : Ed25519, pour la vitesse de signature et l’absence de dépendance à un générateur aléatoire par opération.
  • Certificat TLS d’un site public grand public : ECDSA P-256, pour la compatibilité universelle avec les navigateurs et les anciens clients.
  • VPN d’équipe distribuée sous WireGuard : Curve25519/X25519, imposé nativement par le protocole et déjà optimisé dans le noyau Linux.
  • Application de messagerie chiffrée de bout en bout : Ed25519, pour son caractère déterministe qui réduit le risque d’erreur d’implémentation côté mobile.
  • Environnement réglementé (banque, défense, secteur public soumis à FIPS 140-3) : ECDSA P-256, tant qu’Ed25519 n’obtient pas de statut FIPS approuvé.
  • Signature de mise à jour logicielle interne (hors X.509) : Ed25519, pour la taille de signature fixe et la rapidité de vérification côté client léger ou embarqué.
  • Zone DNSSEC volumineuse : à tester avec votre propre chaîne d’outils, car les benchmarks montrent que le résultat peut s’inverser selon l’implémentation logicielle utilisée.

Avantages et inconvénients

Pour synthétiser l’ensemble des données précédentes, voici les forces et faiblesses de chaque algorithme, sans filtre.

Ed25519

  • Signature plus rapide dans la plupart des benchmarks récents (jusqu’à 1,7x en signature selon les mesures 2026).
  • Signature et clé publique de taille fixe, plus simples à traiter et à stocker.
  • Déterministe par conception, aucune dépendance critique à un générateur aléatoire par opération.
  • Adopté par défaut dans OpenSSH, Signal, Tor et WireGuard depuis plusieurs années.
  • Pas encore approuvé FIPS 140-3, ce qui bloque son usage dans certains marchés réglementés.
  • Support limité dans les certificats X.509 publics et certains HSM/PKI d’entreprise.

ECDSA P-256

  • Compatibilité quasi universelle : navigateurs, autorités de certification, HSM, cartes à puce.
  • Approuvée FIPS 140-3, requise dans de nombreux environnements réglementés.
  • Dominante dans les certificats TLS publics, 49,7 % des certificats analysés mi-2026.
  • Signature non déterministe par défaut, ce qui a causé des failles historiques liées à un générateur aléatoire défaillant.
  • Encodage de signature variable (DER), plus complexe à traiter que le format fixe d’Ed25519.
  • Généralement plus lente en signature que Ed25519 sur les benchmarks les plus récents, l’écart se resserrant en vérification.

Le verdict shattered.io

Il n’existe pas de vainqueur universel entre Ed25519 et ECDSA P-256, et les chiffres rassemblés dans ce comparatif expliquent pourquoi. Ed25519 l’emporte nettement sur la vitesse de signature (jusqu’à 1,7x plus rapide selon la synthèse 2026), sur la taille fixe de ses clés et signatures, et sur la robustesse structurelle face aux erreurs d’implémentation liées au générateur aléatoire. C’est le choix par défaut recommandé pour toute nouvelle clé SSH, tout protocole applicatif que vous contrôlez de bout en bout, et toute architecture qui n’a pas de contrainte X.509 ou FIPS.

ECDSA P-256 reste néanmoins incontournable partout où la compatibilité et la certification pèsent plus lourd que la performance brute : certificats TLS publics, environnements soumis à FIPS 140-3, HSM d’entreprise et cartes à puce gouvernementales. Avec 49,7 % des certificats TLS analysés en juillet 2026, elle continuera de dominer la PKI web tant qu’Ed25519 n’obtiendra pas un statut FIPS approuvé et un support universel côté navigateurs. Le bon réflexe en 2026 n’est donc pas de choisir un camp, mais de faire coexister les deux courbes selon la couche du système que vous sécurisez, en gardant un œil sur la migration hybride post-quantique qui touchera les deux d’ici la fin de la décennie.

Questions fréquentes

Ed25519 est-il plus sûr qu’ECDSA P-256 ?

Les deux offrent un niveau de sécurité classique comparable, autour de 128 bits. Ed25519 réduit le risque d’erreur d’implémentation grâce à sa signature déterministe, ce qui en fait un choix structurellement plus robuste face aux bugs de génération aléatoire, sans pour autant rendre ECDSA P-256 vulnérable si elle est correctement implémentée avec la RFC 6979.

Peut-on utiliser Ed25519 pour les certificats TLS publics ?

Techniquement oui, mais le support reste inégal selon les navigateurs, les anciens clients et les autorités de certification publiques. En 2026, ECDSA P-256 reste le choix ECC recommandé pour un certificat exposé à un public large, Ed25519 étant plus adapté à un usage interne maîtrisé de bout en bout.

OpenSSH accepte-t-il encore les clés ECDSA P-256 ?

Oui, OpenSSH continue de supporter les clés ecdsa-sha2-nistp256. Ed25519 reste toutefois le type de clé recommandé par défaut pour toute nouvelle génération depuis la version 6.5 d’OpenSSH.

Ed25519 est-il approuvé FIPS 140-3 ?

Non, à ce jour Ed25519 et EdDSA ne figurent pas parmi les algorithmes approuvés par la norme FIPS 186-5 du NIST. ECDSA P-256 reste donc le choix requis dans les environnements soumis à une certification FIPS 140-3.

Que se passe-t-il face à un ordinateur quantique ?

Ni Ed25519 ni ECDSA P-256 ne résistent à un ordinateur quantique suffisamment puissant capable d’exécuter l’algorithme de Shor. Les deux devront être combinées avec des algorithmes post-quantiques dans des schémas hybrides, comme le montre déjà l’intégration de X25519 avec ML-KEM dans OpenSSH 9.9.

Quelle courbe choisir pour WireGuard ?

La question ne se pose pas : WireGuard impose Curve25519 (X25519) pour l’échange de clés directement dans sa spécification de protocole. Il n’y a pas d’option ECDSA P-256 disponible côté configuration.

Comment migrer mes clés SSH existantes vers Ed25519 ?

Générez une nouvelle paire avec ssh-keygen -t ed25519, ajoutez la clé publique aux serveurs cibles en conservant l’ancienne clé en parallèle, testez la connexion sur un environnement non critique, puis révoquez les anciennes clés ECDSA une fois la bascule validée sur l’ensemble du parc.

Y a-t-il eu des failles critiques sur Ed25519 ou P-256 en 2025-2026 ?

Aucune faille structurelle contre le problème mathématique des deux courbes n’a été rendue publique sur cette période. Les incidents recensés concernent des bugs d’implémentation dans des bibliothèques cryptographiques (temps non constant, validation de paramètres incorrecte), qui touchent en général plusieurs algorithmes à la fois plutôt qu’une faiblesse propre à Ed25519 ou P-256.