Von X25519 zu X25519+MLKEM768: Wie hybrides TLS Realität wird

Zusammenfassung

Kernpunkte im Überblick

• X25519 dominiert heute den TLS-Schlüsselaustausch – schnell, 32-Byte-Schlüssel, konzeptionell konstante Laufzeit – aber Shors Algorithmus auf einem zukünftigen Quantencomputer wird ihn brechen.
• ML-KEM-768 (ehemals Kyber-768) ist ein gitterbasierter KEM, der in NIST FIPS 203 standardisiert wurde ^[2] und sowohl klassischen als auch Quantenangriffen widerstehen soll.
• Der Hybridmodus kombiniert beide Algorithmen, sodass die Sicherheit gewährleistet bleibt, solange einer von beiden standhält – ein doppelter Sicherheitsansatz, der derzeit in den IETF-TLS-ML-KEM-Entwürfen standardisiert wird ^[3].
• Das ist keine Theorie: Chrome, Cloudflare, AWS, Apple iMessage und Signal setzen hybrides TLS oder verwandte hybride Schlüsselaustauschverfahren bereits in der Produktion ein ^{[9][10][11][12][13]}.
• Die Handshake-Größe wächst um das ~38-Fache (32 → 1.216 Bytes für den Schlüsselanteil), aber die operative Auswirkung wird in der Regel eher durch den größeren Handshake als durch die Rechenzeit bestimmt.
• BSI und NIST empfehlen beide den hybriden Schlüsselaustausch als bewährte Übergangspraxis vor der vollständigen Post-Quanten-Migration ^[6][8], wie in unserem BSI-Compliance-Bericht erläutert.

Was ist X25519 und warum hat es sich durchgesetzt?

Bevor wir die Quantenbedrohung erörtern, ist es hilfreich, den Algorithmus zu verstehen, von dem wir aufsteigen. X25519 ist eine Elliptische-Kurven-Diffie-Hellman-(ECDH-)Funktion, die auf Curve25519 operiert und 2006 von Daniel Bernstein entworfen wurde. Seine Designphilosophie war für die damalige Zeit radikal: den schnellstmöglichen Schlüsselaustausch zu schaffen, der zugleich unmöglich falsch implementiert werden kann. Bernstein erreichte dies durch die Wahl einer Montgomery-Kurve, die alle Implementierungen zu konstanter Laufzeit-Arithmetik zwingt und damit eine ganze Klasse von Seitenkanalangriffen konstruktionsbedingt eliminiert.

Das Ergebnis? Ein öffentlicher Schlüssel ist nur 32 Bytes groß. Ein vollständiger Schlüsselaustausch wird in Mikrosekunden abgeschlossen. Es gibt keine verhandelbaren Parameter, die man falsch einstellen könnte, keine Padding-Oracles zum Ausnutzen und keine Sonderfälle. Diese Einfachheit ist der Grund, warum TLS 1.3 X25519 zu einer von nur zwei verpflichtenden Schlüsselaustauschgruppen machte und damit die älteren, größeren Finite-Field-Diffie-Hellman-Gruppen und den RSA-Schlüsseltransport effektiv ausrangierte ^[5].

In einem TLS 1.3-Handshake sendet der Client seinen X25519-öffentlichen Schlüssel im ClientHello, der Server antwortet mit seinem eigenen, und beide Seiten leiten dasselbe gemeinsame Geheimnis ab. Dieses Geheimnis fließt in die Schlüsselableitungsfunktion von TLS ein, um Sitzungsschlüssel zu erzeugen. Da bei jeder Verbindung frische ephemere Schlüssel generiert werden, kann selbst die Kompromittierung des langfristigen privaten Schlüssels des Servers vergangene Sitzungen nicht offenlegen – eine Eigenschaft namens Forward Secrecy. Für einen tieferen Einblick in die unterschiedlichen Rollen von Schlüsselaustausch und digitalen Signaturen in TLS siehe unseren Artikel über Schlüsselaustausch vs. digitale Signaturen.

Warum X25519 allein nicht mehr ausreicht

Die Sicherheit von X25519 beruht auf dem Diskreten-Logarithmus-Problem auf elliptischen Kurven (ECDLP): Gegeben ein Punkt Q = kG auf Curve25519, ist es rechnerisch nicht machbar, den Skalar k zu bestimmen. Auf klassischer Hardware bleibt dies wahr – aber Shors Algorithmus ^[7], ausgeführt auf einem hinreichend leistungsfähigen Quantencomputer, löst das ECDLP in polynomialer Zeit. Wenn diese Maschine kommt, wird jeder jemals aufgezeichnete X25519-Schlüsselaustausch rückwirkend brechbar.

