Ed25519- vs. RSA-Schlüssel: welcher SSH-Schlüsseltyp passt

Die Frage Ed25519 vs. RSA stellt sich meist, wenn du ssh-keygen ausführst und überlegst, was du bei -t angeben sollst. Derselbe Vergleich gilt für das Signieren von Code und Dateien. Ed25519 bietet 128-Bit-Sicherheit mit winzigen Schlüsseln und schnellen, deterministischen Signaturen; RSA bietet universelle Kompatibilität, ist dafür aber deutlich größer und hat eine langsamere, fehleranfälligere Schlüsselerzeugung.

Auf einen Blick

Gemessen mit OpenSSH 10.3p1 und OpenSSL 3.6.5 auf einem Kern eines Apple M4 Max.

Größen und Geschwindigkeit

Auf demselben 128-Bit-Niveau ist ein öffentlicher Ed25519-Schlüssel 32 Byte groß und ein RSA-3072-Modul 384. In SSH zeigt sich der Unterschied in authorized_keys, known_hosts, in Zertifikaten und bei jedem Handshake: Eine Zeile mit einem öffentlichen Ed25519-Schlüssel hat 86 Byte gegenüber 558 bei RSA-3072, und eine abgetrennte SSH-Signaturdatei hat 294 Byte gegenüber 1.211.

Die Geschwindigkeit ist asymmetrisch. RSA prüft schneller als Ed25519 (hier etwa 54.000 gegenüber 25.000 Operationen pro Sekunde), signiert aber etwa 60-mal langsamer, und die Schlüsselerzeugung muss zwei große Primzahlen suchen. Das dauerte auf diesem Rechner im Schnitt etwa 100 ms pro RSA-3072-Schlüssel und kann auf kleinen Geräten viel länger dauern. Für SSH-Server, die pro Verbindung einen Handshake signieren, kosten Ed25519-Host-Schlüssel weniger CPU-Zeit; für Benutzer geht beides ohne spürbare Verzögerung.

Das folgende Skript hat die Größenangaben in der Tabelle erzeugt; es verwendet nur 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

Robustheit und Fehlerbilder

Ed25519 hat kaum Stellschrauben: eine Kurve, eine Hashfunktion, deterministische Nonces, eine Signaturkodierung. Es gibt kein Padding zur Auswahl und keinen schwachen Parametersatz, den du versehentlich wählen könntest.

Die Geschichte von RSA ist eine Liste von Fehlern bei Parametern und Padding. Der ursprüngliche SSH-Signaturalgorithmus ssh-rsa hasht mit SHA-1, das durch Chosen-Prefix-Kollisionen gebrochen ist; OpenSSH 8.8 (September 2021) hat ihn standardmäßig deaktiviert, und RSA-Schlüssel signieren heute mit rsa-sha2-256 oder rsa-sha2-512 (RFC 8332), was mit jedem aktuellen Client und Server automatisch geschieht. Kurze Schlüssel sind eine weitere Falle: NIST lässt 1024-Bit-RSA für Signaturen seit 2013 nicht mehr zu, und 2048 Bit entsprechen dem 112-Bit-Niveau von NIST, das der Entwurf NIST IR 8547 nach 2030 als veraltet einstufen will. Schwache Schlüsselgeneratoren haben gemeinsame oder strukturierte Primzahlen erzeugt (die ROCA-Schwachstelle und Schlüssel, die sich per Batch-GCD faktorisieren lassen) – eine Fehlerklasse, die es bei Ed25519-Seeds nicht gibt, solange der Zufallszahlengenerator funktioniert.

Kompatibilität

Ed25519 funktioniert mit OpenSSH ab 6.5, PuTTY, dem in Windows integrierten OpenSSH, GitHub, GitLab, Bitbucket, den meisten Cloud-Konsolen, Linux-Instanzen in EC2 und dem Signieren von Git-Commits per SSH. Die nennenswerten Lücken sind Windows-Instanzen in Amazon EC2, deren Schlüsselpaare RSA sein müssen, weil der Schlüssel das anfängliche Administratorpasswort entschlüsselt, außerdem manche Netzwerk-Appliances und eingebettete SSH-Implementierungen sowie sehr alte Unternehmenssoftware. FIDO-gestützte Schlüssel vom Typ ed25519-sk brauchen einen Authenticator, der EdDSA unterstützt; ecdsa-sk ist die breiter unterstützte Hardware-Option.

