Der Status-Quo des Post-Quanten-Internets 2025

Diese Woche, in der letzten Oktoberwoche 2025, haben wir einen wichtigen Meilenstein für die Internetsicherheit erreicht: Der Großteil des von Menschen initiierten Datenverkehrs mit Cloudflare verwendet Post-Quanten-Verschlüsselung, wodurch die Bedrohung durch Harvest-Now/Decrypt-Later gemindert wird.

Wir möchten diesen freudigen Moment nutzen, um ein Update zum aktuellen Stand der Migration des Internets zur Post-Quanten-Kryptographie geben – und über den langen Weg, der noch vor uns liegt. Unser letzter Überblick liegt nun 21 Monate zurück, und seitdem hat sich viel getan. Vieles davon ist wie vorhergesagt eingetreten: die Fertigstellung der NIST-Standards, die breite Einführung der Post-Quanten-Verschlüsselung, detailliertere Roadmaps von Regulierungsbehörden, Fortschritte beim Bau von Quantencomputern, der Bruch einiger Kryptographien (keine Sorge: nichts, was auch nur annähernd eingesetzt wird) und neue, spannende Kryptografie wurde vorgeschlagen.

Doch es gab auch einige Überraschungen: Ein großer Fortschritt in Richtung Q-Day wurde durch die Verbesserung quantenmechanischer Algorithmen erzielt, und ein neuer Quantenalgorithmus sorgte für einen ernstzunehmenden Schreckmoment. Wir werden all dies und mehr behandeln: was wir für die kommenden Jahre erwarten und was Sie heute bereits unternehmen können.

Das Wichtigste zuerst: Warum ändern wir unsere Kryptografie? Es liegt an den Quantencomputern. Diese wundersamen Geräte beschränken sich nicht auf Nullen und Einsen, sondern nutzen vielmehr das, was die Natur tatsächlich bereithält: Quantenüberlagerung, Interferenz und Verschränkung. Dadurch sind Quantencomputer in der Lage, bestimmte sehr spezielle Berechnungen besonders effizient durchzuführen – insbesondere die Simulation der Natur selbst, was bei der Entwicklung neuer Materialien äußerst hilfreich sein wird.

Quantencomputer werden herkömmliche Computer nicht ersetzen – im Gegenteil: Bei den meisten Aufgaben, die im Alltag relevant sind, sind sie ihnen deutlich unterlegen. Man kann sie sich eher wie Grafikkarten oder Neural Engines vorstellen – spezialisierte Geräte für bestimmte Rechenaufgaben, nicht für den allgemeinen Gebrauch.

Leider sind Quantencomputer auch besonders gut darin, wichtige Kryptografieverfahren zu knacken, die heute noch weit verbreitet sind – etwa RSA und elliptische Kurven (ECC). Daher vollziehen wir den Übergang zur Post-Quanten-Kryptografie: Kryptografie, die gegen Angriffe durch Quantencomputer resistent ist. Die genauen Auswirkungen auf die verschiedenen Kryptografiearten werden wir später noch erläutern.

Derzeit sind Quantencomputer noch recht schwach: Sie sind heute schlichtweg nicht leistungsfähig genug, um reale kryptografische Schlüssel zu knacken. Das bedeutet jedoch nicht, dass wir uns noch keine Sorgen machen sollten – verschlüsselte Daten können bereits jetzt abgefangen und nach dem Q-Day – dem Tag, an dem Quantencomputer in der Lage sind, gängige Verschlüsselungsverfahren wie RSA-2048 zu knacken – entschlüsselt werden. Wir bezeichnen dies als „Harvest-Now-Decrypt-Later“-Angriff.

Nimmt man das Faktorisieren als Maßstab, wirken Quantencomputer wenig beeindruckend: Die größte Zahl, die bislang ohne Tricks mit einem Quantencomputer faktorisiert wurde, ist 15 – ein Rekord, der sich auf vielfältig amüsante Weise überbieten lässt. Es ist verlockend, Quantencomputer erst ernst zu nehmen, wenn sie klassische Rechner beim Faktorisieren übertreffen – doch das wäre ein großer Fehler. Selbst konservative Schätzungen sehen den Q-Day weniger als drei Jahre nach jenem Tag, an dem Quantencomputer beim Faktorisieren die klassischen Systeme schlagen. Wie also lässt sich der Fortschritt beobachten?

Auf dem Weg zum Q-Day sind zwei Kategorien zu berücksichtigen: Fortschritte in der Quantenhardware und algorithmische Verbesserungen der Software, die auf dieser Hardware ausgeführt wird. Wir haben in beiden Bereichen deutliche Fortschritte gesehen.

Wie ein Uhrwerk erscheinen jedes Jahr Meldungen über neue Quantencomputer mit einer Rekordanzahl an Qubits. Dieser Fokus auf die Zählung von Qubits ist ebenfalls recht irreführend. Zunächst einmal sind Quantencomputer analoge Maschinen, und es gibt immer ein gewisses Rauschen, das die Berechnung beeinträchtigt.

Zwischen den verschiedenen Technologien zur Realisierung von Quantencomputern bestehen erhebliche Unterschiede: siliziumbasierte Quantencomputer lassen sich gut skalieren und führen Instruktionen schnell aus, leiden jedoch unter sehr starkem Qubit-Rauschen. Das macht sie jedoch nicht nutzlos – mithilfe von Quanten-Fehlerkorrekturcodes lassen sich Millionen verrauschter Silizium-Qubits in einige Tausend hochpräzise Qubits umwandeln – genug, um RSA zu knacken. Ionenfallen-basierte Quantencomputer wiederum weisen deutlich weniger Rauschen auf, sind aber schwerer zu skalieren. Bereits ein paar Hunderttausend dieser Qubits könnten ausreichen, um das Ende von RSA-2048 einzuleiten.

^{Zeitraffer zur Spitzenentwicklung in der Quanteninformatik von 2021 bis 2025 – mit der Qubit-Anzahl auf der X-Achse und dem Rauschpegel auf der Y-Achse. Die Punkte im grauen Bereich repräsentieren verschiedene existierende Quantencomputer. Sobald dieser graue Bereich die linke rote Linie erreicht, wird es kritisch – das würde bedeuten, dass ein Quantencomputer große RSA-Schlüssel knacken kann. Zusammengestellt von Samuel Jaques von der University of Waterloo.}

Die Anzahl der Qubits und das Rauschniveau geben nur einen oberflächlichen Einblick. Wesentliche Details auf Hardwareebene – wie die Qubit-Verschaltung – können entscheidend sein. Vor allem aber bildet das Diagramm nicht ab, wie gut sich die verwendete Technologie skalieren lässt.

Tatsächlich scheint der Fortschritt bei Quantencomputern auf diesen Diagrammen in den letzten zwei Jahren zu stagnieren. Für Fachleute jedoch markiert Googles Willow-Ankündigung vom Dezember 2024 – die in der Grafik kaum auffällt – in Wirklichkeit einen echten Meilenstein: die skalierbare Umsetzung des ersten logischen Qubits im Surface Code. Zitat Sam Jaques:

Als ich diese Ergebnisse [Willow] zum ersten Mal las, bekam ich eine Gänsehaut – „Wow, Quantencomputing ist wirklich real.“

Zweifellos ein bedeutender Meilenstein – jedoch kein überraschender Durchbruch. Um Sam nochmals zu zitieren:

Trotz meiner Begeisterung befinden wir uns damit ungefähr dort, wo man uns erwarten würde – vielleicht sogar etwas verspätet. Alle großen Durchbrüche, die demonstriert wurden, sind notwendige Schritte auf dem Weg zu einer 20-Millionen-Qubit-Maschine, die RSA knacken könnte. Unerwartete Durchbrüche gibt es keine. Man kann es mit dem jährlichen Anstieg der Transistordichte klassischer Chips vergleichen: beeindruckend, aber letztlich erwartbar.

„Business as usual“ ist zugleich die Strategie: Der von Google bei Willow verfolgte Ansatz mit supraleitenden Qubits gilt seit jeher als der direkteste Weg, bei dem die Herausforderungen gezielt und mit minimalem technischem Risiko angegangen werden.

Im Gegensatz dazu verfolgt Microsoft mit seinem Fokus auf topologische Qubits eine ganz andere Strategie. Diese Qubits wären theoretisch weitgehend rauschresistent. Sollten sie sich in großem Maßstab umsetzen lassen, wären sie herkömmlichen supraleitenden Qubits deutlich überlegen. Ob ihr Bau jedoch überhaupt möglich ist, ist nach wie vor ungeklärt. Anfang 2025 stellte Microsoft den Majorana-1-Chip vor – ein erster Ansatz, wie diese Technologie realisiert werden könnte. Allerdings unterstützt der Chip keine Berechnungen und taucht daher auch nicht in Sams früherer Vergleichsgrafik auf.

Zwischen topologischen und supraleitenden Qubits gibt es zahlreiche weitere Ansätze, die weltweit in Laboren verfolgt werden und in der Grafik auftauchen – etwa QuEra mit neutralen Atomen und Quantinuum mit Ionenfallen.

Das größte Interesse in der Presse fanden bisher die Fortschritte auf der Hardware-Seite im Hinblick auf den Q-Day. Der größte Durchbruch der letzten zwei Jahre liegt jedoch nicht im Hardwarebereich.

Wir dachten, dass wir mit der Supraleitung etwa 20 Millionen Qubits benötigen würden, um RSA-2048 zu knacken. Tatsächlich geht es mit deutlich weniger. In einer beeindruckend umfassenden Arbeit vom Juni 2025 zeigt Craig Gidney, dass durch clevere Optimierungen in der Quanten-Software weniger als eine Million Qubits ausreichen. Aus diesem Grund verschieben sich die roten Linien in Sams Diagramm – die die Grenze zum Knacken von RSA markieren – im Jahr 2025 drastisch nach links.

Um diese Leistung einzuordnen, nehmen wir einmal ganz spekulativ an, Google könne so etwas wie ein Moore’sches Gesetz aufrechterhalten und die Zahl physikalischer Qubits alle anderthalb Jahre verdoppeln. Das wäre deutlich schneller als bisher demonstriert, aber nicht völlig unrealistisch, sobald die Grundlagen geschaffen sind. Dann würde es bis 2052 dauern, um 20 Millionen Qubits zu erreichen – aber nur bis 2045 für eine Million. Craig hat Q-Day also um sieben Jahre nähergerückt!

Wie viel Potenzial steckt noch in Software-Optimierungen? Unter 100.000 supraleitende Qubits zu kommen, erscheint Sam als unmöglich, und er geht davon aus, dass mehr als 242.000 nötig sein werden, um RSA-2048 zu knacken. Legt man unsere frühere Schätzung zum Fortschritt von Quantencomputern zugrunde, entspräche das einem Q-Day im Jahr 2039 bzw. frühestens 2041.

Auch wenn Craigs Schätzung auf detaillierten und plausiblen Annahmen zur Architektur eines großskaligen Quantencomputers mit supraleitenden Qubits beruht, bleibt sie dennoch eine Schätzung – und sie könnte erheblich danebenliegen.

