Post-Quanten-Kryptografie

Ein Quantencomputer rechnet mit Qubits, die gleichzeitig eine Kombination aus 0 und 1 halten und so verschränkt werden können, dass ihre Zustände voneinander abhängen. Bei den meisten Aufgaben ist er nicht schneller als ein gewöhnlicher Computer. Bei einigen Problemen mit passender mathematischer Struktur sorgt ein Quantenalgorithmus dafür, dass sich falsche Antworten gegenseitig auslöschen und die richtige hervortritt, und das ergibt einen enormen Geschwindigkeitsvorteil. Heutige Geräte haben zu wenige Qubits und zu viele Fehler, um Verschlüsselung zu gefährden. Dafür bräuchte es eine große, fehlertolerante Maschine, die ihre eigenen Fehler korrigiert, und die hat noch niemand gebaut. Für Ihr Unternehmen ist der praktische Punkt eng gefasst: Eine solche Maschine würde die Public-Key-Kryptografie brechen, die fast jede Ihrer Verbindungen schützt, deshalb muss der Ersatz geplant werden, bevor es sie gibt.

Weil ein großer, fehlertoleranter Quantencomputer mit Shors Algorithmus die Public-Key-Verfahren brechen könnte, mit denen heute Schlüssel ausgehandelt und Daten signiert werden: RSA und Elliptische-Kurven-Kryptografie (ECC). Diese beiden schützen den Schlüsselaustausch fast jeder HTTPS-, VPN- und SSH-Verbindung sowie die Signaturen auf Zertifikaten, Software-Updates und Dokumenten. Ein Angreifer mit einer solchen Maschine könnte früher aufgezeichneten Verkehr lesen und Signaturen fälschen. Symmetrische Verschlüsselung wie AES, die die Daten nach dem Schlüsselaustausch verschlüsselt, schwächt Grovers Algorithmus nur moderat; mit 256-Bit-Schlüsseln bleibt sie nutzbar. Einen solchen Computer gibt es heute nicht, und niemand kann das Jahr nennen, in dem es ihn geben wird. Das Risiko ist real für Daten, die viele Jahre geheim bleiben müssen, und es ist zu planen, kein Notfall. Die Lösung ist Software, nicht Hardware: neue Algorithmen, 2024 vom NIST standardisiert und per Update verteilt.

Er macht aus den schweren Problemen, auf denen sie beruhen, leichte. RSA ist sicher, weil niemand eine sehr große Zahl in vertretbarer Zeit in ihre zwei Primfaktoren zerlegen kann; Elliptische-Kurven-Kryptografie ist sicher, weil niemand die geheime Zahl hinter einem öffentlichen Punkt auf der Kurve ermitteln kann. Peter Shor zeigte 1994, dass ein Quantencomputer in beiden Problemen ein verborgenes, sich wiederholendes Muster findet, eine Periode, und aus dieser Periode folgt das Geheimnis schnell. Auf einer ausreichend großen Maschine braucht der Angriff eine praktikable statt einer unmöglichen Zeit. Längere Schlüssel retten RSA und ECC nicht: Sie verlangsamen den Quantenangriff nur etwas. Deshalb ist die Antwort neue Mathematik, etwa die Gitterprobleme hinter ML-KEM und ML-DSA, für die kein effizienter Quantenalgorithmus bekannt ist. Veröffentlichte Schätzungen der nötigen Maschine liegen noch weit jenseits von allem, was bisher gebaut wurde.

Viel weniger als Shors Algorithmus für RSA: Er schwächt symmetrische Verschlüsselung und Hashfunktionen, bricht sie aber nicht. Lov Grover zeigte 1996, dass ein Quantencomputer Möglichkeiten in etwa der Quadratwurzel der üblichen Schrittzahl durchsuchen kann. Beim Erraten eines Schlüssels halbiert das ungefähr die Schlüssellänge in Bit: Theoretisch verhält sich ein 128-Bit-AES-Schlüssel eher wie einer mit 64 Bit. In der Praxis ist der Angriff eine sehr lange Kette von Schritten, die sich nicht sinnvoll auf viele Maschinen verteilen lässt, sodass selbst AES-128 weit davon entfernt bleibt, leicht zu brechen zu sein. Der übliche Rat ist einfach: AES-256 für Daten, die lange geheim bleiben müssen, und SHA-256 oder stärker zum Hashen. Die meisten modernen Systeme unterstützen beides bereits, daher ist dieser Teil der Umstellung meist eine Konfigurationsfrage und kein Migrationsprojekt. Die eigentliche Arbeit liegt bei den Public-Key-Verfahren.

Das weiß niemand, und wer ein Jahr nennt, rät. Eine Maschine, die groß und stabil genug ist, um Shors Algorithmus gegen heutige Schlüssellängen auszuführen, braucht Fortschritte bei Qubit-Qualität, Fehlerkorrektur und Größe, die noch nicht demonstriert wurden. Expertenbefragungen und Hersteller-Roadmaps nennen Spannen, keine Daten, und die Spannen verschieben sich. Ihre Planung hängt von diesem Datum aber nicht ab. Regulierer haben eigene Fristen gesetzt: Der koordinierte EU-Fahrplan vom 23. Juni 2025 verlangt, Anwendungsfälle mit hohem Risiko bis Ende 2030 umzustellen, und die Übergangsleitlinie des NIST (NIST IR 8547, Entwurf November 2024, endgültige Fassung Oktober 2026) kündigt quantenanfällige Public-Key-Verfahren wie RSA und Elliptische-Kurven-Kryptografie nach 2030 ab und untersagt sie in NIST-Standards nach 2035. Kunden, Prüfer und Ausschreibungen werden nach diesen Daten fragen, lange bevor es einen Quantencomputer gibt. Für Daten, die ein Jahrzehnt oder länger geheim bleiben müssen, zeigt die Mosca-Ungleichung, warum Warten auf das Datum die falsche Strategie ist.

