Ed25519 vs. Ed448: 128- oder 224-Bit-EdDSA

Bei Ed25519 vs. Ed448 geht es um den Sicherheitsspielraum. Beide gehören zur selben Algorithmenfamilie aus RFC 8032, beide sind in FIPS 186-5 zugelassen, und beide signieren deterministisch, ohne Zufall pro Signatur. Ed448 arbeitet auf einer größeren Kurve und erreicht damit etwa 224 Bit klassische Sicherheit statt etwa 128 – und bezahlt dafür mit Größe, Geschwindigkeit und Unterstützung im Ökosystem.

Auf einen Blick

Die Geschwindigkeiten wurden auf einem Kern eines Apple M4 Max mit openssl speed gemessen.

Sicherheitsspielraum

Beide sind EdDSA über Edwards-Kurven mit vollständigen Additionsformeln, deterministischen Nonces und strikten Kodierungen und damit gleich robust gegenüber Implementierungsfehlern. Der Unterschied liegt in der Größe der Gruppe. Die Gruppe von Ed25519 mit etwa 2²⁵² Elementen bietet etwa 128-Bit-Sicherheit gegen die Pollard-Rho-Methode, dasselbe Niveau wie P-256, AES-128 und die Suche nach Kollisionen bei SHA-256. Die Gruppe von Ed448 mit etwa 2⁴⁴⁶ Elementen bietet etwa 224 Bit, mehr als P-384 (192) und nahe an P-521.

Für klassische Angreifer liegen 128 Bit weit außer Reichweite; der zusätzliche Spielraum sichert also eher gegen unerwartete Fortschritte in der Kryptoanalyse elliptischer Kurven ab als gegen Brute-Force-Angriffe. Gegen einen großen Quantencomputer fallen beide Kurven dem Shor-Algorithmus zum Opfer, die größere nur mit etwas höherem Aufwand; deshalb behandeln die Post-Quanten-Pläne von NIST beide gleich.

Unterschiede in der Konstruktion

Ed448 ist keine hochskalierte Kopie. Es hasht mit SHAKE256 statt SHA-512, was eine andere Hashfunktion in deinem Abhängigkeitsbaum bedeutet, und stellt immer einen Domain-String mit einem Kontext von bis zu 255 Byte voran. Ed25519 hat in seiner reinen Form keinen Kontext; Ed25519ctx gibt es zwar, es wird aber selten implementiert. Braucht dein Protokoll eine Domain-Separation zwischen verschiedenen Verwendungen eines Schlüssels, liefert Ed448 sie gratis mit, während du bei Ed25519 die Trennung in die signierte Nachricht aufnehmen musst.

Beide haben Pre-Hash-Varianten, Ed25519ph und Ed448ph (HashEdDSA in FIPS 186-5 §7.8). Das sind eigene Algorithmen mit inkompatiblen Signaturen; verwende die reinen Varianten, es sei denn, du musst Daten signieren, die du nicht in einem Stück durchreichen kannst.

Das folgende Skript, ausgeführt mit Node.js 26.10 (OpenSSL 3.6.5), zeigt den Größenunterschied.

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

const message = Buffer.from("release-2026.10.tar.gz digest");

for (const type of ["ed25519", "ed448"]) {
  const { privateKey, publicKey } = generateKeyPairSync(type);
  const signature = sign(null, message, privateKey);
  const raw = publicKey.export({ format: "jwk" }).x;
  console.log(
    type.padEnd(8),
    "public key:", Buffer.from(raw, "base64url").length, "bytes,",
    "SPKI DER:", publicKey.export({ type: "spki", format: "der" }).length, "bytes,",
    "signature:", signature.length, "bytes,",
    "verifies:", verify(null, message, publicKey, signature),
  );
}

ed25519  public key: 32 bytes, SPKI DER: 44 bytes, signature: 64 bytes, verifies: true
ed448    public key: 57 bytes, SPKI DER: 69 bytes, signature: 114 bytes, verifies: true

Unterstützung im Ökosystem