Auf algorithmischer Ebene könnten nicht nur bestehende Quantenalgorithmen verbessert werden – es ist auch denkbar, dass völlig neue entdeckt werden. Im April 2024 veröffentlichte Yilei Chen ein Preprint, in dem er angab, einen neuen Quantenalgorithmus für bestimmte Gitterprobleme gefunden zu haben – diese ähneln, aber entsprechen nicht exakt den Problemen, auf denen unsere Post-Quanten-Kryptografie basiert. Die Veröffentlichung sorgte für große Unruhe: Auch wenn der Algorithmus unsere heutigen Verfahren nicht direkt angreifen konnte, stellte sich die Frage – ließe sich Chens Ansatz noch verbessern? Um das einschätzen zu können, musste man verstehen, was der Algorithmus auf konzeptioneller Ebene leistet. Das war jedoch schwierig – Chens Methode ist äußerst komplex, deutlich komplexer als Shors Algorithmus, der RSA knackt. So dauerte es eine Weile, bis Fachleute erste Einschränkungen des Ansatzes erkannten – und schließlich, nach zehn Tagen, einen grundlegenden Fehler im Algorithmus entdeckten: Der Ansatz funktioniert nicht. Krise abgewendet.

Was ist daraus zu schließen? Optimistisch betrachtet ist dies das übliche Geschäft in der Kryptografie – und Gitterverfahren stehen heute besser da, da sich ein möglicher Angriffsweg als Sackgasse erwiesen hat. Realistisch gesehen ist es jedoch ein Hinweis darauf, dass wir sehr stark auf Gitter setzen. Wie wir später sehen werden, gibt es derzeit keine wirkliche Alternative, die überall einsetzbar ist.

Befürworter der Quanten-Schlüsselverteilung (QKD) könnten nun einwenden, dass genau dieses Problem durch QKD gelöst werde – schließlich garantiere hier die Naturgesetze selbst die Sicherheit. Nun, zu dieser Aussage gehören einige Fußnoten. Vor allem aber hat bislang niemand gezeigt, wie sich QKD über Punkt-zu-Punkt-Verbindungen hinaus skalieren lässt – wie wir in diesem Blogbeitrag erläutern.

Es ist sinnvoll, über mögliche völlig neue Angriffe auf Kryptografie zu spekulieren – aber wir dürfen das Wesentliche nicht aus den Augen verlieren: Viel Kryptografie wird mit Sicherheit durch Quantencomputer geknackt werden. Q-Day kommt, die Frage ist nur: wann.

Wer schon länger im Bereich Kryptografie und IT-Sicherheit tätig ist, hat wahrscheinlich in jedem der vergangenen Jahre gehört, dass „Q-Day noch X Jahre entfernt“ sei. Das kann leicht den Eindruck erwecken, Q-Day sei immer „irgendwann in der Zukunft“ – bis man solche Aussagen in den richtigen Kontext stellt.

Seit 2019 führt das Global Risk Institute jährlich eine Umfrage unter Experten durch, in der gefragt wird, wie wahrscheinlich es ist, dass RSA-2048 innerhalb von 5, 10, 15, 20 oder 30 Jahren geknackt wird. Dies sind die Ergebnisse für 2024 – die Befragungen fanden vor der Veröffentlichung von Willow und Gidneys Durchbruch statt.

^{Ergebnisse der Expertenumfrage des Global Risk Institute aus dem Jahr 2024 zur Wahrscheinlichkeit, dass ein Quantencomputer RSA-2048 innerhalb unterschiedlicher Zeiträume bricht.}

Wie die mittlere Spalte dieser Grafik zeigt, gingen deutlich über die Hälfte der befragten Experten davon aus, dass die Wahrscheinlichkeit, dass ein Quantencomputer RSA-2048 innerhalb von 15 Jahren bricht, bei mindestens ~50 % liegt. Schauen wir uns die historischen Antworten aus den Jahren 2019, 2020, 2021, 2022 und 2023 an. Im Folgenden zeigen wir die jeweilige Einschätzung zur Wahrscheinlichkeit eines Q-Days innerhalb von 15 Jahren nach dem Zeitpunkt der jeweiligen Befragung:

^{Historische Angaben in den Quantum-Threat-Timeline-Berichten zur Wahrscheinlichkeit eines Q-Days innerhalb von 15 Jahren.}

Die Daten zeigen, dass die Antworten allmählich in Richtung größerer Gewissheit tendieren – aber geschieht das in dem Tempo, das wir erwarten würden? Mit sechs Jahren an Umfragedaten können wir untersuchen, wie konsistent die Vorhersagen über die Jahre hinweg sind: Entspricht die 15-Jahres-Prognose von 2019 der 10-Jahres-Prognose von 2024?

^{Historische Angaben in den Quantum-Threat-Timeline-Berichten zur erwarteten Q-Day-Datierung über die Jahre hinweg. Die x-Achse zeigt das jeweils angenommene Jahr des Q-Days, die y-Achse den Anteil der befragten Experten, die die Wahrscheinlichkeit dafür auf mindestens ~50 % (links) bzw. 70 % (rechts) schätzen.}

Fragt man Expertinnen und Experten, wann der Q-Day mit etwa gleichen Chancen eintreten könnte (Grafik links), geben sie über die Jahre hinweg meist dieselbe Antwort: Ja, könnte in etwa 15 Jahren sein.Drängt man jedoch auf mehr Sicherheit und fragt nach einem Eintritt mit über 70 % Wahrscheinlichkeit (Grafik rechts), zeigen sich die Antworten über die Jahre hinweg erstaunlich konstant. Beispiel: Ein Fünftel hielt das Jahr 2034 sowohl 2019 als auch 2024 für wahrscheinlich.

Wenn Sie eine konsistente Antwort von einem Experten wollen, fragen Sie nicht, wann der Q-Day sein könnte, sondern wann er wahrscheinlich eintritt. Natürlich macht es Spaß, über den Q-Day zu spekulieren – doch die ehrliche Antwort lautet: Niemand weiß es genau. Dafür gibt es schlicht zu viele Unbekannte. Und letztlich ist das genaue Datum des Q-Days weit weniger entscheidend als die Fristen, die von Aufsichtsbehörden gesetzt werden.

Wir können uns auch die Zeitpläne verschiedener Aufsichtsbehörden ansehen. Im Jahr 2022 veröffentlichte die National Security Agency (NSA) ihre CNSA 2.0-Richtlinien, die Fristen zwischen 2030 und 2033 für die Umstellung auf Post-Quanten-Kryptographie vorsehen. Ebenfalls im Jahr 2022 setzte die US-Bundesregierung das Ziel, bis 2035 die vollständige Migration der Vereinigten Staaten zu erreichen. Die neue Regierung ist davon nicht abgewichen. Australien hat 2024 das Jahr 2030 als seine ehrgeizige Frist für die Migration festgelegt. Anfang 2025 erreichte der UK NCSC den für das Vereinigte Königreich üblichen Stichtag 2035. Mitte 2025 veröffentlichte die Europäische Union ihren Fahrplan mit den Fristen 2030 und 2035, je nach Anwendungsbereich.

Bei weitem nicht alle nationalen Regulierungsbehörden haben Zeitpläne für die Post-Quanten-Migration veröffentlicht, doch diejenigen, die es getan haben, bewegen sich meist im Zeitraum 2030 bis 2035.

Wann also werden Quantencomputer zum Problem? Ob es 2034 oder 2050 ist, es wird auf jeden Fall zu früh sein. Der enorme Erfolg der Kryptografie über die letzten fünfzig Jahre hat sie allgegenwärtig gemacht – vom Geschirrspüler über den Herzschrittmacher bis hin zum Satelliten. Viele Systeme lassen sich problemlos im Rahmen ihres Lebenszyklus aktualisieren, doch es wird auch einen langen, aufwendigen und teuren Nachlauf geben.

Sehen wir uns nun die Migration zur Post-Quanten-Kryptographie an.

Zur Priorisierung ist es entscheidend zu verstehen, dass die Umstellung auf Post-Quanten-Kryptografie je nach Art der verwendeten Kryptoverfahren – etwa zur Absicherung von Verbindungen – unterschiedlich komplex, dringlich und folgenreich ist. Tatsächlich stehen die meisten Organisationen vor zwei separaten Post-Quanten-Migrationen: Schlüsselaustausch und Signaturen bzw. Zertifikate. Lassen Sie uns dies am Beispiel einer sicheren Verbindung zu einer Website im Browser erläutern.

Das kryptografische Arbeitstier einer Verbindung ist eine symmetrische Chiffre wie AES-GCM. Das entspricht dem klassischen Bild von Kryptografie: Beide Parteien – in diesem Fall Browser und Server – teilen sich einen geheimen Schlüssel, mit dem sie Nachrichten ver- und entschlüsseln. Ohne diesen Schlüssel kann man weder mitlesen noch etwas verändern.

Die gute Nachricht ist: Symmetrische Verschlüsselungsverfahren wie AES-GCM gelten bereits als postquanten-sicher. Ein weit verbreiteter Irrglaube ist, dass Grovers Quantenalgorithmus eine Verdopplung der Schlüssellänge erforderlich macht. Doch bei genauer Betrachtung des Algorithmus zeigt sich, dass er nicht praxisrelevant ist. Die Art und Weise, wie das NIST, das US-amerikanische National Institute for Standards and Technology (das die Standardisierung der Post-Quanten-Kryptographie vorangetrieben hat), seine Post-Quanten-Sicherheitsstufen definiert, ist sehr aufschlussreich. Ein Sicherheitsniveau wird dort definiert als die Schwierigkeit, ein Verfahren – egal ob mit klassischem oder Quantencomputer – zu knacken, wobei ein symmetrischer Algorithmus als Vergleich dient.

Stufe	Definition: so schwer zu knacken wie …	Beispiel
1	Wiederherstellen des Schlüssels von AES-128 durch erschöpfende Suche	ML-KEM-512, SLH-DSA-128s
2	Um einen Konflikt in SHA256 durch erschöpfende Suche zu finden	ML-DSA-44
3	Wiederherstellen des Schlüssels von AES-192 durch erschöpfende Suche	ML-KEM-768, ML-DSA-65
4	Um einen Konflikt in SHA384 durch erschöpfende Suche zu finden
5	Zur Wiederherstellung des Schlüssels von AES-256 durch erschöpfende Suche	ML-KEM-1024, SLH-DSA-256s, ML-DSA-87

^{NIST PQC-Sicherheitsstufen: Je höher, desto schwerer zu knacken („sicherer“). Die Beispiele ML-DSA, SLH-DSA und ML-KEM werden im Folgenden behandelt.}

Die Empfehlung, die Schlüssellängen symmetrischer Kryptografie zu verdoppeln, beruht auf guten Absichten. In vielen Anwendungsfällen ist der Mehraufwand gering und beseitigt jedes theoretische Risiko vollständig. Symmetrische Kryptografie lässt sich kostengünstig skalieren – doppelte Schlüssellänge bedeutet in der Regel deutlich weniger als doppelte Kosten. Oberflächlich betrachtet ist es daher ein naheliegender Ratschlag.

Wenn wir auf AES-256 bestehen, erscheint es nur logisch, auch für die Public-Key-Kryptografie das NIST-PQC-Level 5 zu fordern. Das Problem dabei: Public-Key-Kryptografie skaliert nicht gut. Je nach Verfahren bedeutet der Sprung von Level 1 auf Level 5 meist mehr als eine Verdopplung des Datenvolumens und der CPU-Belastung. Wie wir noch sehen werden, ist die Einführung postquanter Signaturen bereits auf Level 1 eine Herausforderung – auf Level 5 wird sie nahezu untragbar.

Wichtiger ist jedoch, dass Organisationen nur über begrenzte Ressourcen verfügen. Wir möchten nicht, dass ein Unternehmen die Aktualisierung von AES-128 priorisiert und dabei das definitiv quantenanfällige RSA vernachlässigt.

