NISTs Post-Quantum Standards sind da. Ihre Infrastruktur ist nicht bereit.

Im August 2024 veröffentlichte das National Institute of Standards and Technology drei finalisierte Post-Quantum-Kryptographie (PQC)-Standards: FIPS 203 (ML-KEM, basierend auf CRYSTALS-Kyber), FIPS 204 (ML-DSA, basierend auf CRYSTALS-Dilithium) und FIPS 205 (SLH-DSA, basierend auf SPHINCS+). Sie stellen den Höhepunkt eines achtjährigen Standardisierungsprozesses dar, der 2016 begann. Die Standards existieren. Das Bedrohungsmodell ist real. Was noch nicht geschehen ist, ist eine nennenswerte Migration der tatsächlichen Internet-Infrastruktur.

Die kryptografischen Algorithmen, die den Großteil des heutigen Internets schützen – RSA-2048, ECDH P-256, ECDSA – basieren auf mathematischen Problemen (Integerfaktorisierung und diskreter Logarithmus), die klassische Computer nicht effizient lösen können. Ein kryptografisch relevanter Quantum Computer (CRQC), der Shors Algorithmus ausführt, könnte diese in Stunden brechen. Eine solche Maschine existiert heute nicht, aber die "Harvest now, decrypt later"-Bedrohung ist bereits aktiv: staatliche Akteure sammeln heute verschlüsselten Datenverkehr mit der Absicht, ihn zu entschlüsseln, sobald die Quantum-Hardware ausgereift ist.

Was NIST tatsächlich standardisiert hat

FIPS 203 / ML-KEM ist der primäre Key Encapsulation Mechanism für allgemeine Verschlüsselung und Schlüsselaustausch – der direkte Ersatz für RSA und ECDH in Protokollen wie TLS. Es bietet drei Parametersätze: ML-KEM-512, ML-KEM-768 und ML-KEM-1024, die das Sicherheitsniveau gegen Schlüssel- und Chiffretextgrößen abwägen. ML-KEM-768 gilt als praktischer Standard und bietet Sicherheit vergleichbar mit AES-192.

FIPS 204 / ML-DSA übernimmt digitale Signaturen und ersetzt RSA und ECDSA in Zertifikatsketten, Code Signing und Authentifizierungssystemen. Wie ML-KEM ist es in drei Parametervarianten erhältlich (ML-DSA-44, ML-DSA-65, ML-DSA-87). Der Haken: ML-DSA-Signaturen sind deutlich größer als ECDSA-Signaturen – ML-DSA-65 erzeugt 3.309-Byte-Signaturen gegenüber 64–72 Bytes bei ECDSA. Dies hat reale Auswirkungen auf die Größe von Zertifikatsketten in TLS-Handshakes.

FIPS 205 / SLH-DSA ist ein zustandsloses hashbasiertes Signaturschema, das in seinen Sicherheitsannahmen konservativer ist als ML-DSA, da es nur auf der Sicherheit von Hashfunktionen und nicht auf Gitterproblemen beruht. Es ist langsamer und erzeugt größere Signaturen, wodurch es sich besser für langlebige Signaturen auf Root-Zertifikaten und Firmware eignet als für Hochdurchsatz-Authentifizierung.

Wo das Internet heute tatsächlich steht

Browser-Unterstützung für hybriden Schlüsselaustausch kam bereits vor der Finalisierung der Standards. Chrome aktivierte X25519Kyber768 (ein Hybrid, der klassisches ECDH mit Kyber kombiniert) standardmäßig in Chrome 124 (April 2024). Cloudflare und Google betreiben seit Ende 2023 hybrides PQC für TLS auf ihrer Edge-Infrastruktur. Dies deckt jedoch nur den Schlüsselaustausch ab – die Zertifikatsketten, die die Serveridentität validieren, verwenden weiterhin durchgängig ECDSA oder RSA.

