NISTs Post-Quantum-Kryptografie-Standards sind final – Ihre Migrationsuhr tickt

NIST hat im August 2024 drei Post-Quantum-Kryptografie-Standards finalisiert: ML-KEM (FIPS 203, basierend auf CRYSTALS-Kyber), ML-DSA (FIPS 204, basierend auf CRYSTALS-Dilithium) und SLH-DSA (FIPS 205, basierend auf SPHINCS+). Nach einem Jahrzehnt der Evaluierung und mehreren Algorithmenrunden sind diese produktionsreif. Die Migrationsuhr begann am Tag der Veröffentlichung der Standards – nicht am Tag, an dem Quantencomputer eintreffen.

Der praktische Zeitplan ist nicht abstrakt. Die US-Regierung hat angeordnet, dass Bundesbehörden bis 2030 für die meisten Systeme mit der PQC-Migration beginnen müssen, bei klassifizierter Infrastruktur noch früher. Die Industrie ist bereits voraus: Google Chrome hat 2023 hybrides ML-KEM in TLS ausgeliefert und seitdem auf die finalisierte FIPS-203-Version aktualisiert. Apple hat PQC mit iOS 17.4 zu iMessage hinzugefügt. Signal hat 2024 sein Protokoll aktualisiert. Wenn Sie Infrastruktur betreiben, die 10+ Jahre sicher bleiben soll – insbesondere alles, was asymmetrischen Schlüsselaustausch betrifft – ist Migration keine Option, sondern Pflicht.

Harvest-Now-Decrypt-Later ist eine aktive Bedrohung

Der Grund, warum Dringlichkeit jetzt zählt, obwohl es noch keine kryptografisch relevanten Quantencomputer gibt, ist harvest-now-decrypt-later (HNDL). Staatliche Gegner erfassen bereits heute verschlüsselten Datenverkehr mit der Absicht, ihn zu entschlüsseln, sobald Quantenkapazität verfügbar ist. Schätzungen von NIST, NSA und CISA gehen davon aus, dass kryptografisch relevante Quantencomputer (CRQCs) in 10–15 Jahren kommen – genau das Zeitfenster, in dem 2026 erfasste Daten entschlüsselt werden könnten, während sie noch intelligence value haben.

Wenn Ihre Anwendung mit Daten umgeht, die ein Jahrzehnt lang vertraulich bleiben müssen – Finanzunterlagen, Gesundheitsdaten, Kommunikation, geistiges Eigentum, Regierungsaufträge – braucht der Gegner heute keinen Quantencomputer. Er braucht einen, solange Ihnen die Geheimhaltung dieser Daten noch wichtig ist. Die Erfassung findet jetzt statt.

Triage: Was wann migrieren

Nicht alles muss gleichzeitig umgestellt werden. Die richtige Triage-Reihenfolge: zuerst Schlüsselaustausch, dann Signaturen, zuletzt symmetrische Verschlüsselung (oder gar nicht).

1. Schlüsselaustausch – Höchste Priorität

RSA- und ECDH-Schlüsselaustausch werden als Erstes von Quantencomputern gebrochen. Ersetzen Sie sie durch ML-KEM (Kyber). Der sichere Standard-Einstieg ist der Hybrid-Modus: klassisch und PQC gleichzeitig laufen lassen. Falls ML-KEM eine unentdeckte Schwäche hat, schützt Sie der klassische Algorithmus. Falls ein CRQC auftaucht, deckt die PQC-Schicht Sie ab.

X25519MLKEM768 ist die konkrete Hybride, die Chrome, Cloudflare und AWS heute in Produktions-TLS einsetzen. Ihr Web-Stack unterstützt es möglicherweise bereits: OpenSSL 3.5 (veröffentlicht April 2025) enthält volle ML-KEM- und ML-DSA-Unterstützung. Die Aktivierung ist typischerweise ein Konfigurationsflag, keine Codeänderung.

2. Digitale Signaturen – Mittlere Priorität

ML-DSA (Dilithium) ersetzt RSA-PSS und ECDSA für Signaturen. Die Dringlichkeit ist hier geringer, weil Signaturen nicht das HNDL-Problem haben – eine Signatur muss nur zum Zeitpunkt der Verifikation gültig sein, nicht ein Jahrzehnt später. Setzen Sie Code-Signing-Zertifikate, langlebige Dokumentsignaturen und interne CA-Hierarchien auf Ihre Roadmap 2027–2028, nicht auf Ihren 2026-Sprint.

3. Symmetrische Verschlüsselung – Niedrige Priorität

AES-256 und SHA-256 werden von Quantencomputern nicht gebrochen. Grovers Algorithmus halbiert ihre effektive Schlüssellänge, weshalb AES-256 seit Jahren die Standardempfehlung ist. Wenn Sie bereits 256-Bit-symmetrische Schlüssel verwenden, erfordert symmetrische Verschlüsselung keine Migration. Wenn Sie aus Performance-Gründen noch auf AES-128 setzen, aktualisieren Sie auf AES-256 – das ist der Umfang der Arbeit hier.

Bibliotheks-Reife Mitte 2026

Das Ökosystem hat sich in allen wichtigen Sprachen auf die finalisierten FIPS-Standards geeinigt:

Go

