ECDSA vs. EdDSA: P-256 oder Ed25519 für Signaturen

Mit ECDSA vs. EdDSA ist meist ECDSA auf P-256 gegenüber EdDSA auf Ed25519 gemeint: die beiden Signaturverfahren, die fast jeden modernen Einsatz elliptischer Kurven abdecken. Beide sind gleich stark und gleich kompakt; die Wahl hängt deshalb einerseits davon ab, wie sicher sich das Verfahren implementieren lässt, und andererseits davon, wie gut das Ökosystem es unterstützt.

Auf einen Blick

Die Geschwindigkeiten wurden auf einem Kern eines Apple M4 Max gemessen: mit OpenSSL 3.6.5 (openssl speed) und, für die Zeile mit reinem JavaScript, mit @noble/curves 2.3.0 unter Node.js 26.10.

Wie sich die Konstruktionen unterscheiden

Beide sind Signaturverfahren, die auf dem diskreten Logarithmus über elliptischen Kurven beruhen. Zwischen ihrer Entstehung liegen jedoch rund zwanzig Jahre (ECDSA 1992, EdDSA 2011), und das ist ihnen anzumerken.

Die Nonce

Eine ECDSA-Signatur verbraucht eine geheime Nonce k, die nur für diese eine Signatur gilt. Wiederholt sich k bei zwei Nachrichten oder ist es über viele Signaturen hinweg auch nur um ein paar Bits verzerrt, lässt sich der private Schlüssel berechnen; so gelangte der Signaturschlüssel der PlayStation 3 an die Öffentlichkeit, und so wurden viele Kryptowährungs-Wallets leergeräumt. FIPS 186-5 erlaubt entweder ein zufälliges k aus einem zugelassenen Generator oder die deterministische Ableitung nach RFC 6979, und die meisten modernen Bibliotheken verwenden standardmäßig eine dieser beiden Varianten – das Fehlerbild ist aber im Verfahren selbst angelegt.

EdDSA beseitigt dieses Fehlerbild: Die Nonce ist ein Hash aus einer geheimen Schlüsselhälfte und der Nachricht (RFC 8032 §5.1.6). Zweimaliges Signieren derselben Nachricht ergibt dieselbe Signatur, und verschiedene Nachrichten erhalten immer verschiedene Nonces, ganz ohne Zufallszahlengenerator. Der Preis dafür sind Fehlerangriffe: Ein Glitch beim zweimaligen Signieren derselben Nachricht kann den Schlüssel offenlegen. Deshalb bevorzugen manche Hardware-Wallets und der Post-Quanten-Standard ML-DSA das Signieren in der Hedged-Variante, bei dem zusätzlich frischer Zufall einfließt.

Kodierung und Malleability

