NISTʼs Post-Quantum-Kryptographie-Standards sind final – der Migrationszeitplan, den jede Organisation kennen muss

Die Standards sind final. Die Uhr läuft.

Im August 2024 veröffentlichte das National Institute of Standards and Technology (NIST) FIPS 203, FIPS 204 und FIPS 205 – die ersten finalisierten Post-Quantum-Kryptographie-Standards (PQC) der Geschichte. Nach fast einem Jahrzehnt der Evaluierung standardisierte die Behörde drei Algorithmen: ML-KEM (Module Lattice Key Encapsulation Mechanism, basierend auf Kyber), ML-DSA (Module Lattice Digital Signature Algorithm, basierend auf Dilithium) und SLH-DSA (Stateless Hash-Based Digital Signature Algorithm, basierend auf SPHINCS+). Ein vierter Algorithmus, FN-DSA (basierend auf Falcon), soll in einer nachfolgenden FIPS-Publikation standardisiert werden. Dies sind keine Entwürfe oder Vorschläge – es sind verbindliche Standards, und NISTʼs Empfehlung ist eindeutig: Die Migration muss jetzt beginnen.

Die Dringlichkeit liegt nicht darin, was Quantencomputer im Jahr 2026 können – sondern darin, was sie zwischen 2030 und 2035 können werden, und was Angreifer bereits heute tun. Das Harvest-now-decrypt-later-Bedrohungsmodell bedeutet: Staatliche Akteure und gut ausgestattete Angreifer erfassen verschlüsselten Datenverkehr bereits jetzt, speichern ihn und setzen darauf, dass ein kryptographisch relevanter Quantencomputer (CRQC) ihn irgendwann entschlüsseln wird. Jede Information, die länger als fünf bis zehn Jahre vertraulich bleiben muss, ist bereits gefährdet – darunter Gesundheitsdaten, Finanzverträge, Regierungskommunikation und geistiges Eigentum.

Was Quantencomputer tatsächlich brechen können – und wann

Die heutigen Quantencomputer sind fehlerhafte, kleinmaßstäbige Systeme. IBMs Heron-Prozessor und vergleichbare Systeme arbeiten im Bereich von Hunderten bis wenigen Tausend physikalischen Qubits – weit entfernt von den Millionen fehlerkorrigierter logischer Qubits, die nötig wären, um Shorʼs Algorithmus gegen RSA-2048 oder ECDSA P-256 einzusetzen. Aktuelle Maschinen können kein produktiv eingesetztes kryptographisches System brechen. Die realistische Schätzung für einen CRQC, der RSA-2048 brechen kann, liegt zwischen 2030 und 2035 – wobei optimistische Prognosen einen früheren Zeitpunkt annehmen, falls die Fehlerkorrektur schneller voranschreitet als erwartet.

Was Shorʼs Algorithmus bricht: RSA (alle in der Praxis verwendeten Schlüsselgrößen), Diffie-Hellman-Schlüsselaustausch (einschließlich endlicher Felder und elliptischer Kurven) sowie ECDSA/EdDSA-Signaturen. Was er nicht bricht: symmetrische Verfahren wie AES-256, bei denen lediglich eine Verdopplung der Schlüssellänge erforderlich ist (Groverʼs Algorithmus liefert nur eine quadratische Beschleunigung). TLS 1.3 in der heutigen Deployment-Form stützt sich auf ECDHE für den Schlüsselaustausch und ECDSA oder RSA für die Zertifikatsauthentifizierung – beides ist langfristig verwundbar. SHA-256 und SHA-3 gelten bei aktuellen Ausgabelängen als quantenresistent, mit einer moderaten Reduzierung der Sicherheitsmarge.

Die drei neuen Algorithmen: Technische Details