Dies ist der Kern der Harvest-Now-Decrypt-Later-(HNDL-)Bedrohung: Angreifer fangen verschlüsselten TLS-Datenverkehr heute passiv ab und archivieren ihn, bis Quantenhardware die Sitzungsschlüssel extrahieren kann. Alle Daten, die über die 2030er Jahre hinaus vertraulich bleiben müssen, sind bereits gefährdet. Wie wir in jenem Artikel untersucht haben, wurde beobachtet, dass Geheimdienste verschlüsselten Internetverkehr in großem Maßstab umleiten – genau die Art von Chiffretext-Archiv, die das HNDL-Modell vorhersagt.

Der Expertenkonsens ist ernüchternd: 22,7 % der Kryptographie-Forscher erwarten, dass RSA-2048 bis 2030 fällt, und 50 % sagen spätestens 2035. X25519 bietet aufgrund der Struktur elliptischer Kurven sogar weniger Quantenresistenz als RSA-2048. Für eine vollständige Schwachstellenanalyse von TLS 1.3 unter Quantenangriff – einschließlich der Auswirkungen auf Handshake, Schlüsselaustausch und Authentifizierung – siehe unseren ausführlichen Bericht über TLS 1.3-Quanten-Schwachstellen und hybride Abwehrmaßnahmen.

ML-KEM-768: Wie ein post-quantensicherer KEM funktioniert

ML-KEM-768 (Module-Lattice-Based Key Encapsulation Mechanism, Sicherheitsstufe 3) ist einer der ersten post-quantensicheren Algorithmen, die von NIST in FIPS 203 standardisiert wurden ^[2] (August 2024). Ehemals als CRYSTALS-Kyber bekannt, gehört er zur Familie der gitterbasierten Kryptographie – Verfahren, deren Sicherheit auf der Schwierigkeit basiert, das Module Learning With Errors (MLWE)-Problem zu lösen. Kein bekannter Quantenalgorithmus kann MLWE effizient lösen, was ihn zu einem Kandidaten für die Post-Quanten-Ära macht.

ML-KEM-768 ist jedoch kein direkter Ersatz für X25519 – es funktioniert grundlegend anders. X25519 führt einen interaktiven Diffie-Hellman-Austausch durch: Beide Parteien tragen ephemere öffentliche Schlüssel bei und berechnen gemeinsam ein geteiltes Geheimnis. ML-KEM hingegen ist ein Schlüsselkapselungsmechanismus (KEM): Der Absender nutzt den öffentlichen Schlüssel des Empfängers, um ein zufälliges geteiltes Geheimnis in einen Chiffretext zu kapseln, und nur der Inhaber des zugehörigen privaten Schlüssels kann es entkapseln. Das Ergebnis ist dasselbe – beide Seiten teilen ein Geheimnis – aber der Mechanismus ist asymmetrisch statt interaktiv.

Der Größenunterschied ist erheblich – der öffentliche Schlüssel von ML-KEM-768 ist 37× größer als der von X25519. Dies ist der Preis der Quantenresistenz: Gitterprobleme erfordern größere mathematische Objekte. Der Rechenaufwand ist auf moderner Hardware allerdings in der Regel moderat; in der Praxis werden Bedenken bei der Einführung häufiger durch die Nachrichtengröße und Kompatibilität als durch die reine ML-KEM-Rechenzeit bestimmt. Für detaillierte Leistungsbenchmarks einschließlich FrodoKEM und Classic McEliece siehe unseren Bericht BSI-konformer Post-Quanten-Schlüsselaustausch.

Der hybride Ansatz: Doppelte Absicherung

Wenn ML-KEM-768 quantensicher ist, warum nicht einfach X25519 damit ersetzen? Die Antwort lautet konservatives kryptographisches Engineering. ML-KEM wurde seit seiner Auswahl durch NIST im Jahr 2022 intensiv untersucht, aber gitterbasierte Kryptographie ist im Vergleich zur vier Jahrzehnte langen Erfolgsbilanz elliptischer Kurven noch jung. Was, wenn ein Durchbruch in der Gitter-Kryptoanalyse MLWE schwächt oder bricht? Hätten wir X25519 bereits aufgegeben, stünden wir mit leeren Händen da.