Ed25519 ist breit verfügbar: OpenSSH (seit 9.5 der Standard-Schlüsseltyp), die Standardbibliothek von Go, libsodium, BoringSSL, Java ab Version 15, .NET über Bibliotheken, jede große JOSE-Bibliothek, OpenPGP-v6-Schlüssel, Apple CryptoKit, WebCrypto in allen aktuellen Browsern und viele Sicherheitsschlüssel für SSH und FIDO2.

Ed448 gibt es in OpenSSL, Bouncy Castle, Java ab Version 15, Node.js, cryptography für Python, einigen OpenPGP-Implementierungen nach RFC 9580 (in denen es optional ist) und einigen JOSE-Bibliotheken. Es fehlt in OpenSSH, der Standardbibliothek von Go, BoringSSL und WebCrypto im Browser (die Liste der Algorithmen für sign() bei MDN enthält Ed25519, aber nicht Ed448). Keine der beiden Kurven ist in öffentlich vertrauenswürdigen TLS-Zertifikaten erlaubt, deren Schlüssel auf RSA und die NIST-Kurven beschränkt sind.

Wann welches Verfahren passt

• SSH, Git-Signaturen, Software-Releases, JWTs, Authentifizierung zwischen Diensten: Ed25519.
• Signieren im Browser mit WebCrypto: Ed25519 (oder ECDSA P-256 für ältere Browser); Ed448 ist nicht verfügbar.
• Eine Richtlinie, die für Signaturen mindestens 192 Bit klassische Sicherheit verlangt: Ed448 oder, wenn die Richtlinie auf NIST-Kurven aufbaut, P-384 oder P-521 (CNSA 1.0 etwa nannte P-384, nicht Ed448).
• Protokolle, die eine eingebaute Domain-Separation brauchen: Der verpflichtende Kontext von Ed448 hilft; bei Ed25519 nimmst du ein festes Label in die signierten Daten auf.
• Sehr schmalbandige Verbindungen oder knapper Speicher: Ed25519, denn die Signaturen sind 50 Byte und die Schlüssel 25 Byte kürzer.

Hinweise zur Migration

Ein Wechsel zwischen den beiden bedeutet neue Schlüssel: Es sind verschiedene Kurven, verschiedene Hashfunktionen und verschiedene Kennungen.

1. Prüfe zuerst jeden Verifizierer. Die Unterstützung für Ed448 ist der Engpass; ein einziger Empfänger, der auf der Standardbibliothek von Go oder auf OpenSSH aufbaut, schließt es aus.
2. Ändere die Kennungen explizit: OID 1.3.101.113, in JOSE alg Ed448 (RFC 9864) oder für ältere Bibliotheken EdDSA mit crv Ed448, COSE −53, OpenPGP-Algorithmus 28 in v6-Schlüsseln.
3. Lege Puffer und Schemas für 57-Byte-Schlüssel und 114-Byte-Signaturen aus; feste Felder mit 32 und 64 Byte sind die klassische Fehlerquelle.
4. Lege die Kontexte fest. Wenn du Ed448 einführst, definiere den Kontext-String, den dein Protokoll verwendet, denn Signierer und Verifizierer müssen denselben übergeben.
5. Setze für langfristigen Schutz lieber auf einen Post-Quanten-Plan (ML-DSA, möglicherweise als Composite-Signatur mit Ed25519 oder Ed448) als auf den Umstieg von Ed25519 auf Ed448.

Quellen

• RFC 8032, EdDSA (§5.1 Ed25519, §5.2 Ed448)
• FIPS 186-5, Standard für digitale Signaturen (§7)
• NIST SP 800-186 (§3.2.3.1 Edwards25519, §3.2.3.2 Edwards448)
• RFC 8410, Ed25519 und Ed448 in X.509
• RFC 9864, vollständig spezifizierte Algorithmen für JOSE und COSE
• RFC 9580, OpenPGP
• MDN: von SubtleCrypto.sign() unterstützte Algorithmen