ECDSA vs RSA : quel algorithme de signature, et quand

Deux algorithmes, une même fonction

Les signatures RSA reposent sur l’exponentiation modulaire avec un grand module composé : la clé privée est dérivée de deux nombres premiers secrets, et c’est la difficulté de factoriser leur produit qui garantit le secret de la clé privée. ECDSA (Elliptic Curve Digital Signature Algorithm, normalisé dans FIPS 186-5) opère quant à lui dans le groupe des points d’une courbe elliptique, où le problème difficile est le logarithme discret sur courbe elliptique.

Conséquence pratique de ces problèmes difficiles distincts : les attaques contre la factorisation passent mieux à l’échelle que les attaques contre le logarithme discret sur courbe elliptique, si bien que les clés RSA doivent grandir beaucoup plus vite que les clés EC pour conserver la même marge de sécurité. Ce seul fait explique l’essentiel des écarts de taille et de performance décrits ci-dessous.

Taille : clés et signatures à sécurité égale

La comparaison des niveaux de sécurité établie par le NIST (voir SP 800-57 Part 1) place une clé de courbe elliptique de 256 bits dans la même classe de sécurité de 128 bits qu’un module RSA de 3072 bits :

(*encodage en point non compressé / en point compressé.) Au niveau de 128 bits, aujourd’hui le plancher pour les nouveaux systèmes, une signature ECDSA P-256 fait 64 octets contre 384 octets pour RSA-3072, et la clé publique est environ dix fois plus petite. Même RSA-2048, très répandu (et doté d’une marge plus faible), produit des signatures de 256 octets. Là où chaque octet compte (certificats dans un handshake TLS, jetons dans un en-tête HTTP, transactions sur une blockchain), les courbes elliptiques l’emportent sur la taille, à chaque fois.

Notez les deux valeurs indiquées pour la signature ECDSA : 64 octets « bruts » contre ~70–72 octets en encodage DER. Une même signature mathématique a deux encodages courants pour la transmission, et les confondre est l’une des causes les plus fréquentes des erreurs « invalid signature ». Ce sujet a droit à son propre article.

Vitesse : l’asymétrie entre signature et vérification

Les deux algorithmes ont des profils de performance opposés, et cette asymétrie mérite d’être bien assimilée, car elle détermine de vraies architectures :

• La vérification RSA est très rapide. Vérifier revient à effectuer une seule exponentiation modulaire avec l’exposant public, qui vaut presque toujours la petite valeur 65 537. C’est pourquoi RSA s’est maintenu si longtemps dans les chaînes de certificats : un certificat est signé une fois et vérifié des milliards de fois.
• La signature RSA est lente, car elle effectue une exponentiation avec l’exposant privé de pleine taille sur un module de 2048 à 4096 bits. La génération de clés RSA est plus lente encore : elle doit chercher de grands nombres premiers aléatoires, ce qui peut prendre une fraction de seconde perceptible et varie de façon imprévisible.
• La signature ECDSA est rapide : une seule multiplication scalaire sur un corps de 256 bits, généralement plusieurs fois, voire un ordre de grandeur, plus rapide qu’une signature RSA-2048, avec un écart bien plus grand face à RSA-3072. La génération de clés EC est pratiquement gratuite (une multiplication scalaire), ce qui compte pour les clés éphémères et les clés propres à chaque appareil.
• La vérification ECDSA est plus lente que la vérification RSA (environ deux multiplications scalaires), tout en restant rapide dans l’absolu sur du matériel moderne.

Quelques lignes de Node.js suffisent pour constater directement l’écart de taille :

import { generateKeyPairSync, sign } from "node:crypto";

const message = Buffer.from("measure me");

const ec = generateKeyPairSync("ec", { namedCurve: "P-256" });
const rsa = generateKeyPairSync("rsa", { modulusLength: 3072 }); // slow: prime search

const ecSig = sign("sha256", message, ec.privateKey);  // DER-encoded by default
const rsaSig = sign("sha256", message, rsa.privateKey);

console.log("ECDSA P-256:", ecSig.length, "bytes"); // ~70-72 (64 raw)
console.log("RSA-3072:  ", rsaSig.length, "bytes"); // 384

Où l’on trouve chacun aujourd’hui

