Choisir ECDSA, EdDSA ou RSA pour un certificat TLS

Un certificat TLS (Transport Layer Security) porte une clé publique qui sert à une seule chose dans la négociation : prouver, par une signature, que le serveur détient la clé privée correspondante. Choisir entre RSA (Rivest-Shamir-Adleman), ECDSA (Elliptic Curve Digital Signature Algorithm) et EdDSA (Edwards-curve Digital Signature Algorithm) revient donc à choisir le coût de cette preuve, sa taille sur le réseau, ses modes de défaillance et la liste des clients capables de la vérifier.

→ Lire l’explication complète de la marmotte

Taille de clé et niveau de sécurité : RSA contre courbes elliptiques

En bits d’effort d’attaque, RSA-2048 offre environ 112 bits, RSA-3072 environ 128 ; ECDSA sur la courbe P-256 et Ed25519 offrent environ 128 bits, P-384 environ 192. À sécurité égale, l’écart de taille est brutal :

Algorithme	Clé publique	Signature	Sécurité estimée
RSA-2048	256 octets (module)	256 octets	112 bits
RSA-3072	384 octets	384 octets	128 bits
ECDSA P-256	65 octets (non compressée)	70 à 72 octets (encodage DER, Distinguished Encoding Rules)	128 bits
Ed25519	32 octets	64 octets	environ 128 bits

Cette taille se paie à chaque négociation : chaîne, signatures et horodatages de transparence voyagent dans le premier vol du serveur. Une chaîne RSA complète peut dépasser la fenêtre de congestion initiale de TCP (Transmission Control Protocol), environ 14 Ko, et coûter un aller-retour de plus. En QUIC, la limite anti-amplification (trois fois les octets reçus du client) produit le même effet plus tôt. ECDSA sur la feuille et l’intermédiaire allège la chaîne de plusieurs centaines d’octets.

Confusion fréquente : le type de clé du certificat et l’algorithme qui le signe sont indépendants. Une clé ECDSA signée par un intermédiaire RSA fait encore vérifier du RSA au client.

Performance de signature et de vérification

L’asymétrie de coût décide l’architecture. En RSA, signer est lent et vérifier est très rapide (exposant public 65537) ; en ECDSA, signer est rapide et vérifier est plus lent. Or dans TLS, le serveur signe une fois par négociation complète, et le client vérifie. Sur un cœur de processeur récent, un ordre de grandeur courant est de 1 000 à 2 000 signatures RSA-2048 par seconde contre plusieurs dizaines de milliers en ECDSA P-256. Un frontal qui termine beaucoup de négociations sans reprise de session divise ainsi par 10 à 30 le coût processeur de l’authentification.

Côté client, la vérification ECDSA reste de l’ordre de la dizaine de microsecondes, sauf sur microcontrôleur. Ed25519 signe et vérifie vite, en temps constant plus facile à implémenter.

Modes de défaillance : ce qui casse avec chaque algorithme

La sécurité réelle se joue dans la façon de mal finir, pas dans le nombre de bits.

ECDSA exige un nombre aléatoire unique et secret par signature. Le réutiliser une fois révèle la clé privée par simple algèbre ; un biais de quelques bits suffit, avec assez de signatures, à la retrouver par attaque de réseau euclidien, comme l’ont montré les fuites temporelles de type Minerva ou TPM-Fail. Contre-mesure : nonces déterministes selon la RFC (Request for Comments) 6979, ou bibliothèque qui les dérive déjà de la clé et du message. Le tirer avec un générateur maison relève de la roulette russe à barillet inconnu.

EdDSA rend le nonce déterministe par construction, ce qui supprime cette classe d’erreurs. Il reste sensible aux fautes matérielles provoquées pendant la signature, et surtout à la compatibilité : les règles du CA/Browser Forum n’autorisent que RSA et ECDSA (P-256, P-384, P-521) pour les certificats web publics. Aucune autorité publique reconnue par les navigateurs n’émet donc de certificat Ed25519.

RSA souffre d’un héritage : le remplissage PKCS#1 (Public-Key Cryptography Standards) v1.5 et ses failles de vérification (falsification avec exposant 3), l’échange de clés RSA en TLS 1.2 exploité par les oracles de Bleichenbacher (ROBOT, Return Of Bleichenbacher’s Oracle Threat). TLS 1.3 impose RSA-PSS (Probabilistic Signature Scheme) pour les signatures de négociation et supprime l’échange de clés RSA, mais un serveur qui garde TLS 1.2 avec des suites TLS_RSA_* réexpose le problème.

Aucune de ces familles ne résiste à un ordinateur quantique capable de faire tourner l’algorithme de Shor. Seule l’agilité (inventaire, renouvellement automatisé) prépare la migration post-quantique.

Recommandation par contexte

Web public : ECDSA P-256 comme certificat principal. Ajouter un second certificat RSA-2048 uniquement si l’inventaire des clients montre des terminaux anciens (Java ancien, équipements embarqués, terminaux industriels) ; nginx, Apache et HAProxy servent les deux et choisissent selon les algorithmes annoncés par le client.
PKI (Public Key Infrastructure) interne et mTLS (mutual TLS) : Ed25519 si toutes les piles des deux côtés le supportent (OpenSSL 1.1.1 et plus, Go, rustls) et si le module matériel qui garde la clé de l’autorité implémente le mécanisme EdDSA de PKCS#11 3.0 ; sinon P-256. Le détail de l’authentification mutuelle est dans la page mTLS.
Contraintes réglementaires imposant une suite de type CNSA (Commercial National Security Algorithm) : P-384 ou RSA-3072 minimum.

