ML-DSA vs. ECDSA: Umstieg auf Post-Quanten-Signaturen

Bei ML-DSA vs. ECDSA geht es um die Signaturhälfte des Übergangs zur Post-Quanten-Kryptografie. ECDSA auf P-256 liefert 64-Byte-Signaturen und ist überall im Einsatz, doch der Shor-Algorithmus bricht es. ML-DSA (FIPS 204, August 2024) widersteht bekannten Quantenangriffen und ist schnell, seine Schlüssel und Signaturen liegen aber im Kilobytebereich. Anders als beim Schlüsselaustausch, wo hybrides ML-KEM in Browsern bereits die Voreinstellung ist, liegt die Migration der Signaturen größtenteils noch vor uns.

Auf einen Blick

Die Geschwindigkeiten wurden mit openssl speed auf einem Kern eines Apple M4 Max gemessen. ML-DSA ist in OpenSSL portabler C-Code; optimierte Implementierungen signieren um ein Mehrfaches schneller.

Warum der Umstieg nötig ist

ECDSA beruht auf dem Problem des diskreten Logarithmus auf elliptischen Kurven, das der Shor-Algorithmus auf einem großen, fehlertoleranten Quantencomputer effizient löst. Eine solche Maschine gibt es noch nicht, und die Schätzungen, wann es eine geben könnte, gehen weit auseinander. Signaturen haben aber eine Eigenschaft, die ihre Dringlichkeit bestimmt: Wer später eine Signatur fälscht, macht damit keine vergangene Authentifizierung rückgängig. Ein TLS-Handshake, der 2026 mit ECDSA authentifiziert wurde, lässt sich nicht nachträglich angreifen, wie es bei einem aufgezeichneten Schlüsselaustausch möglich ist. Früh Aufmerksamkeit braucht dagegen alles, dessen Signaturen viele Jahre vertrauenswürdig bleiben müssen: Schlüssel von Root-CAs und Zwischen-CAs, Firmware und Bootketten, Roots für die Codesignatur, Rechtsdokumente und Langzeitarchive.

ML-DSA ist ein gitterbasiertes Signaturverfahren (hervorgegangen aus CRYSTALS-Dilithium), dessen Sicherheit auf Module-LWE und Module-SIS beruht; ein Quantenvorteil über generische Beschleunigungen hinaus ist dagegen nicht bekannt. NIST IR 8547 (ein erster öffentlicher Entwurf) schlägt vor, ECDSA, EdDSA und RSA nach 2035 nicht mehr zuzulassen, und CNSA 2.0 der NSA verlangt ML-DSA-87 für nationale Sicherheitssysteme, wobei das Signieren von Software und Firmware zuerst umgestellt wird.

Das Größenproblem

Gerade die Größe macht die Migration schwierig. Ein TLS-Server authentifiziert sich mit einer Zertifikatskette und einer Handshake-Signatur; mit ECDSA ergeben die Schlüssel des Leaf- und des Zwischenzertifikats, ihre Signaturen, zwei eingebettete SCTs und die Signatur in CertificateVerify zusammen einige Hundert Byte. Mit ML-DSA-44 sind dieselben Elemente etwa 14,7 KB groß (zwei öffentliche Schlüssel mit je 1.312 Byte und fünf Signaturen mit je 2.420 Byte: zwei auf den Zertifikaten, zwei in den SCTs und die in CertificateVerify), mit ML-DSA-65 noch mehr. Damit überschreitet der erste Flight des Servers das anfängliche Congestion Window von TCP, was zusätzliche Roundtrips kostet, und die Amplification-Limits von QUIC geraten unter Druck.

#!/bin/sh
dir=$(mktemp -d)
cd "$dir" || exit 1
for alg in EC ML-DSA-44 ML-DSA-65; do
  if [ "$alg" = EC ]; then
    openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out key.pem 2>/dev/null
    label="ECDSA P-256"
  else
    openssl genpkey -algorithm "$alg" -out key.pem 2>/dev/null
    label="$alg"
  fi
  openssl req -new -x509 -key key.pem -subj "/CN=example.com" -days 90 -outform DER -out cert.der 2>/dev/null
  printf '%-12s certificate %5s bytes\n' "$label" "$(wc -c < cert.der | tr -d ' ')"
done
cd / && rm -rf "$dir"

ECDSA P-256  certificate   388 bytes
ML-DSA-44    certificate  3985 bytes
ML-DSA-65    certificate  5514 bytes

Die Antwort der Web-PKI wird noch ausgearbeitet. Chrome hat im Februar 2026 angekündigt, künftig auf Merkle Tree Certificates (ein Internet-Draft der IETF-Arbeitsgruppe PLANTS) zu setzen, die die meisten Signaturen pro Zertifikat durch kurze Inklusionsbeweise ersetzen, und keine Post-Quanten-X.509-Zertifikate in seinen aktuellen Root Store aufnehmen zu wollen. Das CA/Browser Forum hat ML-DSA für öffentlich vertrauenswürdige TLS-Zertifikate noch nicht zugelassen. Private PKIs können ML-DSA-Zertifikate nach RFC 9881 bereits ausstellen, und OpenSSL ab 3.5, Bouncy Castle und weitere Bibliotheken unterstützen sie.