• TLS / X.509. Les deux sont partout. RSA domine encore le parc installé de certificats, mais les certificats ECDSA (P-256, P-384) sont délivrés en standard par les grandes AC et réduisent sensiblement la taille des handshakes ; de nombreux grands sites servent ECDSA avec un repli sur RSA. TLS 1.3 prend en charge nativement les deux familles de signatures.
• SSH. L’écosystème est passé aux courbes elliptiques : Ed25519 (un schéma de signature EC apparenté, pas ECDSA) est le choix par défaut habituel pour les nouvelles clés, et ECDSA P-256 est également courant. Les clés RSA fonctionnent toujours, mais l’ancien schéma de signature ssh-rsa (fondé sur SHA-1) est désactivé par défaut dans les versions récentes d’OpenSSH : les clés RSA doivent utiliser les variantes SHA-2.
• JWT. RS256 (RSA) est le choix par défaut historique de l’écosystème de l’identité ; ES256 (ECDSA P-256) est le choix moderne et compact, imposé par plusieurs plateformes (les API de jetons d’Apple, DPoP, la plupart des identifiants WebAuthn et des clés d’accès). Les compromis sont assez spécifiques pour que nous leur ayons consacré un guide : ES256 vs RS256 pour les JWT. Vous pouvez inspecter de vrais jetons avec le débogueur JWT.
• Blockchains. Un territoire pratiquement réservé à ECDSA : Bitcoin et Ethereum signent tous deux avec ECDSA sur la courbe secp256k1 (Bitcoin a en outre adopté les signatures Schnorr avec Taproot). Avec ses tailles de signature, RSA est exclu d’emblée là où chaque octet de transaction est payant.
• Signature de code et micrologiciels. Historiquement dominés par RSA, de plus en plus mixtes ; les appareils contraints privilégient ECDSA pour ses petites clés et sa signature rapide et économe en mémoire.

Le revers d’ECDSA : le nonce doit être parfait

ECDSA a une exigence opérationnelle que RSA n’a tout simplement pas : chaque signature consomme un nombre secret neuf k (le nonce), et la sécurité du schéma repose sur le fait que ce nombre soit unique et uniformément aléatoire pour chaque signature, sans exception. Les modes de défaillance ne pardonnent pas :

• Si le même k sert ne serait-ce qu’une fois pour deux messages différents avec la même clé, la clé privée peut être calculée à partir des deux signatures par de l’algèbre élémentaire. C’est exactement ce qui s’est produit lors du célèbre incident de la PlayStation 3 en 2010, où un nonce constant a exposé la clé de signature de la console.
• Même un nonce partiellement prévisible ou légèrement biaisé, observé sur de nombreuses signatures, peut suffire à reconstituer la clé à l’aide de techniques fondées sur les réseaux euclidiens. Un générateur de nombres aléatoires système faible au moment de la signature est donc un risque de compromission de clé, pas un simple problème de qualité.

La réponse standard est ECDSA déterministe, spécifié dans la RFC 6979 : dériver k de la clé privée et du condensat du message via HMAC, de sorte que la même entrée produise toujours le même nonce, bien distribué, sans qu’aucun aléa soit nécessaire au moment de la signature. FIPS 186-5 autorise désormais ECDSA déterministe, et la plupart des bibliothèques modernes implémentent la RFC 6979 ou une variante « hedged » (dérivation déterministe mêlée à de l’entropie supplémentaire). Lors du choix d’une bibliothèque, c’est l’un des premiers points à vérifier. RSA, en revanche, n’a besoin d’aucun aléa par signature avec PKCS#1 v1.5, et le sel aléatoire de RSA-PSS n’entraîne pas de compromission de clé s’il se répète.

Le compte à rebours post-quantique a commencé pour les deux

Quel que soit votre choix, préparez son retrait. Un ordinateur quantique suffisamment grand exécutant l’algorithme de Shor casse aussi bien la factorisation que le logarithme discret sur courbe elliptique : RSA et ECDSA tombent ensemble. Le NIST a esquissé le calendrier de transition dans NIST IR 8547 (encore au stade de projet public initial) : les algorithmes de signature classiques (ECDSA, EdDSA et RSA) sont interdits après 2035 pour l’usage fédéral, quel que soit le jeu de paramètres. Une échéance antérieure ne concerne que le niveau de sécurité de 112 bits, c’est-à-dire, pour les signatures, RSA-2048 et P-224 : ceux-ci sont déconseillés après 2030, autrement dit encore utilisables, mais avec un risque reconnu. P-256, P-384 et RSA-3072 ne sont pas concernés par l’échéance de 2030 ; c’est une distinction à bien saisir, car elle détermine lesquelles de vos clés demandent de l’attention en premier.

Les successeurs désignés sont ML-DSA (fondé sur les réseaux euclidiens, normalisé dans FIPS 204) et SLH-DSA (fondé sur le hachage, FIPS 205), que suivra FN-DSA, dérivé de Falcon. Préparez-vous à un choc de taille : une signature ML-DSA-65 pèse environ 3,3 Ko, cinquante fois une signature P-256, ce qui explique que les travaux protocolaires sur les certificats hybrides et composites soient toujours en cours. La leçon pratique pour aujourd’hui n’est pas « adoptez la PQC partout dès maintenant », mais construisez l’agilité cryptographique : recensez chaque endroit où vos systèmes signent, gardez les choix d’algorithmes configurables et évitez de coder en dur les tailles de clé ou de signature.

Alors, lequel utiliser aujourd’hui ?

Envie de voir les différences sur de vrais octets ? Générez ou collez une signature dans le vérificateur de signatures ECDSA : il détecte automatiquement la courbe et l’encodage, et montre exactement ce qu’il a vérifié.