ML-KEM (FIPS 203 / Kyber) ist der primäre Standard für Key Encapsulation – den Mechanismus zur Herstellung gemeinsamer Geheimnisse in Protokollen wie TLS. Er basiert auf Module-Lattice-Problemen (konkret dem Module Learning With Errors-Problem). Beim Parameter-Set ML-KEM-768 (ca. 128-Bit-Quantensicherheit) betragen öffentliche Schlüssel 1.184 Byte und Ciphertexts 1.088 Byte – größer als RSAʼs 256-Byte-Schlüssel bei 2048 Bit, doch die Performance überzeugt: ML-KEM-768 erreicht auf einem modernen Server-Core rund 15.000–20.000 Encapsulations pro Sekunde, verglichen mit etwa 3.000–5.000 RSA-2048-Operationen pro Sekunde bei der Schlüsselgenerierung. Die Decapsulation ist ähnlich schnell. Die Schlüsselgenerierung in ML-KEM ist dramatisch schneller als bei RSA.

ML-DSA (FIPS 204 / Dilithium) ist der primäre Standard für digitale Signaturen. Bei ML-DSA-65 (ca. 128-Bit-Quantensicherheit) betragen Signaturen 3.293 Byte und öffentliche Schlüssel 1.952 Byte. Der Signing-Durchsatz erreicht etwa 5.000–8.000 Signaturen pro Sekunde pro Core, die Verifikation ist noch schneller. Zum Vergleich: ECDSA P-256 signiert mit rund 20.000–40.000 Operationen pro Sekunde – ML-DSA ist langsamer, aber die Lücke ist für die meisten Anwendungen beherrschbar. Die größeren Signaturgrößen sind die eigentliche Integrationsherausforderung, insbesondere bei Zertifikatsketten und ressourcenbeschränkten Umgebungen.

SLH-DSA (FIPS 205 / SPHINCS+) ist ein hashbasiertes Signaturverfahren, das ein konservatives, gut verstandenes Sicherheitsfundament bietet. Es basiert ausschließlich auf der Sicherheit der zugrundeliegenden Hash-Funktion (SHA-256 oder SHAKE) – nicht auf Lattice-Härteannahmen. Der Kompromiss liegt bei Performance und Größe: SLH-DSA-128s erzeugt Signaturen von 7.856 Byte und signiert mit etwa 100–500 Operationen pro Sekunde, je nach Parameter-Set. Es eignet sich am besten für hochsicherheitskritische Anwendungsfälle – Firmware-Signierung, Root-Certificate-Authorities oder Kontexte, in denen Signierungen selten und größere Signaturen akzeptabel sind.

Hybrid Key Exchange: Die sichere Brücke

Da die neuen Algorithmen weniger erprobt sind als RSA und ECDH – hinter denen Jahrzehnte realer Kryptanalyse stehen – ist der empfohlene Migrationspfad der hybride Schlüsselaustausch: die Kombination eines klassischen Algorithmus mit einem Post-Quantum-Algorithmus, sodass die Sicherheit gewährleistet bleibt, solange einer von beiden ungebrochen ist. IETF RFC 9180 (HPKE) und Entwurfsstandards für TLS 1.3 PQC Hybrid Key Exchange definieren konkrete Mechanismen. Google Chrome hat den X25519+ML-KEM-768-Hybrid-Schlüsselaustausch seit Chrome 131 (Ende 2024) standardmäßig aktiviert. Cloudflare, AWS und Azure setzen hybrides PQC in ihrer TLS-Terminierungsinfrastruktur bereits ein oder befinden sich in der Einführungsphase. Der Performance-Overhead durch das Hinzufügen von ML-KEM zu einem bestehenden TLS-Handshake beträgt rund 1–2 Millisekunden zusätzliche Latenz und etwa 2 KB zusätzliche Handshake-Daten – für die meisten Anwendungen vernachlässigbar.

Migrationszeitplan nach Organisationsgröße

Großunternehmen und kritische Infrastruktur (2024–2027): Beginnen Sie jetzt mit der kryptographischen Bestandsaufnahme. Identifizieren Sie alle Systeme, die RSA, ECDSA, ECDH und Diffie-Hellman verwenden. Priorisieren Sie langlebige Geheimnisse und besonders sensible Datenspeicher. Setzen Sie hybrides TLS mit ML-KEM auf internetexponierten Diensten ein. Aktualisieren Sie Zertifikatsausstellungs-Pipelines zur Unterstützung von ML-DSA. Klären Sie mit Anbietern die Roadmap für Firmware- und HSM-Unterstützung. NIST empfiehlt, dass große Organisationen die primäre Migration bis 2030 abschließen.