Post-Quanten-Kryptografie (PQC) ist Public-Key-Kryptografie, die auch gegen einen großen Quantencomputer sicher bleiben soll und dabei auf gewöhnlichen Computern läuft. Das NIST hat am 13. August 2024 die ersten Standards veröffentlicht: FIPS 203 (ML-KEM) für den Schlüsselaustausch sowie FIPS 204 (ML-DSA) und FIPS 205 (SLH-DSA) für digitale Signaturen. Sie beruhen auf mathematischen Problemen wie dem Finden kurzer Vektoren in hochdimensionalen Gittern oder auf der Sicherheit von Hashfunktionen, für die kein effizienter Quantenangriff bekannt ist. Migration heißt, Software, Bibliotheken, Protokolle und Zertifikate zu aktualisieren, nicht Quantenhardware zu kaufen. Sie ist auch nicht dasselbe wie Quantenschlüsselverteilung, die spezielle optische Geräte braucht. Der Preis ist die Größe: Post-Quanten-Schlüssel und -Signaturen sind größer als heutige, Handshakes wachsen, und manche ältere Geräte kommen damit nicht zurecht. Die meisten Organisationen begegnen PQC zuerst über Updates von Browsern, Betriebssystemen und VPN-Software und müssen sich danach um ihre eigenen Server und Anwendungen kümmern.

Es sind die ersten drei Post-Quanten-Standards des US-amerikanischen National Institute of Standards and Technology (NIST), veröffentlicht am 13. August 2024 nach einem offenen, internationalen Wettbewerb, der 2016 begann. FIPS 203 beschreibt ML-KEM, einen Schlüsselkapselungsmechanismus, mit dem sich zwei Parteien auf einen gemeinsamen geheimen Schlüssel einigen; er übernimmt die Rolle, die RSA und Diffie-Hellman auf elliptischen Kurven heute beim Schlüsselaustausch spielen. FIPS 204 beschreibt ML-DSA, das wichtigste Signaturverfahren. FIPS 205 beschreibt SLH-DSA, ein langsameres Signaturverfahren mit größeren Signaturen, das nur auf Hashfunktionen beruht und als konservative Alternative dient. Obwohl es US-Bundesstandards sind, gelten sie weltweit als Referenz: Europäische Behörden wie das BSI und die französische ANSSI empfehlen unter anderem diese Algorithmen, meist kombiniert mit einem klassischen Verfahren. Für Sie sind es die Namen, nach denen Sie in Herstellerdokumentation, Produkt-Roadmaps und Angebotsantworten suchen sollten.

ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism, FIPS 203) ist das Post-Quanten-Verfahren, um über ein offenes Netz einen geheimen Schlüssel zu vereinbaren, und das, dem Sie zuerst begegnen werden. Es ist aus der Einreichung CRYSTALS-Kyber hervorgegangen. Eine Seite veröffentlicht einen öffentlichen Schlüssel; die andere verpackt damit ein frisches Zufallsgeheimnis, das nur der Inhaber des privaten Schlüssels wieder auspacken kann. Dieses Geheimnis dient dann als Schlüssel für schnelle symmetrische Verschlüsselung wie AES. Es gibt drei Größen, ML-KEM-512, ML-KEM-768 und ML-KEM-1024, wobei 768 der übliche Standard ist. Es ist schnell, oft vergleichbar mit elliptischen Kurven, aber öffentlicher Schlüssel und Chiffretext sind jeweils rund ein Kilobyte groß, gegenüber 32 Byte bei X25519. Diese Größe ist der Grund, warum manche alte Firewalls und Middleboxes mit Post-Quanten-Handshakes Probleme haben. In TLS erscheint ML-KEM meist kombiniert mit X25519 als hybride Gruppe X25519MLKEM768, die die meisten Browser bereits anbieten.

Es sind die beiden Post-Quanten-Signaturstandards: ML-DSA (FIPS 204, aus CRYSTALS-Dilithium) und SLH-DSA (FIPS 205, aus SPHINCS+). Eine digitale Signatur belegt, wer Daten erzeugt hat und dass niemand sie verändert hat; sie schützt Zertifikate, Software-Updates, Firmware, Dokumente und Code. ML-DSA ist die Wahl für den allgemeinen Einsatz: schnell, mit Signaturen von einigen Kilobyte statt der 64 Byte einer typischen ECDSA-Signatur. SLH-DSA beruht nur auf der Sicherheit von Hashfunktionen und ist damit sehr konservativ, um den Preis größerer Signaturen und langsameren Signierens; es passt zu langlebigen Vertrauensankern und zum Signieren von Firmware. Für „Harvest now, decrypt later“ spielen Signaturen eine kleinere Rolle, denn eine gefälschte Signatur hilft einem Angreifer erst, wenn es einen Quantencomputer gibt. Deshalb stellen die meisten Organisationen zuerst den Schlüsselaustausch um und die Signaturen später. Das Zertifikats-Ökosystem für Post-Quanten-Signaturen entsteht noch; fragen Sie Ihre Lieferanten nach ihren Plänen, statt heute schon Post-Quanten-Zertifikate zu erwarten.