ECDSA kennt zwei Kodierungen für Signaturen: r‖s im Raw-Format (JOSE, WebCrypto, COSE, PKCS #11) und eine SEQUENCE in ASN.1 DER (X.509, TLS, OpenSSL, Java, WebAuthn-Assertions). Die Verwechslung der beiden ist die mit Abstand häufigste Ursache für Fehler vom Typ „invalid signature“, und die Anleitung zu DER und Raw behandelt das ausführlich. ECDSA ist außerdem formbar: Jeder kann (r, s) in das ebenso gültige (r, n − s) umwandeln, weshalb Bitcoin und Ethereum Low-S erzwingen.

Ed25519 hat nur eine 64-Byte-Kodierung, und RFC 8032 §5.1.7 verlangt, dass S unter der Gruppenordnung liegt; das beseitigt die offensichtliche Malleability.

Grenzfälle bei der Prüfung

Die Prüfung einer ECDSA-Signatur ist klar definiert: Stelle sicher, dass r und s im Bereich 1…n−1 liegen, berechne u₁·G + u₂·Q und vergleiche die x-Koordinate des Ergebnisses mit r. Die Bereichsprüfung auszulassen ist fatal: Java 15 bis 18 akzeptierte für jede Nachricht eine Signatur aus lauter Nullen (CVE-2022-21449).

Bei der Prüfung von EdDSA-Signaturen gibt es ein subtileres Problem. Weil Edwards25519 den Kofaktor 8 hat, erlaubt RFC 8032 sowohl eine Prüfung mit Kofaktor, [8][S]B = [8]R + [8][k]A, als auch die Prüfung ohne Kofaktor, [S]B = R + [k]A, und Bibliotheken unterscheiden sich zusätzlich im Umgang mit Punkten kleiner Ordnung und nicht kanonischen Kodierungen. Bei ehrlich erzeugten Signaturen stimmen die Ergebnisse überein, bei gezielt manipulierten Eingaben nicht. Systeme, in denen sich viele Parteien über die Gültigkeit einig sein müssen, etwa Blockchains, legen sich auf ein Regelwerk fest; meist fällt die Wahl auf ZIP 215 von Zcash.

Wo welches Verfahren unterstützt wird

ECDSA P-256 ist der kleinste gemeinsame Nenner von Hardware und Webplattform. WebCrypto unterstützt es in jedem Browser, die Secure Enclave von Apple und die meisten TPMs, HSMs, Smartcards und Schlüsseltypen von Cloud-KMS bieten es an (oft ausschließlich), Passkeys nutzen es standardmäßig (COSE −7), und die Baseline Requirements des CA/Browser Forum (§6.1.5) erlauben für öffentlich vertrauenswürdige TLS-Zertifikate nur RSA und ECDSA auf P-256, P-384 und P-521.

Ed25519 dominiert in softwaredefinierten Ökosystemen. OpenSSH erzeugt seit Version 9.5 (Oktober 2023) standardmäßig Ed25519-Schlüssel; Signal, WireGuard, Tor, age und die meisten neu entwickelten Protokolle bauen auf den 25519-Kurven auf (X25519 für den Schlüsselaustausch, Ed25519 für Signaturen); OpenPGP-v6-Schlüssel unterstützen es nativ (RFC 9580); und WebCrypto unterstützt es ab Firefox 129, Safari 17 und Chrome 137. In JOSE ersetzt RFC 9864 die polymorphe Kennung EdDSA durch die vollständig spezifizierte Kennung Ed25519.

In FIPS-validierten Umgebungen sind beide nach FIPS 186-5 zugelassen, wobei ältere validierte Module womöglich aus der Zeit vor der EdDSA-Unterstützung stammen. Langfristig fallen beide einem Quantencomputer zum Opfer, und NIST IR 8547 (noch ein Entwurf) schlägt vor, beide nach 2035 nicht mehr zuzulassen.

Geschwindigkeit

Einer verbreiteten Annahme zufolge ist Ed25519 viel schneller als ECDSA. Das stimmte, solange P-256-Implementierungen generisch waren; für das heutige OpenSSL, das handoptimierten P-256-Code mitbringt, stimmt es nicht. Auf einem Kern eines Apple M4 Max erzeugte OpenSSL 3.6.5 etwa 87.000 P-256-Signaturen pro Sekunde gegenüber etwa 60.000 mit Ed25519 und prüfte etwa 29.000 gegenüber 25.000. In reinem JavaScript (@noble/curves 2.3.0) prüft Ed25519 etwa 50 % schneller, während P-256 etwas schneller signiert. So oder so geht es um Mikrosekunden, die selten den Ausschlag geben; entscheidend ist, dass beide um ein bis zwei Größenordnungen schneller sind als das Signieren mit RSA.

Das folgende Skript, ausgeführt mit Node.js 26.10, zeigt die praktischen Unterschiede in wenigen Zeilen.

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

const message = Buffer.from("transfer 100 to alice");

const ed = generateKeyPairSync("ed25519");
const ec = generateKeyPairSync("ec", { namedCurve: "P-256" });

// Ed25519: the algorithm argument is null because the hash is fixed (SHA-512).
const ed1 = sign(null, message, ed.privateKey);
const ed2 = sign(null, message, ed.privateKey);

// ECDSA P-256 with SHA-256, raw r||s output as used by JOSE and WebCrypto.
const ec1 = sign("sha256", message, { key: ec.privateKey, dsaEncoding: "ieee-p1363" });
const ec2 = sign("sha256", message, { key: ec.privateKey, dsaEncoding: "ieee-p1363" });

console.log("Ed25519 signature bytes:", ed1.length, "deterministic:", ed1.equals(ed2));
console.log("ECDSA P-256 signature bytes:", ec1.length, "deterministic:", ec1.equals(ec2));
console.log("Ed25519 public key (SPKI DER) bytes:", ed.publicKey.export({ type: "spki", format: "der" }).length);
console.log("P-256 public key (SPKI DER) bytes:", ec.publicKey.export({ type: "spki", format: "der" }).length);
console.log("both verify:", verify(null, message, ed.publicKey, ed1) && verify("sha256", message, { key: ec.publicKey, dsaEncoding: "ieee-p1363" }, ec1));

Ed25519 signature bytes: 64 deterministic: true
ECDSA P-256 signature bytes: 64 deterministic: false
Ed25519 public key (SPKI DER) bytes: 44
P-256 public key (SPKI DER) bytes: 91
both verify: true

Der ECDSA-Signierer von Node verwendet zufällige Nonces, daher unterscheiden sich zwei Signaturen über dieselbe Nachricht; beide bestehen trotzdem die Prüfung. Der Signatur-Verifizierer akzeptiert beide Verfahren und zeigt an, welche Kodierung er erkannt hat.

Wann welches Verfahren passt

• SSH-Benutzer- und Hostschlüssel: Ed25519 oder ed25519-sk mit einem FIDO-Sicherheitsschlüssel. Verwende ECDSA nur für alte Server oder Hardware, die Ed25519 nicht unterstützt.
• Passkeys und WebAuthn: Akzeptiere beide (COSE −7 sowie −8 oder −19), rechne bei Plattform-Authenticators aber mit ES256.
• Öffentlich vertrauenswürdige TLS-Zertifikate: ECDSA P-256 (oder P-384); die Baseline Requirements lassen Ed25519 nicht zu.
• JWTs und API-Tokens: ES256 für die größte Kompatibilität und für Schlüssel in einem Cloud-KMS; Ed25519, wo jeder Empfänger RFC 8037 oder RFC 9864 unterstützt. Der Vergleich ES256 vs. EdDSA für JWT geht genauer darauf ein.
• Schlüssel in der Secure Enclave, in TPMs, Smartcards oder den meisten HSMs: ECDSA P-256, weil die Hardware genau das anbietet.
• Blockchains: Hier hast du keine Wahl; richte dich nach der Chain (ECDSA oder Schnorr auf secp256k1 für Bitcoin und Ethereum, Ed25519 für Solana).
• Neue Protokolle mit konsenskritischer Prüfung: Ed25519 mit einer explizit festgelegten Prüfregel wie ZIP 215.

Hinweise zur Migration

Zwischen einem P-256-Schlüssel und einem Ed25519-Schlüssel gibt es keine Umwandlung: verschiedene Kurven, verschiedene Schlüsselformate. Der Wechsel von einem zum anderen ist eine Schlüsselrotation.

1. Erzeuge neue Schlüssel dort, wo sie künftig liegen. Mit openssl genpkey -algorithm ED25519 oder ssh-keygen -t ed25519 oder direkt im HSM, falls es Ed25519 unterstützt. Prüfe die Unterstützung in der Firmware, bevor du planst.
2. Veröffentliche während der Übergangszeit beide Schlüssel. Gib in einem JWKS jedem Schlüssel eigene Werte für kid und alg; füge in authorized_keys die neue Zeile hinzu, bevor du die alte entfernst; beantrage bei Zertifikaten ein neues für den neuen Schlüssel.
3. Aktualisiere die Verifizierer vor den Signierern. Verifizierer müssen die neue Algorithmuskennung akzeptieren (Ed25519 oder EdDSA in JOSE, OID 1.3.101.112 in X.509, ssh-ed25519 in SSH), dabei aber weiterhin an einer fest vorgegebenen Allowlist festhalten und die Wahl nie dem Token oder der Nachricht überlassen.
4. Stelle das Signieren um und nimm danach den alten Schlüssel außer Betrieb, sobald alles, was damit signiert wurde, abgelaufen ist.
5. Achte auf Kodierungen. ECDSA-Code wandelt Signaturen oft zwischen DER und Raw-Format um; Ed25519-Code darf das nicht, und die Größe eines „privaten Schlüssels“ für Ed25519 hängt von der API ab (32-Byte-Seed oder 64 Byte aus Seed und öffentlichem Schlüssel).

Der umgekehrte Weg, von Ed25519 zu ECDSA, kommt vor allem vor, wenn Schlüssel in Hardware umziehen. Verwende deterministische oder Hedged-Nonces, erzwinge Low-S, wenn Signaturen als Kennungen dienen, und teste den Umgang mit DER und Raw-Format mit dem Konverter DER ⇄ Raw.

Quellen

• FIPS 186-5, Standard für digitale Signaturen (§6 ECDSA, §7 EdDSA)
• RFC 8032, digitaler Signaturalgorithmus auf Edwards-Kurven
• RFC 6979, deterministische Verwendung von DSA und ECDSA
• SEC 1 v2, Kryptografie mit elliptischen Kurven
• RFC 9864, vollständig spezifizierte Algorithmen für JOSE und COSE
• RFC 8410, Ed25519 und Ed448 in X.509
• ZIP 215, explizite Definition der Ed25519-Validierung
• Baseline Requirements des CA/Browser Forum, §6.1.5
• Versionshinweise zu OpenSSH 9.5