Mittelgroße Organisationen (2025–2028): Nutzen Sie die PQC-Unterstützung der Cloud-Anbieter (AWS Certificate Manager, Google Cloud und Azure ergänzen PQC-Zertifikatsoptionen). Aktivieren Sie hybrides PQC in Load Balancern und API Gateways, sobald die entsprechenden Konfigurationsoptionen verfügbar sind. Aktualisieren Sie VPN- und Remote-Access-Lösungen – viele Anbieter (Cisco, Palo Alto, Fortinet) haben PQC-Unterstützung angekündigt oder bereits ausgeliefert.

Kleine Organisationen (2026–2030): Folgen Sie Ihren Software- und Cloud-Anbietern. Aktualisieren Sie TLS-Bibliotheken (OpenSSL 3.x, BoringSSL und liboqs unterstützen ML-KEM und ML-DSA bereits). Migrieren Sie Certificate Authorities, sobald Ihre CA FIPS 203/204 unterstützt. Der Großteil der Arbeit ergibt sich aus regulären Tooling-Upgrades.

Migrations-Checkliste

• Bestandsaufnahme: Erfassen Sie alle kryptographischen Abhängigkeiten – TLS-Zertifikate, SSH-Schlüssel, Code-Signing-Zertifikate, VPN-Konfigurationen, verschlüsselte Daten im Ruhezustand und HSM-gespeicherte Schlüssel.
• Nach Datenlaufzeit priorisieren: Jedes Geheimnis, das über 2030 hinaus vertraulich bleiben muss, benötigt heute bereits Schutz gegen Harvest-now-decrypt-later-Angriffe.
• Hybrides TLS aktivieren: Setzen Sie X25519+ML-KEM-768 auf allen TLS 1.3-Endpunkten ein. Die meisten großen CDN- und Load-Balancer-Anbieter unterstützen dies jetzt oder in den 2025er Releases.
• Zertifikatsketten aktualisieren: Planen Sie die Migration zu ML-DSA-Zertifikaten. Beobachten Sie die Roadmap Ihrer CA und testen Sie in Staging-Umgebungen mit liboqs oder OQS-fähigen OpenSSL-Builds.
• Code-Signing-Pipelines prüfen: Ersetzen Sie ECDSA-basiertes Signing durch ML-DSA oder SLH-DSA für Firmware, Container-Images und Software-Pakete.
• HSM und Key Management evaluieren: Stellen Sie sicher, dass Ihr HSM-Anbieter FIPS 203/204/205 unterstützt. Thales, Entrust und AWS CloudHSM haben PQC-Roadmaps veröffentlicht.
• SSH aktualisieren: OpenSSH 9.0+ unterstützt hybriden ML-KEM-Schlüsselaustausch. Aktivieren Sie dies für privilegierte Zugriffsinfrastrukturen.
• Performance in Ihrer Umgebung testen: Führen Sie ML-KEM- und ML-DSA-Benchmarks mit liboqs durch, bevor Sie sich auf bestimmte Parameter-Sets festlegen.
• Ihr Team schulen: Security-Engineers müssen Lattice-basierte Kryptographie-Annahmen auf konzeptioneller Ebene verstehen, um Anbieteraussagen und Implementierungsqualität beurteilen zu können.
• Harte Deadline setzen: NIST empfiehlt die Ablösung von RSA und ECC für Schlüsselverteilung und Signaturen bis 2030. Verankern Sie dieses Datum jetzt in Ihrer Security-Roadmap.

Die Post-Quantum-Transition ist die größte kryptographische Infrastrukturmigration seit dem SSL-zu-TLS-Wechsel – und sie hat eine härtere Deadline. Die Algorithmen sind finalisiert, die Implementierungen reifen heran, und Browser sowie Cloud-Anbieter sind bereits in Bewegung. Die einzige Variable ist, ob Ihre Organisation nach eigenem Zeitplan migriert oder erst unter Druck handelt, wenn die Bedrohung akut wird.