Das crypto/tls-Paket der Standardbibliothek unterstützt X25519MLKEM768 ab Go 1.24. Für direkte ML-KEM-Operationen außerhalb von TLS enthält golang.org/x/crypto stabile Unterstützung für ML-KEM 768 und 1024. Die API spiegelt bestehende asymmetrische Schlüsselmuster wider: GenerateKey, Encapsulate, Decapsulate mit typisierten Byte-Slices.

Python

pyca/cryptography 44.0.0 (November 2024) hat ML-KEM über sein OpenSSL-3.5-Backend hinzugefügt. Das Interface folgt dem gleichen generate_private_key / exchange-Muster wie bestehende EC-Operationen. Für Umgebungen, in denen Sie die OpenSSL-Version nicht kontrollieren können, bietet pqcrypto eine direkte Bindung an die Referenz-C-Implementierungen.

Rust

Die ml-kem-Crate des RustCrypto-Projekts ist eine reine Rust-Implementierung, no_std-kompatibel und vollständig konform mit FIPS 203. Sie unterstützt ML-KEM-512, -768 und -1024-Varianten und ist die richtige Wahl für Embedded- oder WASM-Ziele, bei denen OpenSSL nicht eingebunden werden kann. Für die Brücke zu Pre-Standard-Kyber-Deployments bleibt pqcrypto-kyber verfügbar.

Java / JVM

BouncyCastle 1.77+ unterstützt ML-KEM und ML-DSA mit einer stabilen API. OpenJDK 24 hat ML-KEM als Preview-API unter JEP 496 eingeführt, GA ist für JDK 25 geplant. Für produktive JVM-Deployments heute ist BouncyCastle der zuverlässige Weg.

Hybrid-PQC in Ihrem Service Mesh aktivieren

Für internen Service-to-Service-mTLS ist Hybrid-PQC ohne Anwendungscode-Änderungen erreichbar. Envoy Proxy 1.32+ unterstützt X25519+ML-KEM-Hybrid, wenn es gegen OpenSSL 3.5 kompiliert wurde. Die Änderung ist eine Service-Mesh-Konfigurationsaktualisierung Ihrer TLSParameters-Cipher-Suite-Liste. Sowohl Istio als auch Linkerd haben dokumentierte Migrationspfade für diese Konfiguration.

Für Edge-TLS verhandeln Cloudflare und AWS CloudFront bereits X25519MLKEM768, wenn der Client es unterstützt. Wenn Sie TLS bei einem CDN oder Load Balancer terminieren, den Sie nicht kontrollieren, prüfen Sie das Changelog Ihres Anbieters – möglicherweise haben Sie bereits ohne Ihr Wissen teilweisen PQC-Schutz.

Ein konkreter Drei-Jahres-Zeitplan

2026: Prüfen Sie den gesamten Schlüsselaustausch über externe Dienste hinweg. Identifizieren Sie OpenSSL-Versionen im gesamten Unternehmen. Aktivieren Sie X25519MLKEM768 auf HTTPS-Endpunkten (Konfigurationsänderung). Dokumentieren Sie alle RSA- und ECDH-Verwendungen in Nicht-TLS-Kontexten: SSH-Keys, JWTs, interne PKI, jede benutzerdefinierte Schlüsselableitung.

2027: Migrieren Sie Nicht-TLS-Schlüsselaustausch zu ML-KEM. Beginnen Sie mit dem Redesign der internen CA-Hierarchie. Wechseln Sie Code-Signing für neue Artefakt-Releases zu ML-DSA. Evaluieren Sie die SSH-Schlüsselmigration (OpenSSH 9.x unterstützt ML-KEM-basierten Hybrid-KEX).

2028–2030: Schließen Sie die Signaturmigration ab. Entfernen Sie RSA aus aller neuen Infrastruktur. Erreichen Sie Konformität mit NIST SP 800-131C sowie geltenden regulatorischen Anforderungen (HIPAA-Richtlinien, PCI-DSS 5.0 PQC-Bestimmungen, technische Standards der EU Cyber Resilience Act).

Umsetzbare Erkenntnisse

• Aktivieren Sie heute X25519MLKEM768 in TLS 1.3 auf öffentlichen Endpunkten – dies ist eine Konfigurationsänderung mit vernachlässigbarem Performance-Overhead auf moderner Hardware und schützt sofort vor HNDL.
• Upgraden Sie auf OpenSSL 3.5+ oder BouncyCastle 1.77+, bevor Sie neuen kryptografischen Code schreiben; diese enthalten die finalisierten FIPS 203-, 204- und 205-Implementierungen.
• Prüfen Sie Ihre RSA- und ECDH-Oberfläche über TLS, SSH, JWT-Signing, interne PKI und jeden benutzerdefinierten Schlüsselaustausch hinweg – Schlüsselaustausch hat höchste Priorität, Signaturen mittlere, symmetrisch zuletzt.
• Verwenden Sie den Hybrid-Modus (klassisch + PQC gleichzeitig) als Migrationspfad, nicht einen harten Wechsel zu reinem PQC; dies entspricht dem, was Google, Cloudflare, AWS und Apple bereitgestellt haben.
• Wenn Sie mit Daten umgehen, die eine Vertraulichkeitsanforderung von 10+ Jahren haben, behandeln Sie HNDL als aktuelle aktive Bedrohung und setzen Sie die PQC-Schlüsselaustauschmigration auf Ihre 2026-Engineering-Roadmap, nicht auf 2028.