Es sind die nächsten Post-Quanten-Algorithmen auf dem Weg des NIST, noch keine endgültigen Standards. HQC (Hamming Quasi-Cyclic) ist ein Schlüsselkapselungsverfahren, das das NIST im März 2025 als Reserve für ML-KEM ausgewählt hat. Es beruht auf fehlerkorrigierenden Codes statt auf Gittern; sollte je eine Schwäche in Gitterproblemen gefunden werden, stünde ein Algorithmus aus einer anderen mathematischen Familie bereit. Das NIST kündigte damals einen Standardentwurf etwa ein Jahr später und einen endgültigen Standard für 2027 an. FN-DSA, basierend auf der Einreichung FALCON, ist ein Signaturverfahren, das als FIPS 206 geplant ist; seine Signaturen sind viel kleiner als die von ML-DSA, was bei knappem Platz hilft, es ist aber schwerer sicher zu implementieren. Die Lehre für Ihre Planung: Setzen Sie nicht für immer auf einen Algorithmus. Wählen Sie Produkte, die Algorithmen per Konfiguration oder Update austauschen können. Diese Fähigkeit, Krypto-Agilität genannt, schützt Sie, wenn sich ein Standard ändert oder ein Implementierungsfehler auftaucht.

Hybrider Schlüsselaustausch kombiniert im selben TLS-Handshake ein klassisches Verfahren (X25519, ein Austausch auf elliptischen Kurven) mit einem Post-Quanten-Verfahren (ML-KEM-768) und leitet den Sitzungsschlüssel aus beiden ab. Der Schlüssel bleibt geheim, solange eines der beiden hält: Würde im noch jungen ML-KEM ein Fehler gefunden, hielte X25519 heutige Angreifer weiter draußen; gegen einen künftigen Quantencomputer täte es ML-KEM. Deshalb bevorzugen die meisten Leitlinien, auch die europäischer Behörden wie BSI und ANSSI, für die Übergangszeit hybride Verfahren. X25519MLKEM768 ist der Name dieser Kombination in TLS. Große Browser bieten sie bereits standardmäßig an, und große Content-Delivery-Netze sowie viele Cloud-Dienste akzeptieren sie, sodass ein Teil Ihres Webverkehrs sie womöglich schon nutzt, ohne dass Sie etwas geändert haben. Eine Verbindung, die sie nutzt, macht aufgezeichneten Verkehr später weit schwerer zu entschlüsseln. Zu planen sind die Verbindungen, die noch ausschließlich klassischen Schlüsselaustausch nutzen: ältere Server, Appliances, VPNs und interne Anwendungen.

Für fast jedes Unternehmen nicht. Quantenschlüsselverteilung (QKD) nutzt die Physik einzelner Photonen, die über eigene Glasfasern oder Freistrahlstrecken gesendet werden, um einen Schlüssel so zu vereinbaren, dass Abhören auffällt. Sie braucht Spezialhardware an beiden Enden, funktioniert nur über begrenzte Entfernungen, sofern keine vertrauenswürdigen Zwischenstationen eingefügt werden, und authentisiert die beiden Seiten nicht von selbst, braucht also weiterhin klassische oder Post-Quanten-Signaturen. Post-Quanten-Kryptografie ist dagegen Software, die auf den Netzen und Geräten läuft, die Sie schon haben. Europäische Sicherheitsbehörden, darunter das BSI, die französische ANSSI und die niederländische NLNCSA, haben eine gemeinsame Position veröffentlicht, die Post-Quanten-Kryptografie als Hauptweg und QKD allenfalls für Nischenanwendungen sieht. Die europäische Quantenkommunikationsinfrastruktur EuroQCI dient bestimmten staatlichen Zwecken und ist eine andere Frage als das, was ein mittelständisches Unternehmen kaufen sollte. Bietet ein Anbieter QKD als Antwort auf „Harvest now, decrypt later“ für ein gewöhnliches Büronetz an, fragen Sie, was sie leistet, das eine hybride TLS- oder VPN-Konfiguration nicht leistet.

Ein Angreifer zeichnet heute verschlüsselten Verkehr auf und speichert ihn, um ihn zu entschlüsseln, sobald ein leistungsfähiger Quantencomputer existiert. Das Aufzeichnen ist billig und für Sie unsichtbar: Es kann an einem Internetknoten, auf einem kompromittierten Router oder bei einem Provider geschehen, weit weg von Ihrem Netz. Gefährdet ist nur Verkehr, dessen Schlüsselaustausch quantenanfällig ist, und nur Daten, die beim Entschlüsseln noch zählen. Gesundheitsdaten, Konstruktionen, Quellcode, langfristige Verträge, Rechtsakten und personenbezogene Daten mit langer Aufbewahrung sind typische Beispiele; der Lieferplan dieser Woche ist es nicht. Abwägen lässt es sich mit der Mosca-Ungleichung: Sind die Jahre, die Daten geheim bleiben müssen, plus die Jahre Ihrer Migration mehr als die Jahre bis zu einem solchen Computer, ist jetzt der Zeitpunkt, anzufangen. Die praktische Antwort lautet, zuerst den Schlüsselaustausch, der langlebige Daten schützt, auf hybride Post-Quanten-Verfahren umzustellen, denn dort würden heutige Aufzeichnungen zu den Lecks von morgen. Signaturen können später folgen.

