La question Ed25519 vs RSA se pose le plus souvent au moment de lancer ssh-keygen, quand il faut choisir la valeur à passer à -t. La même comparaison vaut pour la signature de code et de fichiers. Ed25519 offre 128 bits de sécurité avec des clés minuscules et des signatures rapides et déterministes ; RSA offre une compatibilité universelle, au prix d’une taille bien plus grande et d’une génération de clés plus lente et plus fragile.
Vue d’ensemble
| Ed25519 | RSA-3072 | |
|---|---|---|
| Sécurité | environ 128 bits | environ 128 bits (RSA-2048 : 112) |
| Clé privée | graine de 32 octets | module de 3072 bits, plus les valeurs CRT |
| Clé publique, brute | 32 octets | module de 384 octets, plus l’exposant |
Ligne .pub d’OpenSSH (mesurée) | 86 octets | 558 octets |
| Signature | 64 octets | 384 octets |
| Fichier SSHSIG pour une signature (mesuré) | 294 octets | 1211 octets |
| Génération de clés | quelques microsecondes | environ 100 ms en moyenne, très variable |
| Signatures / vérifications par seconde, OpenSSL 3.6.5 | environ 60 000 / 25 000 | environ 1000 / 54 000 |
| Noms d’algorithme SSH | ssh-ed25519, sk-ssh-ed25519@openssh.com | type de clé ssh-rsa ; signatures rsa-sha2-256, rsa-sha2-512 |
| Prise en charge par OpenSSH | depuis la 6.5 (2014) ; par défaut depuis la 9.5 (2023) | depuis toujours |
| Signatures déterministes | Oui | Oui pour PKCS #1 v1.5, aléatoires pour PSS |
| NIST IR 8547 (projet) | interdit après 2035 | RSA-2048 déprécié après 2030 ; tout RSA interdit après 2035 |
Mesures effectuées avec OpenSSH 10.3p1 et OpenSSL 3.6.5 sur un cœur d’un Apple M4 Max.
Tailles et vitesse
À niveau égal de 128 bits, une clé publique Ed25519 fait 32 octets et un module RSA-3072 en fait 384. Côté SSH, la différence se voit dans authorized_keys, known_hosts, les certificats et chaque handshake : une ligne de clé publique Ed25519 fait 86 octets contre 558 pour RSA-3072, et un fichier de signature SSH détachée 294 octets contre 1211.
La vitesse est asymétrique. RSA vérifie plus vite qu’Ed25519 (environ 54 000 contre 25 000 opérations par seconde ici), mais signe environ 60 fois plus lentement, et la génération de clés doit chercher deux grands nombres premiers, ce qui a pris en moyenne environ 100 ms par clé RSA-3072 sur cette machine et peut prendre bien plus longtemps sur de petits appareils. Pour les serveurs SSH, qui signent un handshake à chaque connexion, les clés d’hôte Ed25519 coûtent moins de CPU ; pour les utilisateurs, les deux sont instantanés.
Le script ci-dessous a produit les tailles du tableau ; il n’utilise qu’OpenSSH.
#!/bin/sh
dir=$(mktemp -d)
cd "$dir" || exit 1
ssh-keygen -q -t ed25519 -N "" -C demo -f id_ed25519
ssh-keygen -q -t rsa -b 3072 -N "" -C demo -f id_rsa
for k in id_ed25519 id_rsa; do
echo "$k.pub: $(wc -c < $k.pub | tr -d ' ') bytes"
printf 'hello\n' > "msg-$k"
ssh-keygen -q -Y sign -f "$k" -n file "msg-$k"
echo "signature file: $(wc -c < "msg-$k.sig" | tr -d ' ') bytes"
done
cd / && rm -rf "$dir"
id_ed25519.pub: 86 bytes
signature file: 294 bytes
id_rsa.pub: 558 bytes
signature file: 1211 bytes
Robustesse et modes de défaillance
Ed25519 a peu de réglages : une seule courbe, une seule fonction de hachage, des nonces déterministes, un seul encodage de signature. Il n’y a aucun remplissage à choisir ni aucun jeu de paramètres faible à sélectionner par accident.
L’histoire de RSA est une suite d’erreurs de paramètres et de remplissage. L’algorithme de signature d’origine de SSH, ssh-rsa, hache avec SHA-1, que les collisions à préfixe choisi ont cassé ; OpenSSH 8.8 (septembre 2021) l’a désactivé par défaut, et les clés RSA signent désormais avec rsa-sha2-256 ou rsa-sha2-512 (RFC 8332), ce qui se fait automatiquement avec tout client et tout serveur actuels. Les clés courtes sont un autre piège : le NIST n’autorise plus RSA à 1024 bits pour les signatures depuis 2013, et 2048 bits correspond au niveau de 112 bits du NIST, que le projet NIST IR 8547 propose de déprécier après 2030. Des générateurs de clés défaillants ont produit des nombres premiers partagés ou structurés (la faille ROCA et des clés factorisables par PGCD par lots, ou batch GCD), une catégorie de défaillance qui n’existe pas pour les graines Ed25519 tant que le générateur de nombres aléatoires fonctionne.
Compatibilité
Ed25519 fonctionne avec OpenSSH 6.5 et les versions ultérieures, PuTTY, l’OpenSSH intégré à Windows, GitHub, GitLab, Bitbucket, la plupart des consoles cloud, les instances EC2 Linux et la signature des commits Git par SSH. Les principales lacunes sont les instances Amazon EC2 Windows, dont les paires de clés doivent être RSA parce que la clé déchiffre le mot de passe administrateur initial, certains équipements réseau et implémentations SSH embarquées, ainsi que les logiciels d’entreprise très anciens. Les clés ed25519-sk adossées à FIDO exigent un authentificateur qui prend en charge EdDSA ; ecdsa-sk est l’option matérielle la plus largement prise en charge.
RSA fonctionne partout où SSH fonctionne, et c’est son seul véritable avantage. Pour les certificats TLS, la situation est inversée : les autorités de certification de confiance publique délivrent des certificats RSA et ECDSA, mais pas Ed25519 ; cette comparaison porte donc sur SSH et la signature plutôt que sur HTTPS.
Quand choisir l’un ou l’autre
- Clés SSH personnelles et clés de déploiement CI : Ed25519, protégées par une phrase de passe ou conservées sur une clé de sécurité (
ssh-keygen -t ed25519-sk). - Clés d’hôte SSH : proposez Ed25519 en premier ; conservez une clé d’hôte RSA (avec
rsa-sha2-*uniquement) tant que d’anciens clients se connectent, et planifiez son retrait. - Signature de commits et de fichiers avec des clés SSH : Ed25519 ; les signatures font un cinquième de la taille et la vérification se fait avec la même commande.
- Instances EC2 Windows, équipements anciens, systèmes impossibles à mettre à jour : RSA-3072 ou RSA-4096.
- Jetons matériels en mode PIV : ce que le jeton prend en charge, souvent RSA ou ECDSA P-256 plutôt qu’Ed25519.
- Planification à long terme : aucun des deux ne résiste à un ordinateur quantique ; OpenSSH protège déjà les clés de session par un échange de clés hybride post-quantique, et OpenSSH 10.4 a ajouté un type de clé composite expérimental ML-DSA-44 plus Ed25519 pour les signatures.
Notes de migration
Remplacer des clés RSA par des clés Ed25519 est une opération courante de rotation des clés.
- Générez la nouvelle clé avec
ssh-keygen -t ed25519 -a 100(davantage de tours de KDF pour la phrase de passe) ou sur une clé de sécurité. - Installez-la à côté de l’ancienne clé : ajoutez-la à la fin de
authorized_keyssur chaque serveur, ajoutez-la à votre compte d’hébergement Git et à votre gestion de configuration, puis vérifiez que vous pouvez vous connecter avecssh -i ~/.ssh/id_ed25519. - Pour les clés d’hôte, ajoutez
HostKey /etc/ssh/ssh_host_ed25519_keyàsshd_config; les clients dotés deUpdateHostKeys(activé par défaut dans les versions actuelles d’OpenSSH) apprennent automatiquement la nouvelle clé, et les entrées deknown_hostspeuvent être mises à jour avant le retrait de la clé RSA. - Retirez la clé RSA de
authorized_keys, des comptes et des agents une fois que plus rien n’en dépend, et cherchez dans les journaux les clients qui négocient encore RSA. - Si vous devez conserver RSA, assurez-vous que
ssh-rsa(SHA-1) n’est réactivé nulle part : cherchez+ssh-rsadansHostKeyAlgorithmsouPubkeyAcceptedAlgorithms.ssh -Q HostKeyAlgorithmsliste ce que prend en charge un client,nmap --script ssh2-enum-algosce que propose un serveur, et l’inspecteur de clés SSH affiche le type, la taille et l’empreinte d’une clé.
Références
- RFC 8709, algorithmes de clé publique Ed25519 et Ed448 pour SSH
- RFC 8332, utilisation des clés RSA avec SHA-256 et SHA-512 dans SSH
- RFC 8032, EdDSA
- Notes de version d’OpenSSH 8.8 (ssh-rsa désactivé)
- Notes de version d’OpenSSH 9.5 (Ed25519 par défaut)
- NIST SP 800-57 Part 1 Rev. 5, tableau 2
- NIST IR 8547, projet initial soumis à consultation publique
- Amazon EC2 : créer une paire de clés