RSA funktioniert überall, wo SSH funktioniert – das ist sein einziger echter Vorteil. Bei TLS-Zertifikaten ist die Lage umgekehrt: Öffentlich vertrauenswürdige CAs stellen RSA- und ECDSA-Zertifikate aus, aber keine Ed25519-Zertifikate; in diesem Vergleich geht es daher um SSH und Signaturen, nicht um HTTPS.

Wann welcher Schlüsseltyp passt

• Persönliche SSH-Schlüssel und Deploy-Schlüssel für CI: Ed25519, geschützt mit einer Passphrase oder auf einem Sicherheitsschlüssel gespeichert (ssh-keygen -t ed25519-sk).
• SSH-Host-Schlüssel: Biete Ed25519 zuerst an; behalte einen RSA-Host-Schlüssel (nur mit rsa-sha2-*), solange sich alte Clients verbinden, und plane seine Entfernung.
• Signieren von Commits und Dateien mit SSH-Schlüsseln: Ed25519; die Signaturen sind ein Fünftel so groß, und die Prüfung läuft mit demselben Befehl.
• Windows-Instanzen in EC2, alte Appliances, Systeme, die sich nicht aktualisieren lassen: RSA-3072 oder RSA-4096.
• Hardware-Tokens im PIV-Modus: das, was das Token unterstützt, und das ist oft eher RSA oder ECDSA P-256 als Ed25519.
• Langfristige Planung: Keines der beiden übersteht einen Quantencomputer; OpenSSH schützt Sitzungsschlüssel bereits mit einem hybriden Post-Quanten-Schlüsselaustausch, und OpenSSH 10.4 hat einen experimentellen Composite-Schlüsseltyp aus ML-DSA-44 plus Ed25519 für Signaturen eingeführt.

Hinweise zur Migration

RSA-Schlüssel durch Ed25519 zu ersetzen ist eine routinemäßige Schlüsselrotation.

1. Erzeuge den neuen Schlüssel mit ssh-keygen -t ed25519 -a 100 (mehr KDF-Runden für die Passphrase) oder auf einem Sicherheitsschlüssel.
2. Installiere ihn neben dem alten Schlüssel: Hänge ihn auf jedem Server an authorized_keys an, füge ihn deinem Konto beim Git-Hoster und dem Konfigurationsmanagement hinzu und vergewissere dich, dass du dich mit ssh -i ~/.ssh/id_ed25519 anmelden kannst.
3. Bei Host-Schlüsseln trage HostKey /etc/ssh/ssh_host_ed25519_key in sshd_config ein; Clients mit UpdateHostKeys (in aktuellem OpenSSH standardmäßig aktiv) übernehmen den neuen Schlüssel automatisch, und Einträge in known_hosts lassen sich aktualisieren, bevor der RSA-Schlüssel entfernt wird.
4. Entferne den RSA-Schlüssel aus authorized_keys, Konten und Agenten, sobald nichts mehr davon abhängt, und suche in den Logs nach Clients, die noch RSA aushandeln.
5. Wenn du RSA behalten musst, stelle sicher, dass ssh-rsa (SHA-1) nirgends wieder aktiviert wird: Suche nach +ssh-rsa in HostKeyAlgorithms oder PubkeyAcceptedAlgorithms. ssh -Q HostKeyAlgorithms listet auf, was ein Client unterstützt, nmap --script ssh2-enum-algos, was ein Server anbietet, und der SSH-Schlüsselinspektor zeigt Typ, Größe und Fingerabdruck eines Schlüssels.

Quellen

• RFC 8709, Ed25519 und Ed448 als Public-Key-Algorithmen für SSH
• RFC 8332, Verwendung von RSA-Schlüsseln mit SHA-256 und SHA-512 in SSH
• RFC 8032, EdDSA
• Versionshinweise zu OpenSSH 8.8 (ssh-rsa deaktiviert)
• Versionshinweise zu OpenSSH 9.5 (Ed25519 als Standard)
• NIST SP 800-57 Part 1 Rev. 5, Tabelle 2
• NIST IR 8547, erster öffentlicher Entwurf
• Amazon EC2: Schlüsselpaar erstellen