Symmetrische Verschlüsselungen allein reichen nicht aus: Woher weiß ich, welchen Schlüssel ich verwenden soll, wenn ich eine Website zum ersten Mal besuche? Der Browser kann nicht einfach einen zufälligen Schlüssel senden, da jeder, der mithört, diesen Schlüssel ebenfalls sehen würde. Man sollte meinen, dass dies unmöglich ist, aber es gibt eine ausgeklügelte mathematische Lösung, damit sich Browser und Server auf einen gemeinsamen Schlüssel einigen können. Ein solches Schema wird als Schlüsselvereinbarungsmechanismus bezeichnet und beim TLS-Handshake durchgeführt. Im Jahr 2024 ist fast der gesamte Datenverkehr mit X25519, einer Schlüsselvereinbarung im Diffie-Hellman-Stil, gesichert, aber seine Sicherheit wird durch Shor’s Algorithmus auf einem Quantencomputer vollständig geknackt. Somit kann jede Kommunikation, die heute mit Diffie-Hellman gesichert wird, nach ihrer Speicherung in der Zukunft von einem Quantencomputer entschlüsselt werden.

Dies macht es dringend notwendig, die Schlüsselvereinbarung heute zu aktualisieren. Glücklicherweise ist die Post-Quanten-Schlüsselvereinbarung relativ einfach zu implementieren, und wie wir bereits gesehen haben, ist die Hälfte der Anfragen bei Cloudflare bis Ende 2025 bereits mit einer Post-Quanten-Schlüsselvereinbarung gesichert!

Die Schlüsselvereinbarung ermöglicht eine sichere Einigung auf einen Schlüssel, aber es gibt eine große Lücke: Wir wissen nicht, mit wem wir uns auf den Schlüssel geeinigt haben. Wenn wir nur einen Schlüsselaustausch durchführen, kann ein Angreifer in der Mitte separate Schlüsselaustausche mit dem Browser und dem Server durchführen und alle ausgetauschten Nachrichten erneut verschlüsseln. Um dies zu verhindern, benötigen wir noch eine letzte Zutat: Authentifizierung.

Dies wird mit Hilfe von Signaturen erreicht. Wenn Sie eine Website besuchen, z. B.cloudflare.com, legt der Webserver ein von einer Zertifizierungsstelle (Certification Authority, CA) signiertes Zertifikat vor, das bestätigt, dass der öffentliche Schlüssel in diesem Zertifikat von cloudflare.com kontrolliert wird. Der Webserver signiert den Handshake und den Shared Key wiederum mit dem privaten Schlüssel, der dem öffentlichen Schlüssel im Zertifikat entspricht. So kann der Kunde sicher sein, dass er eine Schlüsselvereinbarung mit cloudflare.com abgeschlossen hat.

RSA und ECDSA sind heutzutage gängige traditionelle Signaturverfahren. Auch hier macht Shors Algorithmus kurzen Prozess mit ihnen, wodurch ein Quantenangreifer jede Signatur fälschen kann. Das bedeutet, dass ein Angreifer mit einem Quantencomputer jede Website imitieren (und MitM) kann, für die wir Nicht-Post-Quanten-Zertifikate akzeptieren.

Dieser Angriff kann erst dann durchgeführt werden, wenn Quantencomputer in der Lage sind, RSA/ECDSA zu knacken. Dies macht die Aktualisierung der Signaturschemata für TLS scheinbar weniger dringlich, da wir nur alle vor dem Q-Day migriert haben müssen. Leider werden wir feststellen, dass die Migration zu Post-Quanten-Signaturen wesentlich schwieriger ist und mehr Zeit beanspruchen wird.

Bevor wir uns mit den technischen Herausforderungen der Migration des Internets zu Post-Quanten-Kryptographie befassen, wollen wir einen Blick darauf werfen, wie wir an diesen Punkt gelangt sind und was wir in den kommenden Jahren erwarten können. Beginnen wir damit, wie die Post-Quanten-Kryptographie entstanden ist.

Die Physiker Feynman und Manin schlugen um 1980 unabhängig voneinander Quantencomputer vor. Es dauerte weitere 14 Jahre, bis Shor seinen Algorithmus zum Angriff auf RSA/ECC veröffentlichte. Die meisten Post-Quanten-Kryptographieverfahren sind älter als Shors berühmter Algorithmus.

Es gibt verschiedene Zweige der Post-Quanten-Kryptographie. Die bekanntesten davon sind gitterbasierte, Hash-basierte, multivariate, codebasierte und isogeniebasierte Kryptographie. Mit Ausnahme der isogenie-basierten Kryptografie wurde keine dieser Möglichkeiten ursprünglich als Post-Quanten-Kryptografie konzipiert. Tatsächlich sind frühe codebasierte und Hash-basierte Schemata zeitgleich mit RSA entstanden, da sie in den 1970er Jahren vorgeschlagen wurden, und sie datieren die Veröffentlichung von Shors Algorithmus im Jahr 1994 deutlich vor. Das erste multivariate Schema aus dem Jahr 1988 ist zudem deutlich älter als der Shor-Algorithmus. Es ist ein schöner Zufall, dass der erfolgreichste Zweig, die gitterbasierte Kryptographie, der engste Zeitgenosse von Shor ist und im Jahr 1996 vorgeschlagen wurde. Zum Vergleich: Die heute weit verbreitete Elliptische-Kurven-Kryptografie wurde erstmals 1985 vorgeschlagen.

In den Jahren nach der Veröffentlichung des Shor-Algorithmus untersuchten Kryptographen die bestehende Kryptographie: Was ist eindeutig defekt und was könnte post-quantensicher sein? Im Jahr 2006 fand der erste jährliche Internationale Workshop zur Post-Quanten-Kryptographie statt. Auf dieser Konferenz wurde ein Einführungstext erstellt, der sich gut als Einführung in das Fachgebiet eignet. Ein wichtiger Vorbehalt ist das Ende des Regenbogen-Signaturschemas. Im gleichen Jahr, 2006, wurde die elliptische Schlüsselvereinbarung X25519 vorgeschlagen, die nun den Großteil der Internetverbindungen schützt, entweder eigenständig oder als Hybrid mit dem Post-Quantum ML-KEM-768. 

Zehn Jahre später, im Jahr 2016, schrieb dasNIST, das National Institute of Standards and Technology der USA, einen öffentlichen Wettbewerb zur Standardisierung der Post-Quanten-Kryptographie aus. Sie verwendeten ein ähnliches offenes Format, wie es zur Standardisierung von AES im Jahr 2001 und SHA3 im Jahr 2012 verwendet wurde. Jeder kann sich beteiligen, indem er Vorschläge einreicht und diese bewertet. Kryptografen aus aller Welt reichten Algorithmen ein. Um die Aufmerksamkeit zu fokussieren, wurde die Liste der Einreichungen in drei Runden reduziert. Von den ursprünglich 82 Kandidaten haben es, basierend auf öffentlichem Feedback, acht in die Endrunde geschafft. Von diesen acht Schemata hat das NIST im Jahr 2022 beschlossen,zuerst vier zu standardisieren: ein KEM (Key-Encapsulation-Mechanism) und drei Signaturschemata.

Alter Name	Neuer Name	Art
Kyber	ML-KEM (FIPS203) – Auf Modul-Gitter-basierter Key-Encapsulation-Mechanism-Standard	Gitterbasiert
Dilithium	ML-DSA (FIPS 204) Modul-Gitter-basierter Digital-Signature-Standard	Gitterbasiert
SPHINCS+	SLH-DSA (FIPS 205) Stateless Hash-basierter Digital-Signature-Standard	Hash-basiert
Falcon	FN-DSA (noch nicht standardisiert) FFT über NTRU-Gitter Digital-Signature-Standard	Gitterbasiert

Die endgültigen Standards für die ersten drei wurden im August 2024 veröffentlicht. FN-DSA ist verspätet, das besprechen wir später.

ML-KEM ist derzeit der einzige standardisierte Post-Quanten-Schlüsselaustausch. Trotz gelegentlicher Herausforderungen durch größere Schlüssellängen lässt er sich größtenteils problemlos als Ersatz integrieren.

Die Situation bei den Signaturen stellt sich etwas anders dar: Es ist bezeichnend, dass das NIST sich bereits entschieden hat, drei davon zu standardisieren. Und es wird noch mehr Signaturen geben, die in Zukunft standardisiert werden sollen. Der Grund dafür ist, dass keine der vorgeschlagenen Signaturen auch nur annähernd ideal sind. Kurz gesagt haben sie alle viel größere Schlüssel und Signaturen als wir es gewohnt sind.

Aus sicherheitstechnischer Sicht ist SLH-DSA die konservativste Wahl, aber auch die leistungsschwächste. Für die Größen von Öffentlichen Schlüsseln und Signaturen ist FN-DSA für diese drei Bereiche optimal, aber es ist aufgrund von Gleitkommaarithmetik schwierig, Signaturen sicher zu implementieren. Aufgrund der eingeschränkten Anwendbarkeit und der komplexen Ausgestaltung von FN-DSA hat sich das NIST entschieden, sich vorrangig auf die anderen drei Schemata zu konzentrieren.

Damit ist ML-DSA die Standardauswahl. Ausführlichere Vergleiche finden Sie unten.

Die Standards des NIST allein genügen nicht. Es ist ebenso notwendig, die Verwendung der neuen Algorithmen in höherliegenden Protokollen zu standardisieren. In vielen Fällen – etwa beim Schlüsselaustausch in TLS – reicht es, den neuen Algorithmen eine Kennung zuzuweisen. In anderen Fällen, wie bei DNSSEC, ist eine genauere Ausarbeitung erforderlich. Zahlreiche Arbeitsgruppen der IETF bereiten sich seit Jahren auf die finalen NIST-Standards vor, und man erwartete, dass viele Protokollanpassungen noch 2024 abgeschlossen würden. Das war zu optimistisch: Einige sind fertig – viele jedoch noch nicht.

Beginnen wir mit den guten Nachrichten und sehen wir uns an, was getan wurde.

• Die hybride TLS-Schlüsselvereinbarung X25519MLKEM768, die X25519 mit ML-KEM-768 kombiniert (mehr dazu später), ist einsatzbereit und bereits relativ weit verbreitet. Auch andere Protokolle übernehmen ML-KEM im Hybridmodus, etwa IPsec, das in einfachen Konfigurationen bereits nutzbar ist. (Für bestimmte Szenarien gibt es noch eine kleine Herausforderung, die wir in einem späteren Blogbeitrag beleuchten werden.)Überraschend mag sein, dass die entsprechenden RFCs noch nicht veröffentlicht wurden. Für die Registrierung eines Schlüsselaustauschs in TLS oder IPsec ist jedoch kein RFC erforderlich. In beiden Fällen wird ein RFC dennoch weiterverfolgt, um Missverständnisse zu vermeiden – insbesondere, weil im Fall von TLS ein RFC Voraussetzung dafür ist, eine Methode als „empfohlen“ zu kennzeichnen.

• Für Signaturen ist die Integration von ML-DSA in X.509-Zertifikate und TLS gut geeignet. Ersteres ist ein neu erstellter RFC, und Letzteres benötigt keinen.

Nun zu den schlechten Nachrichten. Zum Zeitpunkt des Schreibens, Oktober 2025, hat die IETF noch nicht endgültig festgelegt, wie hybride Zertifikate aussehen sollen – also Zertifikate, die sowohl ein Post-Quanten- als auch ein klassisches Signaturverfahren kombinieren. Aber man ist kurz davor. Wir hoffen, dass dies Anfang 2026 geklärt sein wird.