Das Zertifikats-Ökosystem ist im Wesentlichen nicht migriert. Die rund 200 Millionen aktiven TLS-Zertifikate Mitte 2025 sind überwiegend ECDSA oder RSA. Zertifizierungsstellen wie DigiCert und Let's Encrypt haben mit Tests zur Ausstellung von PQC-Zertifikaten begonnen, aber noch keine produktiven PQC-Zertifikate in großem Maßstab ausgerollt. Das Problem verschärft sich: PQC-Zertifikate mit ML-DSA-Signaturen würden die TLS-Handshake-Größen erheblich vergrößern, was Clients mit strengen Paketgrößenbeschränkungen brechen oder die Leistung bei Verbindungen mit hoher Latenz beeinträchtigen könnte.

VPN-Protokolle hinken ebenfalls hinterher. WireGuard-, OpenVPN- und IPsec/IKEv2-Implementierungen variieren stark in der PQC-Unterstützung. OpenSSH hat in Version 8.5 (2021) Unterstützung für den hybriden sntrup761x25519-sha512-Schlüsselaustausch hinzugefügt und in 9.0 (2022) zum Standard gemacht, was es zu einer der frühesten weit verbreiteten PQC-Integrationen macht. Aber VPN-Produkte, die in Unternehmensumgebungen verwendet werden – Cisco, Palo Alto, Fortinet – haben unterschiedliche Zeitpläne, viele planen PQC-Unterstützung noch für 2026–2027.

Der Zeitplan, dem Organisationen gegenüberstehen

Der Zeitplan der US-Regierung ist der vorschreibendste. Die NSA Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) schreibt die PQC-Migration für nationale Sicherheitssysteme vor, mit unterschiedlichen Fristen je nach Systemtyp. Software- und Firmware-Signing: bis 2025. Netzwerkausrüstung: bis 2026. Betriebssysteme: bis 2027. Die meisten klassifizierten und sensiblen Regierungssysteme: bis 2033. NISTs eigene Leitlinie in Special Publication 1800-38B bietet einen Migrationsfahrplan für Bundesbehörden mit ähnlichen Zeitplänen.

Für private Organisationen gibt es noch kein regulatorisches Mandat – aber das ändert sich. Die EU-NIS2-Richtlinie enthält Anforderungen an kryptografische Agilität, und die ENISA (EU-Agentur für Cybersicherheit) hat PQC-Migrationsleitlinien veröffentlicht, die Organisationen empfehlen, die Inventarisierungs- und Planungsphasen bis 2025 abzuschließen und die aktive Migration bis 2026 zu beginnen. Finanzaufsichtsbehörden im Vereinigten Königreich und in der EU haben ähnliche Leitlinien herausgegeben.

Das "Harvest now, decrypt later"-Fenster ist der kritische Treiber für die Priorisierung. Alle Daten mit Vertraulichkeitsanforderungen, die über 5–10 Jahre hinausgehen, sollten als bereits gefährdet behandelt werden, wenn sie heute über klassische Kryptographie übertragen werden. Gesundheitsakten, Finanzvereinbarungen, geistiges Eigentum und klassifizierte Kommunikation fallen alle in diese Kategorie.

Die technischen Herausforderungen, die die Migration tatsächlich mit sich bringt

PQC-Migration ist kein einfacher Drop-in-Ersatz. Die größeren Schlüssel- und Signaturgrößen bei Post-Quantum-Algorithmen führen zu kaskadierenden Kompatibilitätsproblemen. ML-KEM-768-öffentliche Schlüssel sind 1.184 Byte groß, verglichen mit 32 Byte bei X25519. ML-DSA-65-öffentliche Schlüssel sind 1.952 Byte groß. Protokolle mit festen Header-Größen, Hardware Security Modules mit Schlüsselgrößenbeschränkungen und HSM-Firmware, die vor PQC stammt, erfordern alle Updates oder Ersatz.

Kryptografische Bibliotheken sind den meisten Anwendungen voraus. OpenSSL 3.x unterstützt PQC über den Open Quantum Safe (OQS)-Provider. BoringSSL (verwendet von Chrome und Android) hat Kyber integriert. Die NIST-validierte liboqs-Bibliothek bietet Referenzimplementierungen. Aber die Integration in Produktionssysteme erfordert Tests auf Leistungsregressionen, insbesondere bei Embedded-Systemen und eingeschränkten IoT-Geräten, wo der Rechenaufwand von ML-KEM erheblich sein kann.