Hybride und Composite-Ansätze

In der Übergangszeit brauchen viele Systeme Signaturen, die sich bei alten wie bei neuen Clients prüfen lassen oder die sicher bleiben, wenn einer der beiden Algorithmen versagt:

• Composite-Signaturen (draft-ietf-lamps-pq-composite-sigs, noch ein Internet-Draft) definieren einzelne Algorithmuskennungen wie ML-DSA-65 mit ECDSA P-256, deren Signatur nur gültig ist, wenn beide Teile die Prüfung bestehen. RFC 9980 für OpenPGP verfolgt denselben Ansatz mit ML-DSA-65+Ed25519, und OpenSSH 10.4 hat einen experimentellen Schlüsseltyp ML-DSA-44+Ed25519 eingeführt.
• Doppelsignaturen hängen zwei unabhängige Signaturen an (CMS unterstützt mehrere Strukturen vom Typ SignerInfo, manche Dokumentformate erlauben mehrere Signaturfelder), sodass jeder Verifizierer die Signatur prüft, die er versteht.
• Parallele PKIs stellen sowohl klassische als auch Post-Quanten-Zertifikate aus und überlassen den Clients die Wahl; dieses Modell wird von der TLS-Aushandlung über signature_algorithms bereits unterstützt.

Wann welches Verfahren passt

• Öffentliche TLS-Serverzertifikate, Passkeys, OIDC und öffentliche JWTs: ECDSA (oder Ed25519) für heute; verfolge für den Umstieg die Arbeit der Browser und der IETF.
• Private PKI für langlebige Dienste und Geräte: ML-DSA-65 oder, wo es beide Arten von Verifizierern gibt, eine Composite-Signatur aus ML-DSA und ECDSA.
• Firmware und Secure Boot: ML-DSA-87 oder die hashbasierten Verfahren LMS, XMSS oder SLH-DSA, je nachdem, ob du die Vorgaben von CNSA 2.0 erfüllen musst.
• Signieren von Code und Paketen: Ergänze ML-DSA neben den bestehenden Signaturen, sobald die Ökosysteme (Sigstore, Betriebssystemhersteller) es unterstützen.
• Blockchains: Hier triffst du die Wahl nicht selbst; für mehrere Chains gibt es Vorschläge für Post-Quanten-Signaturen, aber auf Bitcoin oder Ethereum ist keiner davon breit im Einsatz.
• Kurzlebige Tokens und Sitzungen: ECDSA bleibt in Ordnung, bis die Verifizierer umstellen, da das Fälschungsrisiko nur in Echtzeit besteht.

Hinweise zur Migration

1. Erfasse jeden Signaturschlüssel und jeden Verifizierer (eine kryptografische Stückliste hilft dabei), samt Schlüssellaufzeiten und der Angabe, wer prüft.
2. Entferne Annahmen über Größen: Datenbankspalten, Größenlimits für HTTP-Header (eine ML-DSA-65-Signatur ist in base64 etwa 4,4 KB groß), Speicher auf Smartcards, QR-Codes und DNS-Einträge.
3. Mach Algorithmen aushandelbar: Algorithmuskennungen in Formaten, Allowlists in Verifizierern und Schlüsselkennungen, damit neue Schlüssel neben alten eingeführt werden können.
4. Beginne bei langlebigen Roots: Erstelle für private PKIs jetzt Root-CAs und Zwischen-CAs mit ML-DSA oder Composite-Signaturen, denn die Verteilung von Roots dauert Jahre.
5. Teste die Leistung auf realen Pfaden: Handshake-Latenz mit größeren Ketten, Signierdurchsatz (in portablem Code eine Größenordnung langsamer als ECDSA), Prüfung auf eingeschränkten Geräten.
6. Behalte den Stand von FIPS und Richtlinien im Blick: FIPS 204 ist final, NIST IR 8547 ist noch ein Entwurf, Composite-Signaturen sind noch Entwürfe, und die Regeln der Web-PKI haben sich noch nicht geändert.

Quellen

• FIPS 204, Standard für modulgitterbasierte digitale Signaturen
• FIPS 186-5, Standard für digitale Signaturen
• RFC 9881, ML-DSA in X.509
• NIST IR 8547, erster öffentlicher Entwurf
• draft-ietf-lamps-pq-composite-sigs (Internet-Draft)
• draft-ietf-plants-merkle-tree-certs (Internet-Draft)
• Root-Programme von Chrome, darunter das quantenresistente Programm
• FAQ der NSA zu CNSA 2.0