Der hybride Ansatz löst dieses Problem, indem beide Schlüsselaustauschverfahren parallel ausgeführt und ihre Ergebnisse kombiniert werden. In einem hybriden TLS-Handshake mit X25519MLKEM768 ^[3] enthält das ClientHello des Clients einen einzelnen kombinierten Schlüsselanteil: den 1.184 Bytes großen ML-KEM-768-Kapselungsschlüssel zusammen mit dem 32 Bytes großen ephemeren X25519-Anteil, insgesamt 1.216 Bytes. Der Server antwortet mit seinem eigenen kombinierten Wert: einem 1.088 Bytes großen ML-KEM-Chiffretext plus einem 32 Bytes großen X25519-Ephemeralanteil, insgesamt 1.120 Bytes. Die beiden resultierenden geteilten Geheimnisse werden verkettet und dann in den normalen TLS-1.3-Schlüsselplan eingespeist.

Die Sicherheitsgarantie ist einfach: Ein Angreifer muss sowohl X25519 als auch ML-KEM-768 brechen, um die Sitzung zu kompromittieren. Wenn Quantencomputer X25519 brechen, schützt ML-KEM-768 die Daten weiterhin. Wenn ein klassischer Kryptoanalyse-Durchbruch ML-KEM schwächt, hält X25519 stand. Deshalb wird die hybride Bereitstellung während der Übergangszeit von staatlichen und industriellen Leitlinien weithin empfohlen, darunter BSI TR-02102-1 ^[6] und die umfassenderen Leitlinien zur Post-Quanten-Migration von NIST ^[8].

Dieser hybride Schlüsselaustausch wird derzeit in der IETF-TLS-ML-KEM-Arbeit standardisiert ^[3], einschließlich des Entwurfs, der die X25519MLKEM768-Benannten-Gruppe für TLS 1.3 definiert. Der aktuelle Entwurf spezifiziert, wie die kombinierten Client- und Server-Schlüsselaustauschdaten kodiert werden und wie das geteilte Geheimnis gebildet wird, was interoperable Implementierungen ermöglicht. Für ein visuelles Diagramm, wie der hybride Schlüsselaustausch mechanisch funktioniert, siehe Abbildung 3 in unserem Artikel über TLS-1.3-Quanten-Schwachstellen.

Wer setzt hybrides TLS bereits produktiv ein?

Anders als bei vielen kryptographischen Umstellungen, die jahrelang theoretisch bleiben, hat sich hybrides TLS mit bemerkenswerter Geschwindigkeit von der Entwurfsspezifikation zur Produktionsbereitstellung entwickelt. Hier ist der Stand der Verbreitung Anfang 2026, basierend auf öffentlichen Einsatzankündigungen und standardisierten Dokumenten.

Die Geschwindigkeit der Verbreitung spiegelt eine gemeinsame Dringlichkeit in der Branche wider. Die Einführung durch Chrome ^[10] machte den hybriden post-quantensicheren Schlüsselaustausch auf Internetebene sichtbar, während Cloudflare ^[9] wiederholt betont hat, dass der wichtigste operative Kompromiss der größere Handshake und die damit verbundenen Kompatibilitätsprobleme bei Middleboxes oder Legacy-Infrastruktur sind.

Über TLS hinaus hat der hybride Ansatz auch sichere Messaging-Protokolle beeinflusst: Signals PQXDH-Protokoll ^[12] und Apples PQ3 ^[11] kombinieren beide post-quantensichere und klassische Komponenten, um die Vertraulichkeit von Nachrichten gegen zukünftige Quantenentschlüsselung zu schützen. Für eine breitere Übersicht über Post-Quanten-Einsätze in verschiedenen Branchen siehe unseren Artikel PQC-Praxisbeispiele.

Praktische Herausforderungen in der Umsetzung

Hybrides TLS ist produktionsreif, aber die Umstellung ist nicht völlig schmerzfrei. Hier sind die häufigsten Probleme, denen Betreiber begegnen.

Für die meisten Einsatzszenarien ist die Umstellung unkompliziert. Wenn Sie eine aktuelle Version von OpenSSL (3.5+) ^[14], BoringSSL oder wolfSSL verwenden, ist die Aktivierung des hybriden Schlüsselaustauschs eine Konfigurationsänderung:

Die genaue Server-Konfigurationssyntax hängt von Ihrem TLS-Stack ab und davon, wie er die OpenSSL-Gruppenauswahl exponiert. Betrachten Sie die folgenden Snippets als illustrative Beispiele und nicht als universelle Copy-Paste-Befehle.

Das Grundprinzip besteht darin, X25519MLKEM768 zu bevorzugen und gleichzeitig X25519 als Fallback für Clients bereitzuhalten, die Hybrid noch nicht unterstützen. Dies gewährleistet einen sanften Rückfallpfad.