Aber wenn es nur um die Zuweisung von Kennungen geht, was ist dann die Ursache für die Verzögerung? Vor allem geht es um Wahlmöglichkeiten. Beginnen wir mit den Entscheidungen, die in ML-DSA getroffen werden mussten.

Die zwei Hauptthemen der Diskussion rund um ML-DSA-Zertifikate waren das Prehashing und das Format des privaten Schlüssels.

Beim Prehashing wird die Nachricht in einem Teil des Systems gehasht, während ein anderer Teil die endgültige Signatur erzeugt. Das ist nützlich, wenn man etwa keine großen Dateien an ein HSM zum Signieren senden möchte. Frühe Entwürfe von ML-DSA unterstützten Prehashing mit SHAKE256, allerdings war das nicht klar ersichtlich. In der finalen Version hat NIST zwei Varianten aufgenommen: reguläres ML-DSA und eine explizite Prehashing-Variante, bei der beliebige Hashfunktionen erlaubt sind. Unterschiedliche Varianten sind problematisch – Nutzer müssen sich für eine entscheiden, Software könnte nicht alle Varianten unterstützen, und auch Tests und Validierungen müssen für beide durchgeführt werden. Es ist unstrittig, dass eine einheitliche Variante wünschenswert ist – die Frage war nur, welche. Nach intensiver Diskussion wurde reguläres ML-DSA ausgewählt.

Der zweite Punkt ist das Format des privaten Schlüssels. Aufgrund der Art und Weise, wie Kandidaten anhand von Performance-Benchmarks verglichen werden, ist es für die ursprüngliche ML-DSA-Einreichung vorteilhaft, einige Berechnungen im Privaten Schlüssel im Cache zu speichern. Das bedeutet, dass der private Schlüssel größer (mehrere Kilobyte) ist, als er sein müsste, und mehr Validierungsschritte benötigt. Es wurde vorgeschlagen, den privaten Schlüssel auf das Wesentliche zu reduzieren: nur noch ein 32-Byte-Seed. Für den endgültigen Standard hat sich das NIST entschieden, sowohl den Seed als auch den ursprünglichen, größeren privaten Schlüssel zuzulassen. Das ist nicht ideal: Bleiben Sie besser bei einer der beiden Lösungen. In diesem Fall konnte die IETF keine Entscheidung treffen und fügte sogar eine dritte Option hinzu: ein Paar, bestehend aus dem Seed und dem erweiterten privaten Schlüssel. Technisch gesehen waren sich fast alle einig, dass Seed die bessere Wahl ist. Der Grund, warum dies nicht akzeptabel war, ist, dass einige Anbieter bereits Schlüssel erstellt hatten, für die sie den Seed nicht aufbewahrten. Ja, wir haben bereits ein Post-Quanten-Erbe. Es hat fast ein Jahr gedauert, um diese beiden Entscheidungen zu treffen.

Um ein hybrides ML-DSA-Signaturschema zu definieren, sind noch viele weitere Entscheidungen zu treffen. Mit welchem traditionellen Schema lässt sich ML-DSA kombinieren? Welche Sicherheitsstufen auf beiden Seiten? Dann müssen wir auch Entscheidungen für beide Schemata treffen: Welches Format für private Schlüssel soll verwendet werden? Welcher Hash soll für ECDSA verwendet werden? Hybride stellen ihre eigenen neuen Fragen. Erlauben wir die Wiederverwendung der Schlüssel im Hybrid, und wollen wir dadurch Stripping-Angriffe verhindern? Außerdem stellt sich die Frage nach dem Prehashing mit einer dritten Option: Prehash auf hybrider Ebene.

Der Entwurf für ML-DSA-Hybrid-Signaturen vom Oktober 2025 umfasst 18 Varianten, gegenüber 26 ein Jahr zuvor. Auch hier sind sich alle einig, dass das zu viel ist, aber es war schwierig, es weiter zu reduzieren. Um Endnutzern die Auswahl zu erleichtern, wurde eine kurze Liste hinzugefügt, die mit drei Optionen begann und sich dann auf sechs Optionen erweiterte. Wir gehen davon aus, dass MLDSA44-ECDSA-P256-SHA256 im Internet breite Unterstützung und Verwendung finden wird.

Kehren wir nun zur Schlüsselvereinbarung zurück, für die die Standards festgelegt worden sind.

Der nächste Schritt ist Software-Support. Nicht alle Ökosysteme können sich mit der gleichen Geschwindigkeit bewegen, aber wir haben bereits eine breite Akzeptanz von Post-Quanten-Schlüsselvereinbarungen festgestellt, um dem „Store-now/Decrypt-later“-Prinzip entgegenzuwirken. Aktuelle Versionen aller wichtigen Browser und viele TLS-Bibliotheken und -Plattformen, insbesondere OpenSSL, Go und aktuelle Apple-Betriebssysteme, haben X25519MLKEM768 standardmäßig aktiviert. Verschaffen Sie sich hier einen Überblick.

Auch bei TLS gibt es einen großen Unterschied zwischen Schlüsselaushandlung und Signaturen. Für die Schlüsselvereinbarung können Server und Client die Unterstützung für Post-Quanten-Schlüsselvereinbarungen unabhängig voneinander hinzufügen und aktivieren. Sobald TLS-Verhandlung auf beiden Seiten aktiviert ist, wird Post-Quanten-Schlüsselvereinbarung verwendet. In diesem Blogbeitrag gehen wir näher auf die TLS-Verhandlung ein. Wenn Ihr Produkt lediglich TLS verwendet, könnte Ihr Store-Now/Decrypt-Now-Problem durch eine einfache Softwareaktualisierung der TLS-Bibliothek behoben werden.

Post-Quanten-TLS-Zertifikate sind eher lästig. Wenn Sie nicht beide Enden kontrollieren, müssen Sie zwei Zertifikate installieren: ein Post-Quanten-Zertifikat für die neuen Clients und ein traditionelles Zertifikat für die alten Clients. Wenn Sie die automatische Ausstellung von Zertifikaten noch nicht nutzen, könnte dies ein guter Grund sein, dies zu überprüfen. TLS ermöglicht es dem Client zu signalisieren, welche Signaturschemata er unterstützt, sodass der Server ein Post-Quanten-Zertifikat nur für Clients bereitstellen kann, die diese unterstützen. Obwohl fast alle TLS-Bibliotheken die Einrichtung mehrerer Zertifikate unterstützen, gibt es diese Konfiguration leider nicht auf allen Servern. Wenn dies der Fall ist, ist in den meisten Fällen dennoch eine Konfigurationsänderung erforderlich. (Obwohl caddy das zweifellos für Sie tun wird.)

Apropos Post-Quanten-Zertifikate: Es wird einige Zeit dauern, bis Zertifizierungsstellen (ZAs) diese ausstellen können. Ihre HSMs benötigen zunächst (Hardware-)Unterstützung, die dann überprüft werden muss. Außerdem muss die Verwendung der neuen Algorithmen vom CA/Browser forum genehmigt werden. Root-Programme vertreten unterschiedliche Auffassungen hinsichtlich der Zeitpläne. Gerüchten zufolge bereitet eines der Root-Programme ein Pilotprojekt vor, um Ein-Jahres-Zertifikate mit ML-DSA-87 zu akzeptieren – möglicherweise noch vor Ende 2025. Ein entsprechender Antrag im CA/Browser-Forum befindet sich in Vorbereitung. Chrome hingegen zieht es vor, zuerst das große Zertifikatsproblem zu beheben. Für die Vorreiter werden die Audits voraussichtlich den Engpass darstellen, da nach der Veröffentlichung der NIST-Standards zahlreiche Einreichungen erfolgen werden. Obwohl wir die ersten Post-Quanten-Zertifikate im Jahr 2026 sehen werden, ist es unwahrscheinlich, dass sie vor 2027 allgemein verfügbar oder von allen Browsern als vertrauenswürdig eingestuft werden.

Wir befinden uns in einer interessanten Übergangszeit, in der ein Großteil des Internet-Traffics durch Post-Quanten-Schlüsselvereinbarungen geschützt ist, aber noch kein einziges öffentliches Post-Quanten-Zertifikat verwendet wird.

Das NIST hat die Standardisierung der Post-Quanten-Kryptographie noch nicht ganz abgeschlossen. Zwei weitere Wettbewerbe laufen derzeit: Runde 4 und die Signatur-Onramp.

Das NIST hat bisher nur ein Post-Quanten-Schlüsselvereinbarungsverfahren standardisiert: ML-KEM. Sie hätten gerne ein zweites, ein Backup KEM, das nicht auf Gittern basiert, falls sich diese als schwächer als erwartet herausstellen sollten. Um diesen zu finden, wurde der ursprüngliche Wettbewerb um eine vierte Runde mit einem vierten Durchgang erweitert, um unter den Finalisten einen Backup-KEM auszuwählen. Im März 2025 wurde HQC zur Standardisierung ausgewählt.

HQC schneidet in jeder einzelnen Metrik deutlich schlechter ab als ML-KEM. HQC-1, die Variante mit der niedrigsten Sicherheitsstufe, benötigt 7 kB Daten im Netzwerk. Dies ist fast das Doppelte der 3 kB, die für ML-KEM-1024, der Variante mit der höchsten Sicherheitsstufe, benötigt werden. Eine ähnliche Lücke besteht bei der CPU-Performance. Auch die HQC-Skalierung verschlechtert sich mit dem Sicherheitsniveau: Während ML-KEM-1024 etwa doppelt so viel kostet wie ML-KEM-512, benötigt die höchste Sicherheitsstufe von HQC die dreifache Datenmenge (21 kB!) und mehr als die vierfache Rechenleistung.

Was ist mit der Sicherheit? Um sich gegen schrittweise verbesserte Angriffe abzusichern, hat ML-KEM-768 klare Vorteile gegenüber HQC-1: Es bietet deutlich bessere Performance und weist auf Sicherheitsstufe 3 im Vergleich zu Stufe 1 eine erhebliche Sicherheitsreserve auf. Aber was ist mit plötzlichen Durchbrüchen? Sowohl ML-KEM als auch HQC basieren auf ähnlichen algebraischen Strukturen – auf Gittern bzw. Codes – sodass ein theoretischer Durchbruch beide betreffen könnte. Auch ohne diese algebraischen Strukturen erscheinen Codes und Gitter eng verwandt. Das ist nun reine Spekulation: Ein katastrophaler Angriff auf Gitter könnte Codes verschonen – muss er aber nicht. Immerhin werden auch RSA und ECC, die deutlich unterschiedlicher sind, beide durch Quantencomputer geknackt.

Es könnte trotzdem beruhigend sein, HQC für alle Fälle in der Nähe zu haben. An dieser Stelle möchten wir eine Anekdote aus der chaotischen Woche erzählen, in der noch nicht klar war, dass Chens Quantenalgorithmus gegen Gitter fehlerhaft war. Womit sollte ML-KEM ersetzt werden, falls es betroffen wäre? HQC wurde kurz in Betracht gezogen, aber es war klar, dass eine angepasste Variante von ML-KEM weiterhin deutlich leistungsfähiger wäre.

Tritt man einen Schritt zurück, so ist die Suche nach einem zweiten effizienten KEM ein Luxusproblem. Wenn ich mir ein neues Post-Quanten-Verfahren wünschen dürfte, würde ich mir kein besseres KEM, sondern ein besseres Signaturschema wünschen. Mal sehen, ob mir das Glück hold ist.

