Ein genauerer Blick auf die Performance von ML-KEM

Dieser Blogbeitrag ist Teil einer Serie, in der ich die Post-Quanten-Migration aus technischer Sicht beleuchte. Unser Ziel ist es, die anstehenden Probleme zu verstehen sowie zu klären, wie und warum bestimmte Entscheidungen getroffen werden. Letztlich geht es darum, zu verstehen. Die ersten beiden Beiträge behandelten die Herausforderungen im Zusammenhang mit den größeren Signaturgrößen und den neuen Methoden zum Schlüsselaustausch. Im dritten haben wir die Netzwerk- und TLS-Protokollebenen untersucht, um herauszufinden, welche Aspekte die Performance beeinflussen und wie sich diese durch die Migration verändern werden.

In diesem vierten Beitrag schauen wir uns die neuen Optionen zum Schlüsselaustausch mit ML-KEM an, um zu verstehen, wie sie sich in der Praxis verhalten. Das ist der Teil der Post-Quanten-Migration, der bereits umgesetzt wurde, zumindest im TLS-Protokoll. Die Entscheidungen sind gefallen, schauen wir uns also an, wie sie sich auf die Performance in der Praxis auswirken.

Bevor wir die Post-Quanten-Migration angingen, bot TLS 1.3 zwei Optionen für den Schlüsselaustausch, beide basierend auf dem Diffie-Hellman-Algorithmus; eine klassische und eine Variante mit elliptischen Kurven. Wir bezeichnen diese üblicherweise als DHE und ECHDE. (Das letzte „E“ in der Abkürzung steht für ephemeral, also vergänglich. Das ist von Vorteil, weil es Forward Secrecy bietet.) ECHDE war und ist die dominierende Option, dank besserer Sicherheitseigenschaften bei kleineren Schlüsselgrößen, besserer Performance und geringerem Platzbedarf auf der Leitung.

Mit der Post-Quanten-Migration ist TLS auf hybriden Schlüsselaustausch umgestiegen, der ECDHE mit dem von NIST verabschiedeten ML-KEM-Standard kombiniert. Weil es sich um einen Hybrid handelt, trägt jeder TLS-Handshake Informationen zu zwei Algorithmen mit sich; wir machen buchstäblich alles doppelt. Wie hat sich das auf das Protokoll ausgewirkt?

Um das herauszufinden, habe ich ein altes Tool von mir wieder hervorgeholt (ein Fork einer früheren Arbeit von Vincent Bernat), das ich schon früher für diese Art von Messung verwendet hatte. Ich habe es auf OpenSSL 3.5.5 portiert, das mit Ubuntu 26.04 LTS ausgeliefert wird. Diese OpenSSL-Version [oder so ähnlich] läuft derzeit auf den aktuellen LTS-Betriebssystemen.

Mein Tool misst den CPU- und Netzwerk-Transportbedarf verschiedener Cipher-Suites, Schlüsselaustauschalgorithmen und Protokolle. In diesem Fall habe ich vier Optionen getestet:

• ECDSA-256-Schlüssel gepaart mit ECDHE-X25519 – die Baseline, eine moderne und schnelle Option.
• RSA-2048-Schlüssel gepaart mit ECDHE-X25519 – etwas langsamer wegen RSA.
• ECDSA-256-Schlüssel gepaart mit X25519MLKEM768 – die neue PQC-Hybrid-Option.
• ECDSA-256-Schlüssel gepaart mit ML-KEM-1024 – die neue reine PQC-Option.

Wir können nur TLS 1.3 testen, weil TLS 1.2 und älter nicht für Post-Quanten-Kryptografie angepasst werden.

Die Messung erfolgt auf demselben Computer, auf dem ein vollständiger Client und ein vollständiger Server laufen, im selben Prozess, aber auf getrennten Threads. Wir messen den CPU-Verbrauch und beobachten die Größe jedes Handshakes. Jeder Durchlauf umfasste 2.000 Handshakes und wurde 3-5 Mal wiederholt, damit sich die Werte stabilisieren. Beachten Sie, dass es sich bei den CPU-Messungen um CPU-Zeit handelt, was für unsere Zwecke ausreicht, um einen Schlüsselaustausch mit einem anderen zu vergleichen, die Werte aber ansonsten nicht mit an anderer Stelle erhobenen Messungen vergleichbar sind.