Was kommt nach dem hybriden KEM?

Der hybride Schlüsselaustausch löst das dringendste Problem – den Schutz der Vertraulichkeit gegen Harvest-Now-Decrypt-Later-Angriffe. Doch TLS stützt sich auf zwei kryptographische Säulen, und wir haben bisher nur eine aufgerüstet. Die zweite Säule, Authentifizierung über digitale Signaturen, verwendet weiterhin klassisches RSA und ECDSA. Wie in unserer Analyse Schlüsselaustausch vs. Signaturen erläutert, ist dies vorerst akzeptabel, da ein zukünftiger Quantenbruch einer Signatur vergangene Sitzungen nicht rückwirkend kompromittiert. Doch letztlich müssen auch Zertifikate migriert werden.

NIST hat zwei post-quantensichere Signaturverfahren standardisiert: ML-DSA (FIPS 204 ^[15], ehemals Dilithium) und SLH-DSA (FIPS 205 ^[16], ehemals SPHINCS+). Allerdings bringen PQ-Signaturen erhebliche Größenprobleme mit sich: Ein ML-DSA-65-öffentlicher Schlüssel ist 1.952 Bytes groß und eine Signatur 3.309 Bytes, verglichen mit der 64-Byte-Signatur von ECDSA-P256. Das bedeutet, dass Zertifikate mit PQ-Signaturen wesentlich größer sein werden und die Handshake-Größe noch weiter beeinflussen.

Blickt man weiter voraus, wird die Branche möglicherweise irgendwann vom hybriden Schlüsselaustausch zu eigenständigen Post-Quanten-Gruppen wie ML-KEM übergehen und die X25519-Komponente fallen lassen, sobald das Vertrauen in gitterbasierte Kryptographie und die Interoperabilität hinreichend hoch ist. Doch dieser Tag liegt noch Jahre entfernt – der konservative hybride Ansatz wird voraussichtlich bis in die 2030er Jahre bestehen bleiben.

Referenzen

1. Bernstein, D.J. (2006). Curve25519: new Diffie-Hellman speed records. https://cr.yp.to/ecdh
2. NIST (2024). FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard. https://nvlpubs.nist.gov/nistpubs/fips/nist.fips.203.pdf
3. IETF (2026). draft-ietf-tls-ecdhe-mlkem: Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLS 1.3. https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/
4. IETF (laufend). draft-ietf-tls-mlkem: ML-KEM Post-Quantum Key Agreement for TLS 1.3. https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/
5. IETF (2018). RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3. https://datatracker.ietf.org/doc/html/rfc8446
6. BSI (2025). TR-02102-1: Kryptographische Mechanismen. https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-1.html
7. NIST (2016). IR 8105: Report on Post-Quantum Cryptography. https://csrc.nist.gov/pubs/ir/8105/final
8. NIST. IR 8547 (Initial Public Draft): Transition to Post-Quantum Cryptography Standards. https://csrc.nist.gov/pubs/ir/8547/ipd
9. Cloudflare (2024). Post-quantum cryptography implementation considerations for TLS and related deployment updates. https://blog.cloudflare.com/post-quantum-zero-trust/
10. Chromium Blog (2024). Advancing Our Amazing Bet on Asymmetric Cryptography. https://blog.chromium.org/2024/05/advancing-our-amazing-bet-on-asymmetric.html
11. Apple Security Research (2024). iMessage with PQ3: The New State of the Art in Quantum-Secure Messaging at Scale. https://security.apple.com/blog/imessage-pq3/
12. Signal (2023). Quantum Resistance and the Signal Protocol. https://signal.org/blog/pqxdh/
13. AWS KMS Documentation (2026). Using hybrid post-quantum TLS with AWS KMS. https://docs.aws.amazon.com/kms/latest/developerguide/pqtls.html
14. OpenSSL 3.5 Documentation: SSL_CTX_set1_groups. https://docs.openssl.org/3.5/man3/SSL_CTX_set1_groups/
15. NIST FIPS 204: Module-Lattice-Based Digital Signature Standard (ML-DSA). https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.204.pdf
16. NIST FIPS 205: Stateless Hash-Based Digital Signature Standard (SLH-DSA). https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.205.pdf
17. NSA: Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) FAQ. https://media.defense.gov/2022/Sep/07/2003071836/-1/-1/0/CSI_CNSA_2.0_FAQ_.PDF
18. NCSC (2025). Timelines for migration to post-quantum cryptography. https://www.ncsc.gov.uk/guidance/pqc-migration-timelines