Ende 2022, nach der Ankündigung der ersten vier ausgewählten Verfahren, rief NIST einen neuen Wettbewerb ins Leben, die sogenannte Signatures Onramp, um weitere Signaturschemata zu finden. Der Wettbewerb verfolgt zwei Ziele: Erstens soll er gegen mögliche kryptanalytische Durchbrüche bei gitterbasierter Kryptografie absichern. NIST möchte eine Signatur standardisieren, die besser als SLH-DSA ist – sowohl hinsichtlich Größe als auch Rechenaufwand – und nicht auf Gittern basiert. Zweitens sucht man nach einem Verfahren, das sich in Anwendungsfällen bewährt, in denen die bisherigen Kandidaten Schwächen zeigen – auf diese gehen wir später im Beitrag noch ausführlich ein.

Im Juli 2023 veröffentlichte NIST die 40 eingereichten Vorschläge zur ersten öffentlichen Begutachtung. Die Kryptografie-Community nahm die Arbeit auf, und wie in einer ersten Runde üblich, wurden viele Verfahren innerhalb einer Woche geknackt. Bis Februar 2024 waren zehn Einreichungen vollständig kompromittiert, und mehrere weitere erheblich geschwächt. Von den verbliebenen Kandidaten wählte NIST im Oktober 2024 vierzehn Vorschläge für die zweite Runde aus.

Vor einem Jahr haben wir einen Blogbeitrag verfasst, der diese 14 Einreichungen ausführlich behandelt. Die Kurzfassung: Bei Post-Quanten-Signaturschemata wurden erstaunliche Fortschritte erzielt. Wir werden später kurz darauf eingehen und einige aktuelle Informationen über die Fortschritte seit dem letzten Jahr geben. Es ist erwähnenswert, dass der Auswahlprozess, ähnlich dem wichtigsten Post-Quanten-Wettbewerb, mehrere Jahre dauern wird. Es ist unwahrscheinlich, dass eines dieser On-Ramp-Signaturschemata vor 2028 standardisiert wird – falls sie nicht vorher schon kompromittiert werden. Das bedeutet, dass sie in Zukunft zwar sehr willkommen sind, wir aber nicht darauf vertrauen können, dass bessere Signaturverfahren unsere heutigen Probleme lösen werden. Wie Eric Rescorla, der Herausgeber von TLS 1.3, schreibt: „Man zieht mit den Algorithmen in den Krieg, die man hat, nicht mit denen, die man sich wünscht.“

Vor diesem Hintergrund wollen wir uns den Fortschritt der Bereitstellungen ansehen.

Nachdem wir nun einen Gesamtüberblick haben, wollen wir uns einige genaueren Details zu dem jetzt weit verbreiteten X25519MLKEM768 ansehen.

Zuerst der Post-Quanten-Bereich. ML-KEM wurde unter dem Namen CRYSTALS-Kyber eingereicht. Obwohl es sich um einen US-Standard handelt, arbeiten die Entwickler in Industrie und Hochschulen in Frankreich, der Schweiz, den Niederlanden, Belgien, Deutschland, Kanada, China und den Vereinigten Staaten. Werfen wir einen Blick auf die Performance.

Heutzutage verwendet die überwiegende Mehrheit der Clients die traditionelle Schlüsselvereinbarung X25519. Vergleichen wir das mit ML-KEM.

^{Größe und CPU im Vergleich zwischen X25519 und ML-KEM. Die Performance variiert je nach Hardwareplattform und Implementierungsbeschränkungen erheblich und sollte nur als grober Richtwert betrachtet werden.}

ML-KEM-512, -768 und -1024 sollen ebenso resistent gegen (Quanten-)Angriffe wie AES-128, -192 bzw. -256 sein. Selbst auf AES-128-Ebene ist ML-KEM viel größer als X25519 und benötigt 800 + 768 = 1.568 Byte über die Leitung, während X25519 lediglich 64 Byte benötigt.

Andererseits ist selbst ML-KEM-1024 in der Regel deutlich schneller als X25519, obwohl dies stark von der jeweiligen Plattform und Implementierung abhängen kann.

Wir nutzen diesen Geschwindigkeitsvorteil noch nicht. Wie viele andere Early Adopter gehen wir gerne auf Nummer sicher und setzen eine hybride Schlüsselvereinbarung ein, die X25519 und ML-KEM-768 kombiniert. Diese Kombination mag Sie aus zwei Gründen überraschen.

1. Warum X25519 („128 Bit Sicherheit“) mit ML-KEM-768 („192 Bit Sicherheit“) kombinieren?

2. Warum sollte man sich mit dem nicht-postquanten X25519 befassen?

Die scheinbare Diskrepanz des Sicherheitsniveaus ist eine Absicherung gegen Fortschritte in der Kryptoanalyse bei gitterbasierter Kryptografie. In die Sicherheit (nicht Post-Quanten) von X25519 setzt großes Vertrauen: Die Anpassung an AES-128 ist mehr als ausreichend. Obwohl wir uns heute der Sicherheit von ML-KEM-512 sicher fühlen, könnte sich die Kryptoanalyse in den kommenden Jahrzehnten verbessern. Daher möchten wir vorerst eine Reserve behalten.

Die Einbeziehung von X25519 hat zwei Gründe. Erstens besteht immer die geringe Wahrscheinlichkeit, dass ein Durchbruch alle ML-KEM-Varianten als unsicher erweist. In diesem Fall bietet X25519 weiterhin nicht-post-quantensichere Sicherheit, und unsere Post-Quanten-Migration hat die Situation nicht verschlimmert.

Wichtiger ist, dass wir uns nicht nur um Angriffe auf den Algorithmus, sondern auch auf die Implementierung kümmern. Ein bemerkenswertes Beispiel, bei dem wir einem Desaster entgangen sind, ist das von KyberSlash, einer Timing-Attacke, die viele Implementierungen von Kyber (einer früheren Version von ML-KEM) betraf, einschließlich unserer eigenen. Glücklicherweise hat KyberSlash keinen Einfluss auf Kyber, da es in TLS verwendet wird. Ein ähnlicher Implementierungsfehler, der sich tatsächlich auf TLS auswirken würde, würde wahrscheinlich einen aktiven Angreifer erfordern. In diesem Fall wäre es wahrscheinlich, dass der Angreifer nicht versucht, Daten nach Jahrzehnten zu entschlüsseln, sondern eher, ein Cookie oder ein anderes Token zu stehlen oder eine böswillige Nutzlast einzuschleusen. Die Einbeziehung von X25519 verhindert einen solchen Angriff.

Wie gut funktionieren ML-KEM-768 und X25519 in der Praxis zusammen?

Google war sich möglicher Kompatibilitäts- und Performance-Probleme bewusst und startete bereits 2016 ein erstes Experiment mit Post-Quanten-Kryptographie, im selben Jahr, in dem das NIST seinen Wettbewerb startete. Im Jahr 2018 folgte ein zweites größeres gemeinsames Experiment von Cloudflare und Google. Wir haben zwei verschiedene hybride Post-Quanten-Schlüsselvereinbarungen getestet: CECPQ2, eine Kombination aus dem gitterbasierten NTRU-HRSS und X25519, und CECPQ2b, eine Kombination aus dem isogenie-basierten SIKE und X25519. NTRU-HRSS ist ähnlich groß wie ML-KEM, stellt für die Client-Seite aber eine etwas höhere Rechenleistung dar. SIKE hingegen hat sehr kleine Schlüssel, ist rechenaufwendig und wurde 2022 vollständig kompromittiert. In Bezug auf die TLS-Handshake-Zeiten hat X25519+NTRU-HRSS sehr gut abgeschnitten.

Leider ist bei einem kleinen, aber erheblichen Teil der Clients die Verbindung mit NTRU-HRSS unterbrochen. Der Grund: die Größe der NTRU-HRSS-Keyshares. In der Vergangenheit passte beim Erstellen einer TLS-Verbindung die erste Nachricht, die vom Client gesendet wurde, das sogenannte ClientHello, fast immer in ein einzelnes Netzwerkpaket. Die TLS-Spezifikation sieht ein größeres ClientHello vor, dies wurde jedoch bisher kaum genutzt. Die Protokollverknöcherung greift erneut, da einige Middleboxes, Load Balancer und andere Software stillschweigend davon ausgehen, dass das ClientHello immer in ein einzelnes Paket passt.

In den darauffolgenden Jahren experimentierten wir kontinuierlich mit PQ, wechselten 2022 zu Kyber und 2024 zu ML-KEM. Chrome hat großartige Arbeit bei der Kontaktaufnahme mit Anbietern geleistet, deren Produkte nicht kompatibel waren. Ohne diese Kompatibilitätsprobleme hätte Chrome die Post-Quanten-Schlüsselvereinbarung wahrscheinlich fünf Jahre früher eingeführt. Es dauerte bis März 2024, bis Chrome sich sicher genug fühlte, die Post-Quanten-Schlüsselvereinbarung standardmäßig auf Desktop-Computern zu aktivieren. Danach haben sich neben Chrome viele andere Clients und alle wichtigen Browser der standardmäßigen Aktivierung der Post-Quanten-Schlüsselvereinbarung angeschlossen. Eine unvollständige Zeitleiste:

Juli 2016	Das erste Experiment von Chrome mit PQ (CECPQ)
Juni 2018	Cloudflare / Google-Experiment (CECPQ2)
Oktober 2022	Cloudflare aktiviert PQ standardmäßig auf der Serverseite
November 2023	Chrome erhöht PQ auf Desktops auf 10 %
März 2024	Chrome aktiviert PQ standardmäßig auf dem Desktop
August 2024	Go aktiviert PQ standardmäßig
November 2024	Chrome aktiviert PQ standardmäßig auf Android und Firefox auf Desktop.
April 2025	OpenSSL aktiviert PQ standardmäßig
Oktober 2025	Apple führt PQ standardmäßig mit der Veröffentlichung von iOS/iPadOS/macOS 26 ein.

Es ist bemerkenswert, dass eine zeitliche Verzögerung zwischen der Aktivierung von PQ in Chrome auf Desktop- und Android-Geräten besteht. Obwohl ML-KEM, wie in den Grafiken dargestellt, keine großen Auswirkungen auf die Performance hat, ist sie sicherlich nicht unerheblich, insbesondere bei den langsameren Verbindungen, die auf Mobilgeräten häufiger vorkommen, und es waren weitere Überlegungen erforderlich, um fortzufahren.

Aber jetzt sind wir endlich da angekommen: Über 50 % (Tendenz steigend!) des menschlichen Datenverkehrs ist gegen „Store now, decrypt later“ geschützt, wodurch Post-Quanten-Schlüsselvereinbarungen zur neuen Sicherheitsgrundlage für das Web werden

Browser sind eine Seite der Medaille, was ist mit Servern?

Bereits 2022 haben wir die Serverseite für die Post-Quanten-Schlüsselvereinbarung für praktisch alle Kunden aktiviert. Google hat dies im Jahr 2023 für die meisten seiner Server getan (mit Ausnahme von GCP). Seitdem sind viele gefolgt. Jan Schaumann hat regelmäßige Scans der Top-100.000-Domains veröffentlicht. In seinem Beitrag vom September 2025berichtet er, dass jetzt 39 % den PQ-Ansatz unterstützen, ein Anstieg von 28 % innerhalb von sechs Monaten. In seiner Umfrage sehen wir nicht nur die zunehmende Unterstützung großer Serviceprovider wie Amazon, Fastly, Squarespace, Google und Microsoft, sondern auch eine Zunahme von selbst gehosteten Servern bei Hetzner und OVHcloud.