Daten, die heute über ein Netz laufen und auch nach dem Erscheinen eines großen Quantencomputers vertraulich bleiben müssen. Stellen Sie zu jedem Datenbestand zwei Fragen: Läuft er über eine Verbindung mit quantenanfälligem Schlüsselaustausch, und wie viele Jahre würde seine Offenlegung noch schaden? Typische langlebige Beispiele sind Patienten- und Personalakten, Produktkonstruktionen und Quellcode, Unterlagen zu Übernahmen und Rechtsfällen, Verträge mit öffentlichen Auftraggebern, biometrische Daten und Zugangsdaten, die nie gewechselt werden. Kurzlebige Daten wie ein Einmalcode oder die Preise dieses Monats sind keine Sorge wert. Gespeicherte Daten sind eine andere Frage: Sie schützt meist symmetrische Verschlüsselung wie AES, die ein Quantencomputer nicht bricht, es sei denn, ihre Schlüssel werden mit RSA ausgetauscht oder verpackt. Schreiben Sie die Liste mit einem Verantwortlichen und einer Aufbewahrungsdauer je Eintrag auf: Sie wird zur Prioritätenfolge Ihrer Migration und zur Grundlage der Mosca-Rechnung. Ein Netzwerksensor kann Ihre Daten nicht klassifizieren; diese Liste kommt aus dem Geschäft.

Stellen Sie für jeden wichtigen Datenbestand oder jedes wichtige System drei Zahlen nebeneinander. X ist, wie viele Jahre die Daten geheim bleiben müssen. Y ist, wie viele Jahre Sie brauchen, um dieses System auf Post-Quanten-Kryptografie umzustellen, einschließlich Lieferanten, Tests und Budgetzyklen. Z ist, wie viele Jahre bleiben, bis ein Quantencomputer die heutige Public-Key-Kryptografie brechen kann. Ist X plus Y größer als Z, sind heute gesendete Daten bereits „Harvest now, decrypt later“ ausgesetzt. Michele Mosca hat die Ungleichung 2015 beschrieben, in einem als IACR ePrint 2015/1075 veröffentlichten Beitrag. Z ist unbekannt, also tun Sie nicht so, als kennten Sie es: Probieren Sie einen vorsichtigen und einen entspannten Wert und sehen Sie, welche Systeme selbst beim entspannten durchfallen. Beispiel: Verträge, die 10 Jahre vertraulich bleiben müssen, auf einem System, dessen Migration 5 Jahre dauert, fallen bei jedem Z unter 15 Jahren durch. Das Ergebnis ist eine Prioritätenliste, keine Prognose, und eine Begründung, der ein Prüfer oder die Geschäftsleitung folgen kann.

Die Bedrohung ist kein Hype, viel vom Marketing darum herum schon. Die Fakten sind belastbar: Das NIST hat im August 2024 endgültige Standards veröffentlicht, Browser und große Cloud-Anbieter nutzen bereits hybriden Post-Quanten-Schlüsselaustausch, und die EU hat einen koordinierten Fahrplan mit Terminen. Unsicher ist, wann ein leistungsfähiger Quantencomputer existieren wird, und genau deshalb schlägt Planen das Warten: Kryptografie im ganzen Unternehmen umzustellen dauert Jahre. Der Hype steckt in Produkten, die Immunität gegen Quantenangriffe versprechen, in Countdown-Uhren und im Druck, Hardware zu kaufen, die Sie nicht brauchen. Eine nüchterne Haltung für die meisten mittelständischen Unternehmen: keine Notausgaben, aber eine Bestandsaufnahme in diesem Jahr, Post-Quanten-Fragen bei jedem neuen Einkauf, Updates, die hybriden Schlüsselaustausch einschalten, wo Hersteller ihn anbieten, und Vorrang für Daten, die lange geheim bleiben müssen. Das kostet wenig und erspart später eine überstürzte, teure Migration.

Ja, als Planungs- und Risikothema, nicht als Krise. Es gehört aus drei Gründen auf die Tagesordnung der Leitung. Es ist eine lange, unternehmensweite Umstellung, die über mehrere Jahre Lieferanten, Produkte und Budgets berührt, und nur die Leitung kann sie in eine Reihenfolge bringen. Sie betrifft Daten, deren Schutz das Unternehmen für viele Jahre zugesagt hat, etwa Kunden-, Patienten- oder Konstruktionsdaten. Und Kunden, Versicherer und öffentliche Ausschreibungen fangen an, danach zu fragen, die Antwort wird also zur kaufmännischen Frage. Nach NIS2 müssen die Leitungsorgane erfasster Einrichtungen die Risikomanagementmaßnahmen für Cybersicherheit billigen und ihre Umsetzung überwachen, und eine Richtlinie zur Kryptografie ist eine davon. Was die Leitung braucht, ist kurz: eine Bestandsaufnahme, wo quantenanfällige Kryptografie eingesetzt wird, eine Prioritätenliste danach, wie lange Daten geheim bleiben müssen, einen benannten Verantwortlichen und einen Zeitplan entlang der EU-Meilensteine 2030 und 2035. Eine technische Einführung in Qubits braucht sie nicht.