Werfen wir zunächst einen Blick auf die CPU-Auslastung während des Schlüsselaustauschs.

Man sieht sofort, warum ECDSA aktuell der bevorzugte Schlüsselalgorithmus gegenüber RSA ist. Bei Letzterem muss der Server bei jedem Handshake 2,5-mal mehr Arbeit leisten. Es gibt außerdem eine deutliche Asymmetrie bei der CPU-Zeit zwischen Client und Server: Server leisten insgesamt 3-mal mehr Arbeit.

Ich habe RSA nur zum Vergleich einbezogen, für unsere Zwecke können wir diese Messung jedoch ausklammern und uns auf die übrigen drei konzentrieren, die alle ECDSA verwenden. Das Fazit? Es gibt keine nennenswerten Unterschiede bei der CPU-Zeit, unabhängig davon, welcher Schlüsselaustausch verwendet wird. Das liegt daran, dass ML-KEM sehr schnell ist. Auch wenn es nicht-triviale relative Zuwächse gibt, sind die Unterschiede in absoluten Zahlen gering.

Schauen wir uns als Nächstes die Datenmenge an, die zwischen Client und Server hin- und hergeht.

Hier sehen wir deutliche Unterschiede. Vergleicht man die beiden ML-KEM-Messungen mit X25519 als Baseline, zeigt sich, dass X25519MLKEM768 dem Client-Handshake 1.176 Byte und dem Server-Handshake 1.088 Byte hinzufügt. Von diesen beiden ist der Anstieg auf Serverseite (2x) bedeutsamer, weil er Platz im initialen Congestion Window beansprucht, das in der Praxis den Engpass darstellt, auf den wir stoßen werden.

ML-KEM-1024, ein stärkerer Algorithmus, benötigt noch mehr Platz. Die Serverseite des Handshakes wächst um 1.537 Byte, also etwa das 2,6-Fache.

Wie Sie sich vielleicht aus meinen früheren Artikeln erinnern, verwenden wir ML-KEM-1024 für die reine ML-KEM-Messung, weil das die Mindestanforderung ist, die die NSA im Rahmen ihrer Commercial National Security Algorithm (CNSA) 2.0 akzeptiert.

Diese Messungen erzählen nicht die ganze Geschichte, weil Client und Server auf derselben Maschine laufen, mit nur minimaler Netzwerklatenz. Selbst auf dieser Ebene sehen wir, dass reines ML-KEM etwas schlechter abschneidet als die anderen Methoden; es benötigt etwa dieselbe CPU-Leistung, aber mehr Byte im Handshake.

In der Praxis müssen wir berücksichtigen, dass TLS-Clients in ihrem initialen ClientHello nur eine kleine Anzahl von Key Shares senden können. Heute werden X25519 und X25519MLKEM768 gesendet, ML-KEM-1024 jedoch nicht. Das bedeutet, dass jeder Server, der Letzteres unterstützen möchte, bei jeder vollständigen TLS-Verbindung mit einer Retry-Anfrage antworten muss, was einen weiteren Roundtrip zum Handshake hinzufügt.

ML-KEM-1024 standardmäßig als dritten Key Share hinzuzufügen, ergibt kaum Sinn, da die meiste Welt es nicht nutzen wird. Server, die eine reine PQC-Option benötigen, müssen die Performance-Einbuße vorerst hinnehmen.

Auf lokalen Netzwerken, wo Roundtrips im niedrigen einstelligen Millisekundenbereich liegen, dürfte das kaum ein Problem darstellen, im öffentlichen Internet wird sich die Performance-Einbuße jedoch deutlich bemerkbar machen. Wüssten wir, welche Schlüsselaustauschverfahren ein bestimmter Server unterstützt, könnten wir nur einen Key Share senden, doch aktuell fehlt uns die Technologie, um diese Information zu verteilen. Ein RFC-Entwurf in Arbeit („TLS Key Share Prediction“) untersucht, ob sich DNS dafür über SVCB- und HTTPS-Records nutzen lässt.