Dies ist das öffentlich zugängliche Web. Was ist mit Servern hinter einem Dienst wie Cloudflare?

Im September 2023 haben wir die Unterstützung für unsere Kunden hinzugefügt, um die Post-Quanten-Schlüsselvereinbarung für Verbindungen von Cloudflare zu ihren Ursprungs-Servern zu aktivieren. Das ist Verbindung (3) im folgenden Diagramm:

^{Typischer Verbindungsablauf, wenn ein Besucher eine nicht zwischengespeicherte Seite anfordert.}

Im Jahr 2023 unterstützten nur 0,5 % der Ursprungsserver die Post-Quanten-Schlüsselvereinbarung. Daran hat sich bis einschließlich 2024 nicht viel geändert. Dieses Jahr, im Jahr 2025, sehen wir, dass die Unterstützung mit der Einführung der Softwareunterstützung langsam zunimmt und wir jetzt bei 3,7 % liegen.

^{Anteil der Ursprünge, die die Post-Quanten-Schlüsselvereinbarung X25519MLKEM768 unterstützen.}

3,7 % klingt im Vergleich zu den vorherigen 50 % bzw. 39 % für Clients bzw. öffentliche Server wenig beeindruckend, ist aber dennoch nicht zu verachten. Die Vielfalt ist bei den Ursprüngen viel größer als bei den Kunden: Es müssen viel mehr Menschen aktiv werden, damit sich diese Zahl erhöht. Aber es ist immer noch mehr als eine siebenfache Steigerung, und vergessen wir nicht, dass wir im Jahr 2024 das Erreichen von 1,8 % Kundensupport gefeiert haben. Für Kunden ist es nicht immer einfach, Ursprünge überhaupt zu aktualisieren. Bedeutet das, dass Sie die Post-Quanten-Sicherheit verpassen? Nein, nicht unbedingt: Sie können die Verbindung zwischen Cloudflare und Ihrem Ursprungsserver sichern, indem Sie Cloudflare Tunnel als Sidecar zu Ihrem Ursprungsserver einrichten.

Unterstützung ist gut und schön, aber wie wir bei Browser-Experimenten gesehen haben, ist die Protokollverknöcherung ein großes Problem. Wie sieht es mit Ursprüngen aus? Nun, das kommt darauf an.

Es gibt zwei Möglichkeiten, die Post-Quanten-Schlüsselvereinbarung zu aktivieren: die schnelle Methode und die langsame, aber sicherere Methode. In beiden Fällen können sie, wenn der Ursprung kein Post-Quanten-Verfahren unterstützt, sicher auf die traditionelle Schlüsselvereinbarung zurückgreifen. Die Details erläutern wir in diesem Blogbeitrag, aber kurz gesagt: In der schnellen Variante senden wir die Post-Quanten-Schlüssel sofort, in der sichereren Variante verzögern wir dies um eine Round-Trip-Zeit mithilfe von HelloRetryRequest. Alle gängigen Browser nutzen die schnelle Methode.

Wir haben regelmäßig alle Ursprünge gescannt, um zu sehen, was sie unterstützen. Die gute Nachricht ist, dass alle Ursprünge die sichere, aber langsame Methode unterstützen. Die schnelle Methode schnitt nicht so gut ab, da wir festgestellt haben, dass 0,05 % der Verbindungen abbrechen würden. Das ist zu hoch, um die schnelle Methode standardmäßig zu aktivieren. Wir haben PQ für Ursprünge standardmäßig mit der sichereren Methode für alle Nicht-Enterprise-Kunden aktiviert. Enterprise-Kunden können sich dafür entscheiden.

Wir sind jedoch erst zufrieden, wenn es schnell ist und für alle aktiviert ist. Deshalb werden wir Post-Quanten für Ursprünge mit der schnellen Methode automatisch für alle Kunden aktivieren, wenn unsere Scans zeigen, dass dies sicher ist.

Bisher haben wir nur über Verbindungen zwischen Cloudflare und externen Parteien gesprochen. Es gibt auch viele interne Verbindungen innerhalb von Cloudflare (in den obigen Diagrammen mit 2 markiert). Im Jahr 2023 haben wir große Anstrengungen unternommen, um unsere internen Verbindungen auf Post-Quanten-Schlüsselvereinbarung umzustellen. Im Vergleich zu allen anderen Post-Quanten-Bemühungen, denen wir nachgehen, war dies mit Abstand die größte Aufgabe: Wir haben jedes Engineering-Team im Unternehmen gebeten, seine aktuelle Arbeit zu unterbrechen, eine Bestandsaufnahme der Daten und Verbindungen vorzunehmen, die ihre Produkte sichern, und diese auf Post-Quanten-Schlüsselvereinbarungen umzustellen. In den meisten Fällen war das Upgrade einfach. Tatsächlich wurden viele Teams bereits durch Software-Updates aktualisiert. Dennoch kann es eine Weile dauern, bis man merkt, dass man schon fertig ist! Positiv ist zu vermerken, dass wir bei diesem Push keine Performance- oder Ossifizierungsprobleme festgestellt haben.

Wir haben die meisten internen Verbindungen aktualisiert, aber ein großer Rest verbleibt, an dem wir weiterhin arbeiten. Die wichtigste Verbindung, die wir im Jahr 2023 nicht aktualisieren konnten, ist die Verbindung zwischen dem WARP-Client und Cloudflare. Im September 2025 haben wir es aufgerüstet, indem wir von Wireguard zu QUIC gewechselt sind.

Wie wir gesehen haben, war die Post-Quanten-Schlüsselvereinbarung trotz anfänglicher Schwierigkeiten mit der Protokollverknöcherung unkompliziert zu implementieren. In den allermeisten Fällen handelt es sich um ein unproblematisches Software-Update. Und mit 50 % Bereitstellung (Tendenz steigend) ist dies die neue Sicherheitsgrundlage für das Internet.

Wenden wir uns der zweiten, schwierigeren Migration zu.

Nun konzentrieren wir uns auf die Aktualisierung der im Internet verwendeten Signaturen.

Letztes Jahr, im November 2024, haben wir einen langen und tieferen Einblick in das Feld der Post-Quanten-Signaturschemata geschrieben. Das meiste davon ist noch aktuell, aber es gab einige interessante Entwicklungen. Hier werden wir nur einige Highlights und spannende Neuerungen des letzten Jahres behandeln.

Beginnen wir mit der Bewertung der Post-Quanten-Signaturen, die heute auf dem Sicherheitsniveau von AES-128 verfügbar sind: ML-DSA-44 und die beiden Varianten von SLH-DSA. Wir verwenden ML-DSA-44 als Basis, da dieses Schema anfänglich die weitverbreitetste Anwendung finden wird. Zum Vergleich berücksichtigen wir auch die bewährten Ed25519 und RSA-2048, die heute weit verbreitet sind, sowie FN-DSA-512, das in Kürze standardisiert werden wird, und eine Auswahl von neun vielversprechenden Signaturschemata für TLS aus dem Signaturen-Onramping.

^{Vergleich verschiedener Signaturschemata auf dem Sicherheitsniveau von AES-128. Die CPU-Zeiten variieren je nach Plattform und Implementierungsbeschränkungen erheblich und sollten nur als grober Richtwert betrachtet werden. ⚠️ FN-DSA-Signaturzeit bei Verwendung schneller, aber gefährlicher Gleitkommaarithmetik – siehe Warnung unten. ⚠️ SQISign-Signierung ist nicht sicher gegen Zeit-Seitenkanalangriffe (Timing Side-Channels).}

Es ist sofort ersichtlich, dass keines der postquanten-sicheren Signaturschemata auch nur annähernd als Drop-in-Ersatz für Ed25519 (vergleichbar mit ECDSA P-256) infrage kommt, da die meisten Signaturen schlichtweg deutlich größer sind. Ausnahmen bilden SQISign, MAYO, SNOVA und UOV aus der Onramp-Runde – doch auch sie sind weit von einer idealen Lösung entfernt: MAYO, SNOVA und UOV haben große öffentliche Schlüssel, während SQISign enorm rechenintensiv ist.

Etwas vorausschauend: Das Beste aus dem ersten Wettbewerb scheint FN-DSA-512 zu sein. Die Signaturen und der öffentliche Schlüssel von FN-DSA-512 sind zusammen nur 1.563 Byte groß, bei einer einigermaßen akzeptablen Signierzeit. FN-DSA hat jedoch eine Achillesferse – für eine akzeptable Signier-Performance ist eine schnelle Gleitkommaarithmetik erforderlich. Ohne dies ist das Signieren etwa 20-mal langsamer. Aber Geschwindigkeit allein reicht nicht aus – die Gleitkomma-Arithmetik muss in konstanter Zeit ablaufen. Andernfalls kann der private Schlüssel von FN-DSA durch das Timing der Signaturerstellung rekonstruiert werden. Sichere Implementierungen von FN-DSA zu schreiben, hat sich als äußerst schwierig erwiesen, was FN-DSA besonders dann gefährlich macht, wenn Signaturen spontan erzeugt werden – etwa im Rahmen eines TLS-Handshakes. Wichtig ist, dass dies ausschließlich das Signieren betrifft: Die Verifikation von FN-DSA erfordert keine Gleitkomma-Arithmetik (und bei der Verifikation gibt es ohnehin keinen privaten Schlüssel, der kompromittiert werden könnte).

Der größte Schwachpunkt bei der Migration des Internets zu Post-Quanten-Signaturen ist die große Anzahl an Signaturen selbst bei einer einzigen Verbindung. Wenn Sie diese Website zum ersten Mal besuchen, senden wir fünf Signaturen und zwei öffentliche Schlüssel.

Der Großteil dieser Signaturen entfällt auf die Zertifikatskette: Die CA signiert das Zwischenzertifikat, dieses wiederum das Endzertifikat, und dieses signiert schließlich das TLS-Transkript, um die Authentizität des Servers zu bestätigen. Wer mitgezählt hat: Zwei Signaturen fehlen noch.

Diese sind für die SCTs bestimmt, die für die Transparenz der Zertifikate erforderlich sind. Zertifikatstransparenz (Certificate Transparency, CT) ist ein wichtiger, aber weniger bekannter Bestandteil der Web-PKI, dem Ökosystem, das Browserverbindungen absichert. Ziel ist es, jedes ausgestellte Zertifikat öffentlich zu protokollieren, sodass Fehlerausstellungen im Nachhinein erkannt werden können. Es ist das System, das hinter crt.sh und Cloudflare Radar steht. CT hat seinen Wert erneut unter Beweis gestellt, indem ein abtrünniges Zertifikat für 1.1.1.1 aufgedeckt wurde.

Certificate Transparency funktioniert, indem unabhängige Parteien CT logs betreiben. Vor der Ausstellung eines Zertifikats muss eine Zertifizierungsstelle dieses zuerst an mindestens zwei verschiedene CT-Protokolle übermitteln. Ein SCT ist eine Signatur eines CT-Protokolls, die als Nachweis dient, eine Art Bestätigung, dass das Zertifikat protokolliert wurde.

Bei der Verwendung einer Signatur gibt es zwei Aspekte, die hervorzuheben sind: ob der öffentliche Schlüssel in der Signatur enthalten ist und ob die Signatur online oder offline ist.

