ECDSA vs. RSA: welcher Signaturalgorithmus wann passt

Zwei Algorithmen, eine Aufgabe

Bei RSA beruhen Signaturen auf modularer Exponentiation mit einem großen zusammengesetzten Modul: Der private Schlüssel wird aus zwei geheimen Primzahlen abgeleitet, und die Schwierigkeit, deren Produkt zu faktorisieren, hält den Schlüssel geheim. ECDSA (Elliptic Curve Digital Signature Algorithm, standardisiert in FIPS 186-5) arbeitet dagegen in der Gruppe der Punkte einer elliptischen Kurve; das schwere Problem ist dort der diskrete Logarithmus auf elliptischen Kurven.

Die praktische Folge der unterschiedlichen schweren Probleme: Angriffe auf die Faktorisierung skalieren besser als Angriffe auf diskrete Logarithmen über elliptischen Kurven, deshalb müssen RSA-Schlüssel viel schneller wachsen als EC-Schlüssel, um dieselbe Sicherheitsmarge zu halten. Diese eine Tatsache erklärt die meisten Größen- und Leistungsunterschiede, die unten folgen.

Größe: Schlüssel und Signaturen bei gleicher Stärke

Der NIST-Vergleich der Sicherheitsniveaus (siehe SP 800-57 Part 1) ordnet einen 256-Bit-Schlüssel auf einer elliptischen Kurve in dieselbe 128-Bit-Sicherheitsklasse ein wie einen 3072-Bit-RSA-Modul:

(*Kodierung des Punkts: unkomprimierte / komprimierte Darstellung.) Auf dem 128-Bit-Niveau – heute die Untergrenze für neue Systeme – ist eine ECDSA-P-256-Signatur 64 Byte groß, eine RSA-3072-Signatur dagegen 384 Byte, und der öffentliche Schlüssel ist ungefähr ein Zehntel so groß. Selbst das weit verbreitete RSA-2048, dessen Sicherheitsmarge geringer ist, erzeugt 256-Byte-Signaturen. Wo jedes Byte zählt – Zertifikate im TLS-Handshake, Tokens in einem HTTP-Header, Transaktionen auf einer Blockchain –, gewinnen elliptische Kurven bei der Größe, und zwar jedes Mal.

Beachte die beiden Zahlen für ECDSA-Signaturen: 64 Byte „roh“ gegenüber ~70–72 Byte in DER-Kodierung. Dieselbe mathematische Signatur hat zwei gängige Kodierungen für die Übertragung, und eine Verwechslung der beiden ist eine der häufigsten Ursachen für Fehler mit der Meldung „invalid signature“. Diesem Thema ist ein eigener Artikel gewidmet.

Geschwindigkeit: die Asymmetrie zwischen Signieren und Prüfen

Die beiden Algorithmen haben gegensätzliche Leistungsprofile, und diese Asymmetrie solltest du verinnerlichen, denn sie entscheidet über reale Architekturen:

• Die Prüfung von RSA-Signaturen ist sehr schnell. Prüfen bedeutet eine einzige modulare Exponentiation mit dem öffentlichen Exponenten, der fast immer den kleinen Wert 65537 hat. Deshalb hat sich RSA so lange in Zertifikatsketten gehalten: Ein Zertifikat wird einmal signiert und milliardenfach geprüft.
• Das Signieren mit RSA ist langsam, weil dabei mit dem privaten Exponenten in voller Größe über einem Modul von 2048 bis 4096 Bit potenziert wird. Die Erzeugung von RSA-Schlüsseln ist noch langsamer – dabei muss nach großen zufälligen Primzahlen gesucht werden, was spürbare Bruchteile einer Sekunde dauern kann und unvorhersehbar schwankt.
• Das Signieren mit ECDSA ist schnell – eine einzige Skalarmultiplikation über einem 256-Bit-Körper, typischerweise um ein Mehrfaches bis um eine Größenordnung schneller als eine RSA-2048-Signatur und mit einem noch viel größeren Abstand zu RSA-3072. Die Erzeugung von EC-Schlüsseln kostet praktisch nichts (eine Skalarmultiplikation), was für ephemere und gerätespezifische Schlüssel wichtig ist.
• Die Prüfung von ECDSA-Signaturen ist langsamer als die von RSA-Signaturen (grob zwei Skalarmultiplikationen), auf moderner Hardware absolut gesehen aber immer noch schnell.

Den Größenunterschied siehst du direkt mit ein paar Zeilen Node.js:

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

Wo die beiden heute eingesetzt werden