Die Infrastruktur der Zertifizierungsstelle benötigt umfangreiche Updates. Die Ausstellung von PQC-Zertifikaten erfordert die Aktualisierung der CA-Software, von HSMs, die ML-DSA-Operationen unterstützen, von OCSP-Respondern und von CRL-Verteilungspunkten. Die gesamte PKI-Kette – Root-CAs, Intermediate-CAs, Leaf-Zertifikate – muss koordiniert migrieren, wobei während eines Übergangszeitraums, der ein Jahrzehnt dauern könnte, die Rückwärtskompatibilität erhalten bleibt.

Was Organisationen jetzt tun müssen

Führen Sie ein kryptografisches Inventar durch. Kartieren Sie jedes System, jeden Dienst und jeden Datenfluss, der Public-Key-Kryptographie verwendet. Dies umfasst TLS-Endpunkte, VPNs, SSH-Infrastruktur, Code-Signing-Pipelines, PKI-Systeme, verschlüsselte Datenbanken und alle HSMs oder Smartcards. NIST SP 1800-38B bietet eine detaillierte Methodik für diesen Inventarisierungsprozess.

Priorisieren Sie nach Datensensitivität und -lebensdauer. Systeme, die Daten übertragen oder speichern, die über 2030 hinaus Vertraulichkeit erfordern, sollten ganz oben in der Migrationswarteschlange stehen. Harvest-now-decrypt-later-Angriffe machen die Bedrohung heute real, obwohl der Quantum Computer noch nicht existiert.

Aktivieren Sie hybride Kryptographie, wo verfügbar. Hybride Modi (klassisch + PQC) bieten Quantenresistenz, ohne die klassische Sicherheit zu opfern, falls der PQC-Algorithmus Schwachstellen aufweist. IETF RFC 9370 standardisiert hybriden Schlüsselaustausch für TLS 1.3. Die meisten modernen TLS-Bibliotheken unterstützen heute den hybriden Modus X25519MLKEM768.

Aktualisieren Sie kryptografische Bibliotheksabhängigkeiten. Aktualisieren Sie auf OpenSSL 3.3+, BoringSSL-Builds vom Januar 2024 oder später oder gleichwertige mit OQS-Provider-Unterstützung. Prüfen Sie jeglichen eingebundenen kryptografischen Code oder Hardware-Beschleunigung, die klassische Algorithmusannahmen fest codiert haben könnte.

Beziehen Sie Ihre Zertifizierungsstelle und PKI-Anbieter ein. Fragen Sie DigiCert, Sectigo, Let's Encrypt und interne CA-Betreiber nach ihren PQC-Migrationsfahrplänen und Zeitplanverpflichtungen. Bauen Sie diese Daten in Ihre eigenen Planungshorizonte ein.

Planen Sie Leistungstests. PQC-Algorithmen sind nicht einheitlich langsamer, aber sie sind anders. ML-KEM ist schnell in Software; hashbasierte Signaturen wie SLH-DSA sind langsam. Messen Sie Ihre spezifischen Workloads – insbesondere solche mit hohem Volumen an Signaturprüfungen, wie CDN, Load Balancer oder Authentifizierungsdienst im großen Maßstab.

Die Quantum-Bedrohung ist nicht unmittelbar im Sinne von "ein CRQC wird nächstes Jahr existieren". Seriöse Schätzungen von IBM, Google und akademischen Forschern gehen unter aktuellen Entwicklungspfaden von einer kryptografisch relevanten Quantum-Computing-Entfernung von mindestens 10–15 Jahren aus. Aber kryptografische Migrationen dauern 5–15 Jahre, um über komplexe Infrastrukturen abgeschlossen zu werden. NIST hat die Standards veröffentlicht. Die Migrationsuhr hat zu ticken begonnen. Organisationen, die jetzt mit systematischer Planung und frühzeitiger Migration beginnen, werden Krisenmodus-Hektik vermeiden, wenn regulatorische Fristen eintreten – oder wenn ein Quantum-Computing-Durchbruch den Zeitplan verschiebt.