Für die SCTs und die Signatur der Wurzel über das Intermediate wird der öffentliche Schlüssel während des Handshakes nicht übertragen. Daher eignen sich hierfür besonders Signaturschemata mit kleinen Signaturen, aber größeren öffentlichen Schlüsseln – etwa MAYO, SNOVA oder UOV. Für alle anderen Signaturen hingegen wird der öffentliche Schlüssel mitübertragen, weshalb dort vor allem die kombinierte Größe aus öffentlichem Schlüssel und Signatur entscheidend ist.

Die Handshake-Signatur ist die einzige Signatur, die online erstellt wird. Alle anderen Signaturen werden im Voraus erstellt.  Die Handshake-Signatur wird nur einmal erstellt und verifiziert, während die anderen Signaturen typischerweise von verschiedenen Clients mehrmals verifiziert werden. Das bedeutet, dass es für die Handshake-Signatur vorteilhaft ist, die Signier- und Verifizierungszeit auszugleichen, da beide im hot path liegen, während es sich für die anderen Signaturen lohnt, eine bessere Verifizierungszeit auf Kosten einer langsameren Signierung zu haben. Dies ist einer der Vorteile, die RSA bis heute gegenüber elliptischen Kurvensignaturen genießt.

Das Zusammensetzen verschiedener Signaturschemata ist eine interessante Herausforderung, bringt aber auch einige Nachteile mit sich. Die Verwendung mehrerer Verfahren vergrößert die Angriffsfläche, denn eine Schwachstelle in nur einem Algorithmus oder dessen Implementierung gefährdet das gesamte System. Zudem muss das gesamte Ökosystem mehrere Algorithmen implementieren und optimieren, was einen erheblichen Aufwand bedeutet.

Welche sinnvollen Kombinationen sollten wir also ausprobieren?

Angesichts der heute verfügbaren Entwürfe haben wir nicht viele Möglichkeiten.

Wenn wir einfach für alle Signaturen auf ML-DSA-44 umstellen, kommen 15 KB an Daten hinzu, die während des TLS-Handshakes vom Server zum Client übertragen werden müssen. Ist das viel? Wahrscheinlich. Darauf gehen wir später noch ein.

Wenn wir noch etwas warten und alles außer der Handshake-Signatur durch FN-DSA-512 ersetzen, werden nur 7 kB hinzugefügt. Das ist viel besser, aber ich muss noch einmal sagen, dass es schwierig ist, eine FP-DSA-512-Signierung sicher zu implementieren, ohne die Seitenkanäle zu stoppen. Ein weiterer Weg, sich heutzutage selbst ein Bein zu stellen, ist die Verwendung zustandsbehafteter Hash-basierter Signaturen – wie wir hier erklären. Insgesamt bieten sowohl FN-DSA-512 als auch zustandsbehaftete Hash-basierte Signaturen einen klaren Leistungsvorteil gegenüber ML-DSA-44 – sind jedoch schwer sicher zu handhaben.

Es gibt einige vielversprechende neue Signaturverfahren, die beim NIST On-Ramp eingereicht wurden.

Rein von den Größen her ist SQISign I der klare Gewinner und übertrifft sogar RSA-2048. Leider ist der Rechenaufwand für die Signierung und insbesondere für die Verifizierung zu hoch. SQISign ist in Bezug auf die Implementierungssicherheit schlechter aufgestellt als FN-DSA: Die Lösung ist sehr kompliziert, und es ist unklar, wie eine Signierung in konstanter Zeit durchgeführt werden kann. Für Nischenanwendungen könnte SQISign nützlich sein, aber für eine allgemeine Akzeptanz müssen die Verifizierungszeiten deutlich verbessert werden, selbst wenn dies eine größere Signatur erfordert. In den letzten Jahren wurden erstaunliche Fortschritte bei der Verbesserung der Verifizierungszeit und der Vereinfachung des Algorithmus erzielt; ebenso wurde die Implementierungssicherheit für (Varianten von) SQISign verbessert. Sie sind noch nicht so weit, aber die Lücke hat sich viel stärker verringert, als wir erwartet hätten. Wenn das Verbesserungstempo anhält, könnte ein zukünftiges SQISign durchaus für TLS geeignet sein.

Ein konservativer Anwärter ist UOV (Unbalanced Oil and Vinegar). Es handelt sich um ein älteres, multivariates Schema mit einem großen öffentlichen Schlüssel (66,5 kB), aber kleinen Signaturen (96 Byte). Im Laufe der Jahrzehnte gab es viele Versuche, den öffentlichen UOV-Schlüsseln eine Struktur zu verleihen, um ein besseres Gleichgewicht zwischen der Größe des Öffentlichen Schlüssels und der Signatur zu erzielen. Viele dieser sogenannten strukturierten multivariaten Verfahren, darunter Rainbow und GeMMS, wurden leider spektakulär „mit einem Laptop über das Wochenende“ geknackt. MAYO und SNOVA, auf die wir gleich noch eingehen werden, sind die neuesten Versuche für strukturierte multivariate Analysen. UOV selbst ist weitgehend unbeschadet geblieben. Überraschenderweise entdeckte Lars Ran im Jahr 2025 einen völlig neuen „Wedges“-Angriff auf UOV. UOV hat keinen großen Einfluss, obwohl SNOVA und MAYO stärker betroffen sind. Bemerkenswert an diesem Angriff ist, dass er auf einer relativ einfachen Idee basiert: Es ist überraschend, dass er nicht schon früher entdeckt wurde. Um nun auf die Performance zurückzukommen: Wenn wir UOV für den Stamm und SCTs mit ML-DSA-44 für die anderen kombinieren, erhalten wir nur 10 kB – nahe an FN-DSA-512.

Nun kommen wir zum Hauptereignis:

Betrachtet man die heutige Liste, sehen MAYO und insbesondere SNOVA aus Performance-Gesichtspunkten großartig aus. Letztes Jahr lagen SNOVA und MAYO in Bezug auf die Performance enger beieinander, aber sie haben sich deutlich voneinander entfernt.

MAYO wurde von dem Kryptografen entwickelt, der Rainbow geknackt hat. Als strukturiertes multivariates Verfahren erfordert MAYO eine besonders sorgfältige Prüfung der Sicherheit – doch sofern es nicht geknackt wird, ist sein Nutzen äußerst attraktiv. MAYO ermöglicht eine fein abgestimmte Abwägung zwischen Signatur- und öffentlicher Schlüsselgröße. Für die Einreichung schlugen die Autoren zwei konkrete Varianten vor: MAYO_one mit ausgewogenem Verhältnis (Signatur: 454 Byte, Public Key: 1,4 kB) und MAYO_two mit kleineren Signaturen (216 Byte) und einem noch akzeptablen Public Key (4,3 kB). Die Verifizierungszeiten sind ausgezeichnet, während die Signierzeiten etwas langsamer als bei ECDSA sind, aber weitaus besser als bei RSA. Wenn wir beide Varianten auf die offensichtliche Weise kombinieren, betrachten wir lediglich 4,3 kB. Diese Zahlen sind etwas höher als im Vorjahr, da MAYO seine Parameter erneut leicht angepasst hat, um neu entdeckte Angriffe zu berücksichtigen.

SNOVA war im Laufe des Wettbewerbs härter unter Beschuss als MAYO. Die Reaktion von SNOVA war aggressiver: Anstatt lediglich Parameter zur Anpassung zu optimieren, wurden auch größere Änderungen an den internen Systemen des Schemas vorgenommen, um die Angriffe abzuwehren und zusätzlich eine Performance zu erzielen. Wenn wir SNOVA_(37,17,16,2) und SNOVA_(24,5,23,4) auf die offensichtliche Weise kombinieren, erhalten wir gerade einmal erstaunliche 2,1 kB.

Wir sehen, dass sich ein Kräftemessen zwischen dem riskanten, aber viel kleineren SNOVA und dem konservativen, aber langsameren MAYO abzeichnet. Beide bieten eine sehr gute Performance, und bei beiden ist der Einsatz jetzt zu riskant. Rans neuer Wedge-Angriff ist ein Beispiel dafür, dass das Gebiet der multivariaten Kryptoanalyse immer noch Überraschungen birgt und mehr Aufmerksamkeit und Zeit benötigt. Es ist noch zu früh, um einen Gewinner zwischen SNOVA und MAYO zu bestimmen. Man lasse sie weiterhin konkurrieren. Selbst wenn sie sich als sicher erweisen sollten, wird voraussichtlich keine von beiden bis 2029 standardisiert sein. Das bedeutet, dass wir uns bei der anfänglichen Migration zur Post-Quanten-Authentifizierung nicht auf sie verlassen können.

Ist die Größe von 15 kB für ML-DSA-44 wirklich so schlimm?

Im Durchschnitt werden etwa 18 Millionen TLS-Verbindungen pro Sekunde mit Cloudflare aufgebaut. Für ein Upgrade auf ML-DSA würden jeweils 2,1 Tbit/s benötigt, was 0,5 % unserer aktuellen gesamten Netzwerkkapazität entsprechen würde. Bisher kein Problem. Die Frage ist, wie sich diese zusätzlichen Bytes auf die Performance auswirken.

Für den Austausch von ML-DSA-44 werden zusätzlich 15 kB benötigt. Das ist viel im Vergleich zu einem heutigen typischen Handshake, aber wenig im Vergleich zu dem JavaScript und den Bildern, die viele Webseiten ausliefern. Der springende Punkt ist, dass die Änderung, die wir hier vornehmen müssen, jede einzelne TLS-Verbindung betrifft, unabhängig davon, ob sie für eine umfangreiche Website oder einen zeitkritischen API-Aufruf verwendet wird. Es geht also nicht nur darum, etwas länger zu warten. Wenn Sie einen lückenhaften Mobilfunkempfang haben, können diese zusätzlichen Daten den Unterschied zwischen dem Laden einer Seite und einem Verbindungs-Timeout ausmachen. (Nebenbei bemerkt, wenn wir schon über Overhead sprechen: Viele Apps führen erstaunlich viele TLS-Handshakes durch.)

Genau wie bei der Schlüsselvereinbarung ist die Performance nicht unser einziges Anliegen: Wir wollen in erster Linie, dass die Verbindung überhaupt zustande kommt. Im Jahr 2021 haben wir ein Experiment durchgeführt, bei dem die Zertifikatskette künstlich vergrößert wurde, um größere Post-Quanten-Zertifikate zu simulieren. Wir fassen das Ergebnis hier zusammen. Ein wichtiger Aspekt ist, dass einige Clients oder Middleboxes keine Zertifikatsketten größer als 10 KB mögen. Bei einer Migrationsstrategie mit einem einzigen Zertifikat ist dies problematisch. Bei diesem Ansatz installiert der Server ein einzelnes traditionelles Zertifikat, das ein separates Post-Quanten-Zertifikat in einer sogenannten nicht kritischen Erweiterung installiert. Ein Client, der Post-Quanten-Zertifikate nicht unterstützt, ignoriert die Erweiterung. Bei diesem Ansatz führt die Installation des einzelnen Zertifikats sofort dazu, dass alle Clients mit Kompatibilitätsproblemen beeinträchtigt werden, was die Sache von vornherein zum Scheitern verurteilt. Auch auf der Performance-Seite gibt es aufgrund des anfänglichen Überlastungsfensters einen deutlichen Performanceabfall bei 10 kB.

Sind 9 KB zu viel? Die Verlangsamung der TLS-Handshake-Zeit würde etwa 15 % betragen. Wir halten Letzteres für machbar, aber alles andere als ideal: Eine solche Verlangsamung ist spürbar, und die Leute könnten die Bereitstellung von Post-Quanten-Zertifikaten aufschieben, bis es zu spät ist.

Chrome ist vorsichtiger und hat 10 % als Ziel für die maximale Regression der TLS-Handshake-Zeit festgelegt. Sie berichten, dass die Bereitstellung von Post-Quanten-Schlüsselvereinbarungen bereits zu einer Verlangsamung der TLS-Handshake-Zeit von 4 % geführt hat, aufgrund der zusätzlichen 1,1 kB vom Server zum Client und 1,2 kB vom Client zum Server. Diese Verlangsamung ist proportional größer als die 15 %, die wir bei 9 kB festgestellt haben. Dies könnte jedoch an langsameren Upload- als Download-Geschwindigkeiten liegen. 

Der Fokus auf TLS-Handshake-Zeiten stieß auf Widerstand. Ein Argument ist, dass die Sitzungswiederaufnahme das erneute Senden der Zertifikate überflüssig macht. Ein zweites Argument ist, dass die Datenmenge, die für den Besuch einer typischen Website benötigt wird, die zusätzlichen Bytes für Post-Quanten-Zertifikate in den Schatten stellt. Ein Beispiel ist diese Publikation aus dem Jahr 2024, in der Amazon-Forscher die Auswirkungen großer Post-Quanten-Zertifikate auf datenlastige TLS-Verbindungen simuliert haben. Sie argumentieren, dass typische Verbindungen mehrere Anfragen und Hunderte von Kilobyte übertragen, und dass bei solchen Verbindungen die Verlangsamung des TLS-Handshake kaum ins Gewicht fällt.

Sind die Wiederaufnahme einer Sitzung und Hunderte von Kilobyte über eine Verbindung jedoch typisch? Wir möchten Ihnen mitteilen, was wir sehen. Wir konzentrieren uns auf QUIC-Verbindungen, die wahrscheinlich von Browsern oder browserähnlichen Clients initiiert werden. Von allen QUIC-Verbindungen mit Cloudflare, die mindestens eine HTTP-Anfrage übertragen, sind 27 % Wiederaufnahmen, was bedeutet, dass Schlüsselmaterial einer früheren TLS-Verbindung wiederverwendet wird, wodurch die Übertragung von Zertifikaten vermieden wird. Die mittlere Anzahl der Bytes, die über eine wiederaufgenommene QUIC-Verbindung vom Server zum Client übertragen werden, beträgt 4,4 kB, während der Durchschnitt bei 259 kB liegt. Für Nicht-Wiederaufnahmen liegt der Median bei 8,1 kB und der Durchschnitt bei 583 kB. Dieser große Unterschied zwischen Median und Durchschnitt deutet darauf hin, dass ein kleiner Teil datenlastiger Verbindungen den Durchschnitt verfälscht. Tatsächlich übertragen nur 15,5 % aller QUIC-Verbindungen mehr als 100 kB.

Die mittlere Zertifikatskette (mit Komprimierung) beträgt heute 3,2 kB. Das bedeutet, dass fast 40 % aller Daten, die bei mehr als der Hälfte der nicht fortgesetzten QUIC-Verbindungen vom Server zum Client übertragen werden, lediglich für die Zertifikate bestimmt sind. Dies verschlimmert sich mit Post-Quanten-Algorithmen noch. Für die Mehrheit der QUIC-Verbindungen würde die Verwendung von ML-DSA-44 als direkter Ersatz für klassische Signaturen die Anzahl der übertragenen Bytes über die Lebensdauer der Verbindung mehr als verdoppeln.

Es klingt durchaus problematisch, wenn der Großteil der übertragenen Daten bei einer typischen Verbindung allein auf Post-Quanten-Zertifikate entfällt. Letztlich ist das jedoch nur ein Stellvertreter für das, was wirklich zählt: den Einfluss auf für Endnutzer relevante Kennzahlen, wie z. B. das Ladeerlebnis (etwa die Largest Contentful Paint) und den Anteil der Zertifikate am monatlichen Datenvolumen. Wir werden die Auswirkungen weiter untersuchen, um ein besseres Verständnis zu erlangen.

Der Weg zur Migration des Internets hin zu Post-Quanten-Authentifizierung ist weitaus weniger klar als bei der Schlüsselaushandlung. Wenn die Performance nicht deutlich näher an die heutiger Authentifizierung heranreicht, ist zu erwarten, dass die Mehrheit postquantische Authentifizierung deaktiviert lässt. Wird die Aktivierung bis kurz vor dem Q-Day hinausgezögert, besteht das reale Risiko, dass Probleme erst erkannt werden, wenn es zu spät ist, sie zu beheben. Daher ist es unerlässlich, die Post-Quanten-Authentifizierung so leistungsfähig zu gestalten, dass sie standardmäßig aktiviert werden kann.

Wir untersuchen verschiedene Ideen, um die Anzahl der Signaturen zu reduzieren, in aufsteigender Reihenfolge des Umfangs: Auslassen von Zwischenprodukten, KEMTLS und Merkle-Tree-Zertifikate. Wir haben diese Themen im vergangenen Jahr ausführlich behandelt. Beim letzten Punkt wurden die größten Fortschritte erzielt: Merkle-Tree-Zertifikate (MTC). In diesem Vorschlag werden im Normalfall alle Signaturen außer der Handshake-Signatur durch einen kurzen Merkle-Tree-Proof von <800 Byte ersetzt. Dies könnte durchaus eine Post-Quanten-Authentifizierung ermöglichen, die tatsächlich schneller ist als die Verwendung herkömmlicher Zertifikate heutzutage! Zusammen mit Chrome werden wir es bis Ende des Jahres ausprobieren. Mehr dazu in diesem Blogpost.

Trotz seiner Länge haben wir in diesem Blogbeitrag die Migration von TLS nur am Rande behandelt. Und selbst TLS haben wir nicht vollständig behandelt, da wir Encrypted ClientHello noch nicht besprochen haben (wir haben es nicht vergessen). Obwohl TLS wichtig ist, ist es nicht der einzige Schlüsselprotokoll für die Sicherheit des Internets. Wir möchten kurz einige weitere Herausforderungen erwähnen, können aber nicht näher ins Detail gehen. Eine besondere Herausforderung stellt DNSSEC dar, welches für die Sicherung der Auflösung von Domainnamen verantwortlich ist.

Obwohl Schlüsselaustausch und Signaturen die am weitesten verbreiteten kryptographischen Primitiven sind, beobachten wir seit einigen Jahren auch den Einsatz zunehmend esoterischer Kryptographie für fortgeschrittene Anwendungsfälle – etwa unlinkable Tokens mit Privacy Pass / PAT, anonyme Berechtigungsnachweise oder attributbasierte Verschlüsselung, um nur einige zu nennen. Für die meisten dieser fortschrittlichen kryptografischen Schemata gibt es bisher noch keine bekannte, praktikable Post-Quanten-Alternative. Allerdings gibt es zu unserer Freude große Fortschritte bei der Anonymität von Post-Quanten-Berechtigungen.

Zusammenfassend lässt sich sagen, dass man im Auge behalten sollte: Schlüsselvereinbarung und Zertifikate.

Wir empfehlen die Umstellung auf eine Post-Quanten-Schlüsselvereinbarung, um Store-Now/Decrypt-Later-Angriffe abzuwehren. Dies erfordert lediglich ein Softwareupdate auf beiden Seiten. Das bedeutet, dass Sie mit der schnellen Einführung (wir führen eine Liste) von X25519MLKEM768 in Software und Diensten bereits gegen Store-Now/Decrypt-Later geschützt sein könnten! Auf Cloudflare Radar können Sie überprüfen, ob Ihr Browser X25519MLKEM768 unterstützt; wenn Sie Firefox verwenden, gibt es eine Erweiterung, mit der Sie die Unterstützung von Websites während Ihres Besuchs überprüfen können; Sie können hier scannen, ob Ihre Website dies unterstützt; und Sie können Wireshark verwenden, um dies im Netzwerk zu überprüfen.

Das sind nur Stichproben. Für eine ordnungsgemäße Migration müssen Sie ermitteln, wo Kryptografie eingesetzt wird. Das ist eine hohe Anforderung, da die meisten Unternehmen bereits Schwierigkeiten haben, den Überblick über ihre gesamte Software, Services und externen Anbieter zu behalten. Es wird Systeme geben, die schwer zu aktualisieren sind oder externe Abhängigkeiten aufweisen, aber in vielen Fällen ist es einfach. Tatsächlich werden Sie in vielen Fällen viel Zeit investieren, um herauszufinden, dass diese bereits erledigt sind.

Da das Herausfinden, was zu tun ist, den Großteil der Arbeit ausmacht, liegt es nahe, dies als ersten Meilenstein auszugliedern: zunächst eine detaillierte Bestandsaufnahme erstellen – die sogenannte Cryptographic Bill of Materials (CBOM). Doch eine solche Bestandsaufnahme darf kein Selbstzweck werden: Wir müssen das eigentliche Ziel im Blick behalten. Die meisten Fälle sind einfach: Wenn klar ist, wie man migrieren kann, sollte man nicht zögern oder auf später verschieben, sondern direkt umsetzen. Das bedeutet nicht, dass es schnell geht – es ist ein Marathon, kein Sprint.Aber man wird überrascht sein, wie viel sich bereits mit den ersten Schritten erreichen lässt.

Zertifikate. Zum Zeitpunkt des Verfassens dieses Blogbeitrags im Oktober 2025 stehen die endgültigen Standards für Post-Quanten-Zertifikate noch nicht fest. Hoffentlich dauert die Lösung nicht zu lange. Aber es gibt viel, was Sie jetzt tun können, um sich auf Post-Quanten-Zertifikate vorzubereiten, was Sie keinesfalls bereuen werden. Halten Sie die Software auf dem neuesten Stand. Automatisieren Sie die Ausstellung von Zertifikaten. Stellen Sie sicher, dass Sie mehrere Zertifikate installieren können.

Wenn Sie Bedenken hinsichtlich der Protokollverknöcherung haben, gibt es keinen Grund zu warten: Die finalen Post-Quanten-Standards werden sich nicht wesentlich von dem Entwurf unterscheiden. Sie können heute vorläufige Implementierungen (oder große Dummy-Zertifikate) testen.

Die Post-Quanten-Migration ist etwas Besonderes. Wenn die Kryptografie kompromittiert wird, geschieht dies normalerweise entweder plötzlich oder so allmählich, dass es eine Zeit lang leicht zu ignorieren ist. In beiden Fällen werden Migrationen letztendlich übereilt durchgeführt. Angesichts der Quantenbedrohung wissen wir mit Sicherheit, dass wir einen Großteil der Kryptographie ersetzen müssen, aber wir haben auch noch Zeit. Wir laden Sie ein, dies nicht nur als eine lästige Pflicht zu sehen, sondern als eine Chance: Wir müssen jetzt Wartungsarbeiten an vielen Systemen durchführen, die selten benutzt werden. Anstelle von reinen Hotfixes bietet sich jetzt die Gelegenheit, frühere Entscheidungen zu überdenken.

Zumindest, wenn Sie jetzt anfangen. Wir wünschen Ihnen viel Erfolg bei Ihrer Migration. Sollten Sie auf Probleme stoßen, wenden Sie sich bitte an: [email protected]