Die Empfehlung (EU) 2024/1101 der Kommission vom 11. April 2024 forderte die Mitgliedstaaten auf, den Übergang zu koordinieren, und die NIS-Kooperationsgruppe hat am 23. Juni 2025 einen koordinierten Fahrplan veröffentlicht: den Übergang beginnen, Anwendungsfälle mit hohem Risiko bis Ende 2030 absichern und so viele Systeme wie möglich bis 2035 umstellen. Es ist ein Fahrplan für die Mitgliedstaaten, kein Gesetz, das Ihr Unternehmen unmittelbar bindet; nationale Behörden können daraus Leitlinien oder Regeln machen. Der erste praktische Schritt ist zu wissen, wo Sie Kryptografie einsetzen.

Dass der Übergang überall begonnen hat. Der koordinierte Fahrplan, den die NIS-Kooperationsgruppe am 23. Juni 2025 im Anschluss an die Empfehlung (EU) 2024/1101 der Kommission veröffentlicht hat, sieht drei Schritte vor: erste Schritte bis Ende 2026, Umstellung der Anwendungsfälle mit hohem Risiko bis Ende 2030 und so viele Systeme wie möglich bis 2035. Der erste Schritt dient der Vorbereitung: Die Mitgliedstaaten legen nationale Übergangspläne fest, Organisationen beginnen mit der Bestandsaufnahme, wo sie quantenanfällige Kryptografie einsetzen, und das Risiko jeder Nutzung wird bewertet, damit Fälle mit hohem Risiko früh erprobt werden können. Der Fahrplan richtet sich an die Mitgliedstaaten und ihre öffentlichen und kritischen Sektoren, nicht unmittelbar an Ihr Unternehmen, und nationale Behörden werden ihn in eigene Leitlinien übersetzen. Seine Logik gilt trotzdem für jede Organisation: Wissen Sie bis Ende 2026, wo Ihre Kryptografie steckt, wem welches System gehört und welche zuerst umgestellt werden müssen. Achten Sie auf Veröffentlichungen Ihrer nationalen Cybersicherheitsbehörde.

Nicht ausdrücklich, aber beide weisen in diese Richtung. NIS2, die Richtlinie (EU) 2022/2555, verlangt von erfassten Einrichtungen Konzepte und Verfahren für den Einsatz von Kryptografie und gegebenenfalls Verschlüsselung, als Teil der Risikomanagementmaßnahmen im Bereich der Cybersicherheit nach Artikel 21. Der Cyber Resilience Act, die Verordnung (EU) 2024/2847, verlangt, dass Produkte mit digitalen Elementen die Vertraulichkeit von Daten mit Mechanismen nach dem Stand der Technik schützen, als Teil der grundlegenden Anforderungen in Anhang I. Keiner nennt einen Algorithmus. Der Stand der Technik bewegt sich aber: Sobald NIST-Standards, Leitlinien europäischer Behörden und der EU-Fahrplan hybriden Post-Quanten-Schlüsselaustausch als normal behandeln, lässt sich ein Produkt oder eine Richtlinie, die ihn ignoriert, in einer Prüfung oder Ausschreibung schwerer verteidigen. Der EU-Fahrplan selbst stellt den Post-Quanten-Übergang als No-Regret-Schritt dar, der NIS2 und den CRA unterstützt. Prüfen Sie die nationale Umsetzung von NIS2 und Leitlinien Ihrer nationalen Behörde, denn die Details können sich von Land zu Land unterscheiden.

Vor allem günstige, gewöhnliche Dinge. Erstens: Halten Sie Browser, Betriebssysteme, VPN-Clients, Server und Bibliotheken aktuell; ein Großteil der Post-Quanten-Umstellung kommt per Update, und moderne Browser nutzen hybriden Schlüsselaustausch bereits standardmäßig. Zweitens: Listen Sie auf, wo Sie Kryptografie einsetzen, die Sie selbst steuern: Ihre Website und deren Hosting, Fernzugriff, E-Mail, Dateiaustausch mit Kunden und jedes Gerät mit eigenen Zertifikaten. Drittens: Markieren Sie die Daten, die viele Jahre geheim bleiben müssen. Viertens: Stellen Sie bei jedem neuen Einkauf und jeder Vertragsverlängerung eine Frage: Unterstützt das Produkt hybriden Post-Quanten-Schlüsselaustausch, und wenn nicht, wann? Fünftens: Bevorzugen Sie Lieferanten, die Algorithmen per Update wechseln können. Spezielle Quantenprodukte zu kaufen, steht nicht auf der Liste. NetSenX kann beim zweiten Schritt helfen: NQCI, in der Preview, ist in jedem Plan sichtbar und ab dem Pro-Plan aktiv und braucht den standardmäßig ausgeschalteten Paketmitschnitt-Sensor, eingeschaltet für einen Linux-Agenten oder als SPAN/TAP-Sensor; der Basismodus unter macOS sieht keine Handshakes.