RSA-4096 pour « plus de sécurité » est une mode tenace : quatre fois le coût de signature de RSA-2048, un gain de sécurité que personne n’attaque, et une chaîne encore plus lourde. Le cadenas n’en devient pas plus vert.

Exemple : générer, mesurer et vérifier le certificat servi

Commandes pour OpenSSL 3.x ; l’hôte interrogé sert les deux types de certificats.

# Générer une clé ECDSA P-256 et une demande de certificat (CSR)
openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out serveur-ec.key
openssl req -new -key serveur-ec.key -subj "/CN=www.exemple.test" \
  -addext "subjectAltName=DNS:www.exemple.test" -out serveur-ec.csr

# Générer une clé Ed25519 pour une PKI interne
openssl genpkey -algorithm ED25519 -out interne-ed25519.key

# Mesurer signatures et vérifications par seconde sur ce processeur
openssl speed -seconds 3 rsa2048 ecdsap256 ed25519

# Vérifier quel type de clé le serveur présente selon l'algorithme proposé
HOTE=www.cloudflare.com
for alg in ecdsa_secp256r1_sha256 rsa_pss_rsae_sha256; do
  echo "== $alg"
  openssl s_client -connect "$HOTE:443" -servername "$HOTE" -tls1_3 \
    -sigalgs "$alg" </dev/null 2>/dev/null \
    | openssl x509 -noout -text | grep -E 'Public Key Algorithm|Public-Key'
done

La CSR (Certificate Signing Request) se soumet à l’autorité ; la boucle confirme qu’un serveur à double certificat répond avec la clé attendue. Pour un échec de validation côté client, la page diagnostiquer les erreurs de validation TLS reprend la méthode.

Ce que le choix d’algorithme ne garantit pas, et l’exploitation

L’algorithme de signature ne protège ni la confidentialité passée (assurée par l’échange de clés éphémère, voir TLS expliqué), ni la clé privée posée sans protection sur un disque, ni la validité de la chaîne. En exploitation : garder la clé privée dans un module matériel ou un coffre de secrets quand le volume le permet, automatiser le renouvellement (ACME, Automatic Certificate Management Environment) pour les deux types de certificats avec des échéances décalées, surveiller l’expiration de chacun séparément, et tester le basculement en retirant volontairement le certificat RSA : si rien ne casse, il n’avait plus de raison d’exister.

🐝 Ce qui arrive si on s’en passe

À rester sur des certificats RSA sans passer aux courbes elliptiques, un serveur qui conserve TLS 1.2 garde aussi, le plus souvent, les suites d’échange de clés RSA, dont le déchiffrement PKCS#1 v1.5 est exactement le mécanisme exploité dans « la question qui rend le module bavard » : un attaquant qui interroge le serveur en boucle peut déchiffrer une session enregistrée. Le coût de signature RSA abaisse aussi le seuil à partir duquel une rafale de négociations complètes sature un frontal. Enfin, sans second certificat ni automatisation par type de clé, le changement d’algorithme se découvre le jour où il devient obligatoire, sans procédure testée.

🦫 Explication de la marmotte 🍫

Quand un navigateur se connecte à un site sécurisé, le site doit prouver son identité. Il présente un certificat, un document qui contient sa clé publique et qui est signé par une autorité reconnue. Puis il signe un message de la conversation avec sa clé privée, que lui seul possède. Le navigateur vérifie cette signature avec la clé publique.

Trois familles de calcul peuvent produire cette signature. La plus ancienne, RSA, utilise de très grands nombres : ses clés et ses signatures sont longues, signer demande beaucoup de calcul au serveur, vérifier en demande peu. Les deux plus récentes reposent sur des courbes mathématiques : pour une protection égale, leurs clés et signatures sont environ quatre fois plus courtes, et le serveur signe bien plus vite.

Les signatures sur courbe de la première sorte utilisent un nombre tiré au hasard à chaque fois ; s’il se répète ou s’il est mal tiré, la clé privée peut être recalculée. La seconde sorte évite ce piège, mais les navigateurs ne l’acceptent pas encore pour les sites publics. L’ancienne famille traîne de vieilles méthodes attaquables qu’il faut désactiver.

Aucune de ces méthodes ne résistera aux futurs ordinateurs quantiques.

Pages voisines

La citent

Choisir ECDSA, EdDSA ou RSA pour un certificat TLS

Elle cite

Choisir ECDSA, EdDSA ou RSA pour un certificat TLS

Choisir ECDSA, EdDSA ou RSA pour un certificat TLS

Taille de clé et niveau de sécurité : RSA contre courbes elliptiques

Performance de signature et de vérification

Modes de défaillance : ce qui casse avec chaque algorithme

Recommandation par contexte

Exemple : générer, mesurer et vérifier le certificat servi

Ce que le choix d’algorithme ne garantit pas, et l’exploitation

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines