Warum Post-Quantum-Signaturen die TLS-Handshake-Grenzen sprengen

Beim Übergang zur Post-Quanten-Kryptografie sind manche Aspekte einfacher als andere. Die Umstellung der Schlüsselaushandlung auf einen quantenresistenten Ansatz erforderte zwar einiges an Arbeit, führte aber zu einer Lösung (einem Hybrid-Ansatz, der elliptische Kurven mit ML-KEM kombiniert), die ohne größere Schwierigkeiten realisiert wurde. Anders sieht es bei Zertifikaten und Authentifizierung aus: Hier wird es deutlich aufwendiger – und der Grund dafür sind die Unterschiede in der Signaturgröße zwischen den heute verwendeten (traditionellen) Algorithmen und den zukünftigen (post-quanten) Algorithmen, die wir einsetzen wollen.

Wann immer wir etwas entwerfen – zum Beispiel ein kryptografisches Protokoll – berücksichtigen wir verschiedene Faktoren, wägen die Möglichkeiten samt Vor- und Nachteilen ab und treffen Entscheidungen, um die uns gesetzten Beschränkungen einzuhalten. Sicherheit ist dabei meist nicht verhandelbar (sie bewegt sich aber oft auf einem Spektrum), doch auch die Performance ist ein wichtiger Faktor. Historisch gesehen mögen wir Sicherheit, aber wir lieben schnelle Kryptografie.

Manches zieht einen in seinen Bann – so auch die elliptische Kryptografie. Sie schien das perfekte Werkzeug: sicher und performant, mit schnellen Operationen und kleinen Signaturgrößen. Im Lauf der Jahre wechselten immer mehr Protokolle zu dieser Familie kryptografischer Algorithmen, bis sie praktisch überall verbaut waren. Anforderungen ließen sich einfach durch eine weitere Signatur lösen – bis die Entwicklung durch Quantencomputer abrupt gestoppt wurde. (Falls du eine Auffrischung brauchst: Unser Guide to Post-Quantum Cryptography ist eine gute und angenehm leicht verständliche Lektüre.)

Die durch die Bedrohung eines kryptografisch relevanten Quantencomputers (CRQC) forcierte Umstellung der Kryptografie auf Post-Quantum-Verfahren zeigt eindrücklich, dass es in der digitalen Welt keine inhärente Sicherheit gibt. Es sind alles "Spielchen": Wir spielen mit Mathematik und finden interessante Eigenschaften, die wir dann auf nützliche Weise kombinieren. Was wir Sicherheit nennen, ist vergänglich, denn der Stand der Technik entwickelt sich stetig weiter. Du hast vielleicht schon gehört: Angriffe werden immer besser.

Unsere klassischen Computer können die Mathematik hinter RSA und ECDSA nicht brechen, aber Quantencomputer können es sehr wohl. Um uns gegen letztere zu schützen, spielen wir weitere Spiele – mit anderer Mathematik. Wir entwickeln neue Algorithmen. Der einzige Haken: Die Eigenschaften dieser neuen Algorithmen unterscheiden sich. In diesem Fall bleibt die Performance vergleichbar, aber Schlüssel und Signaturen benötigen deutlich mehr Speicherplatz.

In der folgenden Tabelle vergleichen wir die Schlüsselaspekte von ML-DSA mit traditioneller Kryptografie. Es werden Werte für gängige Algorithmen und Sicherheitsstärken abgebildet, wie sie üblicherweise in Leaf-Zertifikaten und Intermediates (diese nutzen stärkere Kryptografie) zum Einsatz kommen. Wir konzentrieren uns auf ML-DSA, da dies aktuell unser Hauptkandidat ist. Wer wissen möchte, wie andere Algorithmen abschneiden, schaut sich die PQC Signature Zoo an.

Wie man sieht, verwendet selbst die Einstiegsvariante von ML-DSA Signaturen, die 10-mal größer als RSA und 34-mal größer als ECDSA sind. Diese Vergrößerung der öffentlichen Kryptografie rüttelt an den Annahmen, auf denen wir die weiteren Schichten unserer Kryptografie aufgebaut haben – so stark, dass Dinge möglicherweise nicht mehr wie gewünscht funktionieren.

Kleine Anmerkung: Falls dir im Netz leicht voneinander abweichende Angaben zu Signatur- und Public-Key-Größen auffallen, liegt das wahrscheinlich daran, dass teils Rohgrößen und teils verpackte Größen (wie ich sie hier aufführe) betrachtet werden.

Im Kern ist ein X.509-Zertifikat ein Verpackungs- und Transportbehälter für einen öffentlichen Schlüssel, signiert mit dem Schlüssel einer Autorität. Als Zertifikate eingeführt wurden, hatten wir nur RSA-Schlüssel. Bei den heute üblichen 2.048 Bit benötigt ein RSA-Schlüssel 272 Byte und die Signatur 256. ECDSA hingegen kommt mit 65 Byte für den Public Key (ohne Kompression) und 72 für die Signatur aus. Zusammen mit dem beigefügten zusätzlichen Metadatenbedarf liegt die typische Größe eines Leaf-Zertifikats bei etwa 1-2 KB.

Ein einziges Zertifikat reicht nicht aus, um sicher auf einen Server zugreifen zu können. In der Praxis verlassen wir uns auf Zertifikatsketten mit mindestens zwei Zertifikaten, die übers Netzwerk übertragen werden. (Eine vollständige Kette kann drei Zertifikate enthalten, wenn das Root berücksichtigt wird – aber dieses Endzertifikat muss nicht übertragen werden.)

Dieses zusätzliche Intermediate verdoppelt die Anforderungen an die Größe. Intermediates und Roots verwenden meist stärkere Kryptografie, wodurch sie nochmals größer werden.

Oben drauf benötigen Protokolle mindestens eine Signatur, um das Live-Kryptografie-Handshake zu authentifizieren. Damit sprechen wir im TLS-Handshake mindestens von 3 Signaturen und 2 öffentlichen Schlüsseln.

In den Anfangszeiten von SSL waren die Prozessoren langsam und Kryptografie sehr ressourcenintensiv – die kryptografischen Operationen bildeten das Nadelöhr. (Damals hatten wir auch viel kleinere Webseiten als heute.) Heutzutage liegt die Bremse woanders, nämlich beim initialen Stau-Fenster (initial congestion window) von TCP, von dem du womöglich noch nie gehört hast.

Ohne zu sehr ins Detail zu gehen: Das initial congestion window ist die maximale Datenmenge, die man zu Beginn einer TCP-Verbindung senden kann, ohne auf eine Antwortrunde aus dem Netz warten zu müssen. Früher war dieses Fenster sehr klein, die heutige Grenze liegt bei rund 14,5 KB. QUIC, die moderne TCP-Alternative (auf UDP aufbauend), hat allerdings ein Limit von nur etwa 4.500 Byte – aus einem anderen Grund: als Verteidigung gegen Verstärkungsangriffe (anti-amplification), die auf UDP sehr einfach durchführbar sind.

Im Klartext: Wenn der Server nicht alle Zertifikate und protokollbedingte Kryptografie in diesen 14,5 KB unterbringen kann, muss er beim sensibelsten Teil der Verbindung – ganz am Anfang – erst auf ein Okay vom Client warten. In kleinen Netzwerken beträgt der Performanceverlust vielleicht nur einige Dutzend Millisekunden. In Mobilfunknetzen kann er aber leicht bei mehreren Hundert liegen.

Verwendet dein Protokoll UDP (wie QUIC erneut), müssen große Pakete fragmentiert werden, und diese Fragmente gehen an sogenannten Middleboxes oft verloren. Auf Netzwerken mit höherem Paketverlust wird die Performance zusätzlich ausgebremst.

Die zuvor beschriebenen "Vanilla"-X.509-Zertifikate sieht man heute kaum noch im Alltag. Auf privaten Netzwerken vielleicht noch, aber in der Web-PKI sind erweiterte X.509-Zertifikate üblich – ergänzt um Informationen über Certificate Transparency (CT). Das CT-Ökosystem bietet zusätzliche Sicherheitsgarantien, indem es verlangt, dass öffentliche Zertifikate in öffentlichen Logs verzeichnet werden. Die Veröffentlichung wird bezeugt – aktuell von mindestens zwei Operatoren. Jeder Operator trägt eine eigene Signatur bei, eingebettet über die SCT-Erweiterung (Signed Certificate Timestamp) im X.509-Zertifikat.

Mit CT im Spiel sprechen wir im typischen TLS-Handshake bereits von 5 Signaturen und 2 öffentlichen Schlüsseln.

Ohne zu sehr auf die Details der Rechnungen einzugehen (das wäre vielleicht einen eigenen Beitrag wert), hier die ungefähren Größenordnungen, die ich für heute übliche Ketten berechnet habe:

• ECDSA-Zertifikatskette: 586 Byte
• RSA-Zertifikatskette: 1.712 Byte
• ML-DSA-Zertifikatskette: 14.724, 18.640 oder 18.565 Byte

Die ML-DSA-Werte verdienen eine Erklärung. Die kleinste Größe (14.724) erhalten wir, wenn in der gesamten Zertifikatskette ML-DSA-44 verwendet wird. Das entspricht jedoch nicht dem best practice. Die zweite Angabe (18.640) gilt, wenn für Intermediates und Roots stärkere Kryptografie verwendet wird, damit diese Schlüssel länger sicher bleiben. Die dritte Zahl entspricht der Nutzung mit CNSA 2.0 (dem Ansatz der NSA), der ausschließlich ML-DSA-87 akzeptiert.

Schon im Bestfall einer ML-DSA-Kette sprengt die öffentliche Kryptografie alleine das 14-KB-Window – und das freut natürlich niemanden. Diese Vergrößerung könnte spürbare Auswirkungen auf unsere alltägliche Nutzung haben. Geräte mit wenig Ressourcen (z. B. IoT) könnten mit Post-Quantum-Kryptografie ernsthafte Probleme bekommen.

Diese Berechnung fokussiert auf das Grundszenario – es gibt aber viele Situationen, in denen der TLS-Handshake noch weiter anwächst. Beispiele:

• Manchmal muss eine zusätzliche Intermediate-Zertifikatsstelle in die Kette eingebaut werden, etwa wenn man die Hierarchie wechselt, aber mit älteren Root-Stores kompatibel bleiben will.
• Wird Hybrid-Authentifizierung genutzt (gleichzeitiger Einsatz traditioneller und post-quanten Kryptografie im selben Zertifikat), wird die Größe weiter erhöht. Das könnte etwa dann Sinn machen, wenn man neuen Post-Quantum-Algorithmen noch nicht vollkommen traut und lieber auf "doppelte Sicherheit" setzt.
• Ebenfalls größer wird es, wenn OCSP für Revocation-Checks verwendet wird – ein Feature, das im öffentlichen Internet allerdings kaum genutzt wird.

Wir haben gesehen: Eine naive Umstellung auf Post-Quantum-Algorithmen bedeutet, wir müssen einen potenziell erheblichen Performanceverlust einkalkulieren. Im nächsten Blogpost zeige ich, welche Hinweise es gibt, die diese Befürchtungen belegen könnten.