Für die meisten Organisationen Jahre, und deshalb zählt ein früher Start mehr als das genaue Datum. Die Umstellung betrifft jede Stelle, an der Schlüssel ausgehandelt oder Daten signiert werden: Websites, VPNs, SSH, E-Mail, interne Anwendungen, Zertifikate, Hardware-Sicherheitsmodule (HSM), Smartcards, Maschinen und ihre Firmware. Vieles hängt davon ab, wann Lieferanten Post-Quanten-Unterstützung liefern, und von Ihren eigenen Austauschzyklen: Eine in diesem Jahr gekaufte Firewall läuft vielleicht noch im nächsten Jahrzehnt, eine Industriesteuerung weit länger. Frühere Umstellungen zeigen die Größenordnung: Die Abschaffung von SHA-1 und der alten TLS-Versionen dauerte in der Branche viele Jahre von den ersten Warnungen bis zur endgültigen Abschaltung. Ein kleines Unternehmen, das vor allem Cloud-Dienste und aktuelle Software nutzt, schafft einen großen Teil mit gewöhnlichen Updates innerhalb eines normalen Erneuerungszyklus. Ein Unternehmen mit eigener Software, langlebigen Geräten oder einer eigenen Zertifizierungsstelle sollte mit einem Programm über mehrere Jahre rechnen. Das Y in der Mosca-Ungleichung ist Ihre eigene Schätzung; schreiben Sie sie mit Begründung auf.

Sie schützen den heutigen Verkehr vor der Entschlüsselung von morgen und gewinnen einiges, das gar nicht von Quantencomputern abhängt. Daten mit langer Lebensdauer sind nicht mehr „Harvest now, decrypt later“ ausgesetzt, sobald ihr Schlüsselaustausch auf ein hybrides Verfahren umgestellt ist. Die Bestandsaufnahme, die Sie dabei erstellen, findet alte TLS-Versionen, schwache Chiffren, abgelaufene oder vergessene Zertifikate und nicht verwaltete Server, also Risiken von heute. Krypto-Agilität, die Fähigkeit, Algorithmen per Konfiguration zu wechseln, macht die nächste erzwungene Umstellung billiger, egal was sie auslöst. Kaufmännisch beantworten Sie Fragen aus Ausschreibungen und von Kunden mit Fakten und Terminen statt mit einer Lücke, und Sie sind bereit, wenn nationale Behörden den EU-Fahrplan in Leitlinien übersetzen. Innerhalb normaler Austauschzyklen kostet die Migration weit weniger als eine unter Zeitdruck. Was Sie nicht gewinnen, ist Unverwundbarkeit: Post-Quanten-Kryptografie schützt Schlüsselaustausch und Signaturen, nicht gestohlene Passwörter, Phishing oder ungepatchte Systeme.

Meist Kompatibilität und Leistung, selten die Mathematik. Post-Quanten-Schlüssel sind größer, daher passt ein TLS-ClientHello mit X25519MLKEM768 nicht mehr in ein einzelnes Netzwerkpaket; manche älteren Firewalls, Load Balancer und Intrusion-Prevention-Systeme verarbeiten das falsch und verwerfen oder beenden die Verbindung. Hardware-Sicherheitsmodulen, Smartcards und eingebetteten Geräten fehlen womöglich Speicher oder Firmware für die neuen Algorithmen. Signaturen von mehreren Kilobyte vergrößern Zertifikatsketten und bremsen schmale Verbindungen. Junge Implementierungen können Fehler enthalten, ein Grund mehr für hybride Verfahren und gut gepflegte Bibliotheken. Abfang-Proxys, die TLS entschlüsseln, unterstützen die neuen Gruppen vielleicht nicht und drängen Verbindungen still auf klassischen Schlüsselaustausch zurück. Planen Sie das ein: Testen Sie mit echtem Verkehr in einem Testsegment, behalten Sie während des Übergangs den klassischen Rückfall, prüfen Sie, ob Middleboxes aktualisiert sind, und messen Sie danach, welche Verbindungen tatsächlich hybriden Schlüsselaustausch nutzen. Ein Blick auf die Handshakes im Netz zeigt Rückschritte, die Konfigurationsdateien nicht zeigen.

Krypto-Agilität ist die Fähigkeit, die kryptografischen Algorithmen eines Systems zu wechseln, ohne das System neu zu schreiben oder zu ersetzen. In der Praxis heißt das: Algorithmen werden per Konfiguration gewählt, nicht fest einprogrammiert; Software nutzt gepflegte Bibliotheken, die neue Algorithmen per Update erhalten; Zertifikate und Schlüssel werden zentral verwaltet, mit bekannten Verantwortlichen und Ablaufdaten; und Sie wissen, wo welcher Algorithmus eingesetzt wird. Das zählt jetzt, weil der Post-Quanten-Übergang nicht der letzte sein wird: HQC und FN-DSA kommen erst noch, Parameter können überarbeitet werden, und in einer jungen Implementierung kann ein Fehler auftauchen. Eine Organisation, die eine schmerzhafte, manuelle Migration durchzieht, erlebt beim nächsten Mal denselben Schmerz; eine, die Agilität aufbaut, macht die nächste Änderung zu einem Konfigurations-Release. Fragen Sie bei jedem Einkauf danach: Kann das Produkt seine Algorithmen für Schlüsselaustausch und Signatur per Update oder Einstellung wechseln, und sagt der Hersteller das verbindlich zu? Ein Produkt, das es nicht kann, ist ein Migrationsproblem, das Sie heute kaufen.

