PQC StatusHarvest now, decrypt later (HNDL) ist ein geduldiger Angriff: Verschlüsselter Datenverkehr wird heute mitgeschnitten, gespeichert und Jahre später entschlüsselt, sobald die Schlüsselvereinbarung, die ihn geschützt hat, nicht mehr standhält. Dafür ist heute kein Quantencomputer nötig, sondern nur die Fähigkeit zum Mitschneiden und Speicherplatz. Die nützliche Frage für ein Sicherheitsteam lautet daher nicht, wann ein kryptografisch relevanter Quantencomputer existieren wird, sondern wie lange jeder Datenfluss vertraulich bleiben muss und welche Systeme die Datenflüsse mit der längsten Lebensdauer transportieren.
Das Bedrohungsmodell, präzise formuliert
Zerlegen Sie den Angreifer in zwei Fähigkeiten, die zeitlich voneinander getrennt sind.
- Heute: Sammeln. Passiver Mitschnitt an einem Netzwerk-Tap, bei einem vorgelagerten Transitprovider, an einem Peering-Punkt, auf einem kompromittierten Load Balancer oder einer Middlebox oder durch den Diebstahl eines Archivs bereits aufgezeichneter Sitzungen. Der Chiffretext wird gespeichert, nicht gelesen.
- Später: Berechnen. Rekonstruktion eines privaten Schlüssels aus einem öffentlichen Schlüssel. Der Shor-Algorithmus bricht auf einem ausreichend großen Quantencomputer RSA, ECDH, Diffie-Hellman über endlichen Körpern, ECDSA, EdDSA und DSA, unabhängig von der Schlüssellänge. Der Wechsel von RSA-2048 zu RSA-4096 oder von einer elliptischen Kurve zu einer größeren ändert daran nichts.
Symmetrische Kryptografie verhält sich anders. AES, SHA-2 und SHA-3 werden durch Shor nicht gebrochen. Der Grover-Algorithmus bietet gegenüber symmetrischen Schlüsseln einen kleineren, quadratischen Vorteil, und deshalb wird AES-256 bevorzugt, wenn Daten lange vertraulich bleiben müssen. Eine aufgezeichnete Sitzung ist nicht deshalb gefährdet, weil AES-GCM die Nutzdaten geschützt hat. Sie ist gefährdet wegen der Art, wie der AES-Schlüssel vereinbart wurde.
Forward Secrecy löst dieses Problem nicht
TLS 1.3 verwendet stets eine ephemere Schlüsselvereinbarung, in der Praxis ECDH über X25519 oder eine NIST-Kurve. Forward Secrecy bedeutet, dass der Diebstahl des langfristigen privaten Serverschlüssels morgen die Sitzungen von gestern nicht offenlegt, weil das Sitzungsgeheimnis aus ephemeren Schlüsselanteilen stammt. Diese ephemeren öffentlichen Anteile werden jedoch im Klartext innerhalb des Handshakes übertragen. Ein aufgezeichneter Handshake enthält daher alles, was nötig ist, um das Sitzungsgeheimnis zu rekonstruieren, und zwar für jeden, der diese eine Instanz der Schlüsselvereinbarung lösen kann. Forward Secrecy schützt vor Schlüsseldiebstahl. Sie schützt nicht vor einer späteren Kryptanalyse der Schlüsselvereinbarung selbst. Genau diese Lücke ist das gesamte HNDL-Problem.
Warum der Schlüsselaustausch zuerst migriert wird und Signaturen später
Eine Signatur wird im Moment des Verbindungsaufbaus geprüft. Wird ein Signaturalgorithmus in zehn Jahren fälschbar, kann dadurch niemand eine heute aufgezeichnete Sitzung lesen: Die Sitzungsschlüssel wurden nie aus dem Zertifikat abgeleitet. Eine gebrochene Signatur ermöglicht künftige Identitätsvortäuschung sowie gefälschte Artefakte, denen lange vertraut wird.
Daraus ergibt sich die Reihenfolge, der alle offiziellen Roadmaps folgen. Zuerst kommt die hybride Post-Quanten-Schlüsselvereinbarung auf Basis von ML-KEM, dem Schlüsselkapselungsmechanismus (KEM), der am 13. August 2024 als NIST FIPS 203 standardisiert wurde (FIPS 203). Post-Quanten-Signaturen wie ML-DSA (FIPS 204) folgen für Zertifikatsketten. Die hybriden TLS-Gruppen X25519MLKEM768, SecP256r1MLKEM768 und SecP384r1MLKEM1024 sind im IANA-Register der TLS-Parameter eingetragen, und RFC 10024 (August 2026) spezifiziert die hybride Post-Quanten/klassische (PQ/T) Schlüsselvereinbarung für TLS 1.3. Aktuelle Versionen von Chrome, Edge und Firefox bieten X25519MLKEM768 standardmäßig an, sodass dies für viele öffentliche Endpunkte eine Konfigurationsänderung ist und kein Projekt.
Später heißt nicht nie, und zwei Klassen von Signaturen verdienen trotzdem frühzeitig Aufmerksamkeit:
- Signaturen, deren Prüfung auch nach langer Zeit noch vertrauenswürdig sein muss: Signierung von Firmware- und Software-Updates, Vertrauensanker für Secure Boot, Archiv- und Dokumentsignaturen, Zeitstempel.
- Zertifikate und Anmeldedaten mit langer Gültigkeit, deren Neuausstellung teuer oder physisch umständlich ist: eingebettete Produkte, Industrieanlagen, Smartcards.
NSA CNSA 2.0, das für die US National Security Systems gilt, spiegelt diese Aufteilung wider. Es sieht die ausschließliche Verwendung von ML-KEM-1024 und ML-DSA-87 bis Ende 2030 für die Signierung von Software und Firmware sowie für klassische Netzwerkausrüstung vor, und bis Ende 2033 für Webbrowser und Server, Cloud-Dienste und Betriebssysteme.
Welche Daten eine ausreichend lange Vertraulichkeitsdauer haben, um relevant zu sein
Die Vertraulichkeitsdauer ist der Zeitraum, in dem eine Offenlegung noch Schaden verursachen würde. Sie ist eine geschäftliche und rechtliche Eigenschaft der Daten, keine Eigenschaft des Protokolls, und sie ist die einzige Eingangsgröße der HNDL-Priorisierung, die Sie vollständig kontrollieren. Für den Anfang genügen Größenordnungen.
| Datenkategorie | Warum die Lebensdauer lang oder kurz ist | Größenordnung |
|---|---|---|
| Gesundheits-, Genom- und biometrische Daten | Identifizieren eine Person lebenslang und können nicht neu ausgestellt werden | Jahrzehnte |
| Material aus Verwaltung, Verteidigung und Diplomatie | Einstufungsfristen werden durch Vorgaben festgelegt, nicht durch Technologie | Jahrzehnte |
| Geschäftsgeheimnisse, Rezepturen, Konstruktionen, Quellcode | Der Wert folgt der Lebensdauer der Produktlinie | Jahre bis Jahrzehnte |
| Anwaltsgeheimnis, Prozessakten, Unterlagen zu Vorstand und Transaktionen | Bleiben lange nach Abschluss des Geschäfts oder des Verfahrens sensibel | Jahre bis Jahrzehnte |
| Anmeldedaten und Schlüsselmaterial während der Übertragung | Übernehmen die Lebensdauer dessen, was sie freischalten | Jahre |
| Personenbezogene Daten mit Aufbewahrungspflichten | Der Schaden besteht fort, solange die Datensätze existieren | Jahre |
| Echtzeitpreise, kurzlebige Sitzungstoken, betriebliche Telemetrie | Der Wert verfällt nach dem Mitschnitt schnell | Tage bis Monate |
Zwei Korrekturen, die die meisten Inventare benötigen. Erstens übernehmen kurzlebige Daten in einem langlebigen Tunnel die Lebensdauer des Tunnels: Eine Standortverbindung, über die auch Datenbankreplikation läuft, hat die Lebensdauer der Datenbank. Zweitens haben übertragene Geheimnisse die Lebensdauer der Systeme, die sie öffnen, nicht die Lebensdauer der Anfrage, die sie transportiert hat.
Wie Sie Systeme nach der Haltbarkeit ihrer Daten priorisieren
Notieren Sie für jedes System zwei Zahlen. X ist die Vertraulichkeitsdauer der Daten, die es transportiert. Y ist die Zeit, die eine Migration dieses Systems realistischerweise dauern würde, einschließlich Client-Kompatibilität, Appliance-Firmware und Änderungsfenstern. Es gibt eine dritte Größe, den Zeitpunkt, ab dem die betreffende Berechnung machbar wird, und niemand kann dafür ein glaubwürdiges Datum nennen; behandeln Sie sie daher als unbekannt. Die handhabbare Regel ist, was übrig bleibt: Verkürzen Sie Y, und setzen Sie die Arbeit zuerst dort ein, wo X am größten ist, denn bereits aufgezeichneter Datenverkehr lässt sich nicht zurückholen.
| Stufe | Kriterien | Maßnahme |
|---|---|---|
| Jetzt umstellen | Vertraulichkeitsdauer über etwa zehn Jahre, oder der Datenfluss transportiert Schlüssel und Anmeldedaten, oder er durchquert Netze, die Sie nicht kontrollieren | Hybride ML-KEM-Schlüsselvereinbarung auf der Transportebene aktivieren, ausschließlich TLS 1.3 bevorzugen, AES-256 bevorzugen, wo der Stack es zulässt |
| Als Nächstes planen | Lebensdauer von einigen Jahren, interner Datenverkehr, der dennoch Netze von Providern oder Partnern durchläuft | Die Änderung an das nächste Plattform- oder Appliance-Upgrade koppeln, hybride Gruppen aktivieren, sobald die Clients sie unterstützen |
| Der Plattform folgen | Lebensdauer unter einem Jahr, keine Geheimnisse oder langlebigen Kennungen | Die Standardeinstellungen von Betriebssystem, Bibliothek und Browser übernehmen |
Diese Priorisierung braucht ein Inventar als Grundlage. Anforderung 12.3.3 von PCI DSS v4.0.1, seit dem 31. März 2025 verbindlich, verlangt bereits ein dokumentiertes Inventar der verwendeten Cipher Suites und Protokolle, das mindestens alle 12 Monate überprüft wird, einschließlich einer Überwachung ihrer fortbestehenden Eignung. Die technischen Regulierungsstandards zu DORA, die Delegierte Verordnung (EU) 2024/1774 der Kommission, verlangen in Artikel 6 eine Verschlüsselungsrichtlinie mit Bestimmungen zur Aktualisierung oder Änderung kryptografischer Technologie auf Grundlage von Entwicklungen in der Kryptanalyse, und in Artikel 7 ein Schlüsselmanagement über den gesamten Lebenszyklus sowie ein Register der Zertifikate für Assets, die kritische oder wichtige Funktionen unterstützen. NIS2 Artikel 21(2)(h) verlangt Konzepte für den Einsatz von Kryptografie. Keiner dieser Texte nennt eine Spalte zur Datenhaltbarkeit: Eine solche Spalte in das bereits gepflegte Inventar aufzunehmen, ist unsere Auslegung eines praktischen Wegs, die Priorisierung nachzuweisen, und keine wörtliche Anforderung. Dieser Artikel dient der Information und stellt keine Rechtsberatung dar.
Was die offiziellen Zeitpläne gemeinsam haben
Die veröffentlichten Zeitpläne unterscheiden sich in Status und Wortlaut, und die Einschränkungen sind wichtig. Die EU Coordinated Implementation Roadmap v1.1 (veröffentlicht am 23. Juni 2025) ist eine koordinierte Leitlinie für die Mitgliedstaaten, keine für Unternehmen verbindliche Verordnung: erste Schritte einschließlich eines kryptografischen Inventars und nationaler Roadmaps bis Ende 2026, Migration der Anwendungsfälle mit hohem Risiko bis Ende 2030, mit mittlerem Risiko bis Ende 2035. Die Leitlinien des britischen NCSC sehen Bestandsaufnahme und einen ersten Plan bis 2028 vor, die Migrationen mit höchster Priorität bis 2031 und den Abschluss bis 2035. BSI TR-02102-1 (Version 2026-01) ist eine Technische Richtlinie: Sie empfiehlt hybride Schlüsselvereinbarung und hält eine allein eingesetzte klassische Schlüsselvereinbarung nur bis Ende 2031 für akzeptabel, bei sehr hohem Schutzbedarf bis Ende 2030. NIST IR 8547 ist weiterhin ein erster öffentlicher Entwurf (Initial Public Draft); er schlägt vor, quantenanfällige Algorithmen mit 112-Bit-Sicherheit nach 2030 als veraltet einzustufen und quantenanfällige Public-Key-Algorithmen nach 2035 nicht mehr zuzulassen. Die ANSSI schreibt die Hybridisierung innerhalb ihres regulierten Geltungsbereichs vor und stellt klar, dass ihre Post-Quanten-Empfehlungen anderswo noch keine regulatorischen Pflichten sind. Unsere Seite zu den Fristen der Post-Quanten-Migration bündelt die datierten Details an einem Ort.
Die gemeinsame Struktur ist aussagekräftiger als jedes einzelne Datum: eine Gruppe mit höchster Priorität um 2030 bis 2031, der Rest bis 2035, und ein Auswahlkriterium für die erste Gruppe, das im Wesentlichen die lange Lebensdauer der Daten ist. Das ist das HNDL-Argument, festgeschrieben in öffentlicher Politik.
Prüfen Sie, was Ihre Handshakes tatsächlich aushandeln
Messen Sie, bevor Sie planen. Fordern Sie mit OpenSSL 3.5 oder neuer, der Mindestversion mit den ML-KEM-TLS-Gruppen, ausdrücklich eine hybride Gruppe an und lesen Sie aus, was ausgehandelt wurde:
openssl s_client -connect example.com:443 -tls1_3 \
-groups X25519MLKEM768 </dev/null 2>&1 | grep -i groupPrüfen Sie für den administrativen Zugang die Schlüsselvereinbarung einer SSH-Sitzung. OpenSSH 9.9 (19. September 2024) hat mlkem768x25519-sha256 eingeführt, OpenSSH 10.0 (9. April 2025) hat es zur Standard-Schlüsselvereinbarung gemacht, und OpenSSH 10.1 (6. Oktober 2025) warnt über WarnWeakCrypto, standardmäßig aktiviert, wenn eine Verbindung eine Schlüsselvereinbarung ohne Post-Quanten-Schutz aushandelt. Die Release Notes sind auf openssh.com veröffentlicht.
ssh -v -o KexAlgorithms=mlkem768x25519-sha256 user@host 2>&1 | grep -i kexSetzen Sie die hybride Gruppe an die erste Stelle und behalten Sie dahinter einen klassischen Fallback bei, zum Beispiel X25519MLKEM768 und danach X25519, damit ältere Clients weiterhin eine Verbindung herstellen können. Testen Sie in einer Staging-Umgebung vor der Produktion und achten Sie auf die Handshake-Größen bei Verbindungen mit begrenzter Bandbreite und bei Appliances, die den ClientHello inspizieren.
Ihr nächster Schritt
Beginnen Sie mit den beiden Artefakten, die den Rest zu einer mechanischen Aufgabe machen: einer Spalte zur Datenhaltbarkeit in Ihrem kryptografischen Inventar und einer Messung dessen, was Ihre externen Endpunkte heute aushandeln. Für Letzteres können Sie Ihre Domain kostenlos mit PQC Status scannen: Der Scan meldet die angebotenen hybriden ML-KEM-Gruppen, die TLS-Versionen und Cipher Suites sowie die Zertifikatskette. Ein Scan beschreibt nur die von außen sichtbare TLS-Konfiguration; behandeln Sie ihn daher als Nachweis für Ihr Inventar, nicht als Zertifizierung oder Compliance-Bestätigung. Nehmen Sie sich dann die Systeme Ihrer Stufe Jetzt umstellen vor und stellen Sie sie in dieser Reihenfolge auf hybride Schlüsselvereinbarung um.