• TLS / X.509. Beide sind überall zu finden. RSA dominiert nach wie vor den Bestand an Zertifikaten, aber ECDSA-Zertifikate (P-256, P-384) gehören bei den großen CAs zum Standardangebot und verkleinern Handshakes spürbar; viele große Websites liefern ECDSA mit RSA als Fallback aus. TLS 1.3 unterstützt beide Signaturfamilien nativ.
• SSH. Das Ökosystem ist zu elliptischen Kurven übergegangen: Ed25519 (ein verwandtes EC-Signaturverfahren, nicht ECDSA) ist die übliche Voreinstellung für neue Schlüssel, ECDSA P-256 ist ebenfalls verbreitet. RSA-Schlüssel funktionieren weiterhin, aber das alte Signaturverfahren ssh-rsa (auf Basis von SHA-1) ist in aktuellen OpenSSH-Releases standardmäßig deaktiviert – RSA-Schlüssel müssen die SHA-2-Varianten verwenden.
• JWTs. RS256 (RSA) ist der historische Standard des Identitäts-Ökosystems; ES256 (ECDSA P-256) ist die kompakte, moderne Wahl und wird von mehreren Plattformen vorgeschrieben (Apples Token-APIs, DPoP, die meisten WebAuthn-/Passkey-Credentials). Die Abwägungen sind so speziell, dass wir ihnen eine eigene Anleitung gewidmet haben: ES256 vs. RS256 für JWTs. Echte Tokens kannst du mit dem JWT-Debugger untersuchen.
• Blockchains. Praktisch reines ECDSA-Terrain: Bitcoin und Ethereum signieren beide mit ECDSA über der Kurve secp256k1 (Bitcoin hat mit Taproot zusätzlich Schnorr-Signaturen eingeführt). Wegen seiner Signaturgrößen kommt RSA dort, wo jedes Byte einer Transaktion bezahlt wird, gar nicht erst infrage.
• Codesignatur und Firmware. Historisch stark von RSA geprägt, zunehmend gemischt; ressourcenarme Geräte bevorzugen ECDSA wegen der kleinen Schlüssel und des schnellen, speichersparenden Signierens.

Der Haken bei ECDSA: Die Nonce muss perfekt sein

ECDSA hat eine Betriebsanforderung, die RSA schlicht nicht kennt: Jede Signatur verbraucht eine frische geheime Zahl k (die Nonce), und die Sicherheit des Verfahrens hängt davon ab, dass diese Zahl für jede einzelne Signatur eindeutig und gleichverteilt zufällig ist. Fehler verzeiht das Verfahren nicht:

• Wird dasselbe k jemals für zwei verschiedene Nachrichten mit demselben Schlüssel verwendet, lässt sich der private Schlüssel mit elementarer Algebra aus den beiden Signaturen berechnen. Genau das geschah 2010 beim berühmten Vorfall um die PlayStation 3, bei dem eine konstante Nonce den Signaturschlüssel der Konsole offenlegte.
• Schon eine teilweise vorhersagbare oder leicht verzerrte Nonce kann, über viele Signaturen hinweg beobachtet, ausreichen, um den Schlüssel mit Gitterverfahren zu rekonstruieren. Ein schwacher Zufallszahlengenerator des Systems zum Zeitpunkt des Signierens ist deshalb ein Risiko der Schlüsselkompromittierung und nicht bloß ein Qualitätsproblem.

Die Standardlösung ist deterministisches ECDSA, spezifiziert in RFC 6979: k wird über HMAC aus dem privaten Schlüssel und dem Digest der Nachricht abgeleitet, sodass dieselbe Eingabe immer dieselbe, gut verteilte Nonce ergibt und beim Signieren kein Zufall nötig ist. FIPS 186-5 erlaubt deterministisches ECDSA inzwischen, und die meisten modernen Bibliotheken implementieren RFC 6979 oder eine abgesicherte Variante (deterministische Ableitung, gemischt mit zusätzlicher Entropie). Bei der Wahl einer Bibliothek gehört das zu den ersten Dingen, die du prüfen solltest. RSA dagegen braucht bei PKCS#1 v1.5 keinen Zufall pro Signatur, und das zufällige Salt in RSA-PSS führt nicht zur Kompromittierung des Schlüssels, wenn es sich wiederholt.

Die Post-Quanten-Uhr läuft für beide

Wofür du dich auch entscheidest – plane die Ablösung gleich mit ein. Ein ausreichend großer Quantencomputer, auf dem der Shor-Algorithmus läuft, bricht Faktorisierung und diskrete Logarithmen auf elliptischen Kurven gleichermaßen – RSA und ECDSA fallen gemeinsam. NIST hat den Zeitplan für den Übergang in NIST IR 8547 skizziert (bisher nur als erster öffentlicher Entwurf): Klassische Signaturalgorithmen – ECDSA, EdDSA und RSA – sind für den Einsatz in US-Bundesbehörden nach 2035 nicht mehr zulässig, und zwar bei jedem Parametersatz. Ein früherer Meilenstein gilt nur für das 112-Bit-Sicherheitsniveau, bei Signaturen also für RSA-2048 und P-224: Diese sind nach 2030 als veraltet eingestuft (deprecated), also weiterhin nutzbar, aber mit anerkanntem Risiko. Das Datum 2030 betrifft P-256, P-384 und RSA-3072 nicht – eine Unterscheidung, die du richtig treffen solltest, denn sie entscheidet, welche deiner Schlüssel zuerst Aufmerksamkeit brauchen.

Die benannten Nachfolger sind ML-DSA (gitterbasiert, standardisiert in FIPS 204) und SLH-DSA (hashbasiert, FIPS 205); das von Falcon abgeleitete FN-DSA soll folgen. Stell dich auf einen Größenschock ein: Eine ML-DSA-65-Signatur ist rund 3,3 KB groß – das Fünfzigfache einer P-256-Signatur –, weshalb die Protokollarbeit an hybriden und Composite-Zertifikaten noch andauert. Die praktische Konsequenz für heute lautet nicht „PQC jetzt überall einführen“, sondern Kryptoagilität aufbauen: Kenne jede Stelle, an der deine Systeme signieren, halte die Wahl der Algorithmen konfigurierbar und vermeide fest einprogrammierte Schlüssel- oder Signaturgrößen.

Welchen solltest du also heute verwenden?

Willst du die Unterschiede an echten Bytes sehen? Erzeuge im ECDSA-Signatur-Verifizierer eine Signatur oder füge eine ein – er erkennt Kurve und Kodierung automatisch und zeigt genau an, was er geprüft hat.