Zunehmend ja, aber Sie müssen jedes Produkt prüfen. OpenSSH hat mit Version 9.0 im Jahr 2022 einen hybriden Post-Quanten-Schlüsselaustausch zum Standard gemacht, und Version 10.0 von 2025 hat die auf ML-KEM beruhende Hybridvariante mlkem768x25519-sha256 zum Standard erhoben; laufen auf beiden Seiten aktuelle Versionen, nutzen Ihre SSH-Sitzungen sie wahrscheinlich schon. Bei VPNs ist das Bild gemischt. Der IPsec-Schlüsselaustausch IKEv2 hat mit RFC 9370 einen Standardweg erhalten, zusätzliche Schlüsselaustausche wie ML-KEM einzubinden; manche Hersteller und Open-Source-Projekte unterstützen das, andere haben es nur angekündigt. WireGuard kann einen vorab geteilten symmetrischen Schlüssel als Post-Quanten-Schutzschicht hinzufügen, sein Handshake selbst ist aber klassisch. Prüfen Sie die Versionshinweise der Firmware Ihrer Firewall oder Ihres VPN-Gateways und die tatsächlich genutzten Client-Versionen, und denken Sie daran, dass ein alter Server an einem Ende die ganze Verbindung klassisch hält. Fernzugriffs- und Site-to-Site-VPNs transportieren viele langlebige Daten und gehören deshalb weit nach vorn in Ihre Migrationsreihenfolge.

Beginnen Sie mit einer Bestandsaufnahme: Zertifikate, VPNs, TLS auf Ihren Servern, SSH, Code-Signierung und die Bibliotheken Ihrer Anwendungen. Ein großer Teil zeigt sich im Netzwerkverkehr, weil der Schlüsselaustausch jeder TLS-Verbindung ohne Entschlüsselung sichtbar ist. NQCI, das Krypto-Inventar von NetSenX (in der Preview), ist in jedem Plan sichtbar und ab dem Pro-Plan aktiv: Es zeigt, welche Verbindungen quantenanfälligen Schlüsselaustausch nutzen und welche hybriden Post-Quanten-Schlüsselaustausch. Dafür braucht es den Paketmitschnitt-Sensor, der standardmäßig aus ist: eingeschaltet für einen Linux-Agenten oder als Sensor an einem SPAN- oder TAP-Port. Der Basismodus des Agenten, wie er unter macOS läuft, sieht keine TLS-Handshakes. Es schafft Sichtbarkeit; die Migration selbst bleibt bei Ihnen und Ihren Anbietern.

Einen großen Teil davon ja, aber nicht alles. Jede TLS-Verbindung kündigt, bevor die Verschlüsselung beginnt, an, welche Gruppen für den Schlüsselaustausch der Client anbietet und welche der Server wählt, dazu die TLS-Version; SSH funktioniert ähnlich. Ein Sensor, der diese Handshakes sieht, kann je Server und Client auflisten, wo noch quantenanfälliger Schlüsselaustausch genutzt wird und wo bereits hybrider Post-Quanten-Schlüsselaustausch, und zwar für jedes Gerät im Segment, auch Drucker, Appliances und Maschinen, auf denen kein Agent laufen kann. Was er nicht sieht: Kryptografie in Anwendungen und Datenbanken, auf der Festplatte gespeicherte Schlüssel und Zertifikate, Code-Signierung, verschlüsselte Backups, nicht überwachte Segmente und Verbindungen, deren Handshake nie am Sensor vorbeikommt. NQCI, das Krypto-Inventar von NetSenX (in der Preview), ist in jedem Plan sichtbar und ab dem Pro-Plan aktiv; es braucht den standardmäßig ausgeschalteten Paketmitschnitt-Sensor, eingeschaltet für einen Linux-Agenten oder als Sensor an einem SPAN- oder TAP-Port. Der Basismodus unter macOS sieht keine Handshakes. Kombinieren Sie es mit einem Zertifikatsinventar und Lieferantenfragebögen.

Schauen Sie auf die im TLS-Handshake gewählte Gruppe für den Schlüsselaustausch: X25519MLKEM768 bedeutet hybrid Post-Quanten; X25519, secp256r1 oder ein RSA-Schlüsselaustausch bedeuten nur klassisch. Einen einzelnen Server können Sie von außen testen: OpenSSL ab Version 3.5 und darauf aufbauende Werkzeuge wie curl können die hybride Gruppe anbieten und zeigen, was der Server wählt, und manche Online-TLS-Prüfer melden es. Auch die Entwicklerwerkzeuge des Browsers zeigen die ausgehandelte Gruppe einer besuchten Website. Für das ganze Netz reicht ein einmaliger Test nicht, denn es zählt, was täglich wirklich zwischen Ihren Clients und Servern passiert: Alte Clients, Appliances und interne Anwendungen fallen oft auf klassische Gruppen zurück. NQCI, in der Preview, zeigt das je Verbindung im überwachten Verkehr. Es ist in jedem Plan sichtbar und ab dem Pro-Plan aktiv, mit eingeschaltetem Paketmitschnitt-Sensor für einen Linux-Agenten oder als SPAN- oder TAP-Sensor, denn der Basismodus unter macOS sieht keine Handshakes. Das Ergebnis zeigt, wo Updates die Migration schon erledigt haben und wo sie noch aussteht.

Halten Sie für jede Stelle, an der Kryptografie etwas schützt, fest, was geschützt wird, wie, und wer es ändern kann. Praktische Felder: das System oder der Dienst und sein Verantwortlicher; was es schützt, mit Datenart und wie viele Jahre die Daten geheim bleiben müssen; das Protokoll, etwa TLS, SSH, IPsec, S/MIME, Code-Signierung oder Festplatten- und Datenbankverschlüsselung; die Algorithmen für Schlüsselaustausch, Signatur und Verschlüsselung mit Schlüssellängen; Zertifikate mit Aussteller und Ablaufdatum; die Bibliotheks- oder Produktversion und ob der Hersteller einen Post-Quanten-Plan hat; und ob sich der Algorithmus per Konfiguration ändern lässt. Ergänzen Sie eine Priorität aus der Mosca-Ungleichung. Die Quellen unterscheiden sich je Schicht: Netzbeobachtung für das, was über die Leitung geht, Zertifikatsverwaltung und Scanner für Zertifikate, Software-Composition-Analyse und Lieferantenfragebögen für das, was in Anwendungen steckt. Ein Inventar nur aus Zertifikaten übersieht den Schlüsselaustausch, eines nur aus dem Netz übersieht gespeicherte Daten. Halten Sie es aktuell, denn jedes Update kann die Antwort ändern, und datieren Sie jeden Eintrag: Prüfer und Ausschreibungen fragen, wann zuletzt geprüft wurde.

Nein, und kein Produkt zur Netzwerküberwachung kann das. Schutz vor einem künftigen Quantencomputer entsteht, indem Sie die Kryptografie in Ihren eigenen Systemen und in denen Ihrer Lieferanten ändern: zuerst hybrider Schlüsselaustausch, dann Post-Quanten-Signaturen. NetSenX ist kein Verschlüsselungsprodukt und ändert, aktualisiert oder migriert nichts. Es gibt Ihnen Sichtbarkeit, und damit beginnt jede Migration. NQCI, das Krypto-Inventar von NetSenX, ist in der Preview: in jedem Plan sichtbar und ab dem Pro-Plan aktiv. Es zeigt, welche Verbindungen im überwachten Verkehr noch quantenanfälligen Schlüsselaustausch nutzen und welche schon hybriden Post-Quanten-Schlüsselaustausch, sodass Sie sehen, wo Updates die Arbeit schon erledigt haben und wo nicht, und später Rückschritte erkennen. Es braucht den Paketmitschnitt-Sensor, der standardmäßig aus ist: eingeschaltet für einen Linux-Agenten oder als Sensor an einem SPAN- oder TAP-Port; der Basismodus unter macOS sieht keine Handshakes. Kryptografie in Anwendungen, auf Festplatten oder in Segmenten, die kein Sensor beobachtet, sieht es nicht.

Mit Fakten zu Ihrem Plan, nicht mit Schlagworten. Bewerter suchen meist vier Dinge: dass Sie wissen, wo Sie quantenanfällige Kryptografie einsetzen, dass Sie priorisiert haben, dass Sie einen Zeitplan haben und dass jemand verantwortlich ist. Eine starke Antwort nennt das Inventar und sein Datum; die Methode der Priorisierung, etwa die Mosca-Ungleichung angewandt auf Aufbewahrungsfristen; die bereits getanen Schritte, etwa hybrider Schlüsselaustausch auf öffentlichen Diensten und geprüfte VPN- und SSH-Versionen; die Abhängigkeiten von Lieferanten mit deren erklärten Plänen; und Meilensteine entlang des koordinierten EU-Fahrplans: erste Schritte bis Ende 2026 und Anwendungsfälle mit hohem Risiko bis Ende 2030. Nennen Sie die NIST-Standards FIPS 203, 204 und 205 beim Namen. Behaupten Sie nicht, Ihr Dienst sei immun gegen Quantenangriffe; ein kundiger Bewerter zieht dafür Punkte ab. Stammt Ihr Inventar teilweise aus Netzbeobachtung, sagen Sie das und auch, was es nicht abdeckt. Eine ehrliche Teilantwort mit Terminen schneidet besser ab als eine selbstbewusste Lücke.

Stellen Sie Fragen mit überprüfbaren Antworten. Welche Post-Quanten- oder Hybridalgorithmen unterstützt das Produkt heute, mit Namen, etwa X25519MLKEM768 für TLS oder ML-DSA für Signaturen, und ab welcher Version? Falls noch keine: in welchem Release und bis wann? Lassen sich die Algorithmen per Konfiguration oder Update wechseln, ohne Hardware zu tauschen? Welche Kryptobibliothek nutzt das Produkt, und wer pflegt sie? Hat die Hardware, etwa eine Firewall, ein Hardware-Sicherheitsmodul oder eine Steuerung, Reserven für größere Schlüssel, oder muss sie ersetzt werden? Wie wird der Hersteller seine eigenen Updates signieren, wenn sich die Signaturalgorithmen ändern? Funktioniert das Produkt in der Übergangszeit weiter mit Clients, die nur klassische Algorithmen beherrschen? Verlangen Sie die Antworten schriftlich und mit Terminen. Seien Sie vorsichtig bei Antworten, die Immunität gegen Quantenangriffe versprechen oder nur über symmetrische Verschlüsselung reden: Sie weichen der eigentlichen Frage aus. Ein Anbieter, der nicht antworten kann, ist eine Abhängigkeit, die Sie einplanen müssen, und seine Antwort gehört in Ihr Inventar.