Zusammenfassung
Wichtigste Punkte auf einen Blick
- Klassische Kryptographie besteht Quantenrechner nicht: RSA und elliptischer Diffie–Hellman beruhen auf Problemen, die mit Shors Algorithmus auf ausreichend großen Quantencomputern effizient gelöst werden können.
- Die Bedrohung „Harvest now, decrypt later“ (HNDL) ist real: Versierte Angreifer speichern wahrscheinlich bereits verschlüsselte Daten, um sie später zu entschlüsseln. Daten, die über die 2030er Jahre hinaus vertraulich bleiben müssen, sind potenziell gefährdet.
- Hybrider Schlüsselaustausch verbindet das Beste aus zwei Welten: Durch die Kombination von ML-KEM-768 mit X25519 bleibt das System sicher, solange mindestens eines der Verfahren hält. Das ist wie zwei Schlösser an der Tür—ein Angreifer muss beide knacken, siehe IETF-Entwurf.
- RSA-Signaturen sind vorerst ausreichend: Da TLS Signaturen nur zur Authentifizierung während des Handshakes einsetzt—nicht zur Datenverschlüsselung—offenbart das nachträgliche Brechen einer Signatur keine früheren Sitzungsschlüssel. Zertifikate mit RSA oder ECDSA bleiben praktikabel, bis Quantenrechner sie in Echtzeit attackieren können.
Die klassischen Grundlagen von TLS 1.3
Zunächst zum Status quo: Wenn ein Browser eine sichere Website aufruft, führt er mit dem Server einen elliptischen Diffie–Hellman-Austausch durch, um ein gemeinsames Geheimnis zu erzeugen. Anschließend authentifizieren beide Seiten diesen Austausch über X.509-Zertifikate, wie in RFC 8446 beschrieben. Der Vorteil der ECDH-Operation (häufig mit der Kurve X25519) ist die Vorwärtsgeheimnis: Selbst wenn morgen der private Schlüssel des Servers geleakt wird, kann der heutige Verkehr nicht entschlüsselt werden. Die Authentifizierung erfolgt über digitale Signaturen—typischerweise RSA oder ECDSA—im Serverzertifikat, sodass der Browser die Gegenstelle prüfen kann.
Die Sicherheit beider Mechanismen hängt von Problemen ab, die wir für schwer halten: Diffie–Hellman vom diskreten Logarithmus, RSA von der Faktorisierung großer Zahlen. Ein ausreichend leistungsfähiger Quantencomputer mit Shors Algorithmus könnte diese Probleme effizient lösen, wie NISTs Risikoanalyse ausführt. Obwohl solche Maschinen noch nicht existieren, warten staatliche Akteure nicht ab—sie zeichnen bereits verschlüsselte Daten auf in der Hoffnung, sie am „Q-Day“ entschlüsseln zu können.
Quantenbedrohungen und das „Harvest-Now-Decrypt-Later“-Problem
HNDL klingt nach Spionagethriller, ist aber eine reale Sorge der IT-Sicherheit. Das Prinzip: Auch wenn heutige Quantencomputer moderne Kryptographie nicht brechen, können Angreifer verschlüsselte Verbindungen abfangen und speichern oder ganze Datenbanken entwenden—ein Archiv verschlüsselter Geheimnisse, das auf den Tag wartet, an dem Quantenrechner stark genug sind.
Branchenanalysen warnen, dass Angreifer mit hinreichend starken Quantenrechnern aus aufgezeichneten Handshakes private Schlüssel extrahieren und Jahre an Daten entschlüsseln könnten, wie auch der IETF-Entwurf zu PQC-Anwendungen beschreibt.
Besonders kritisch ist das für Informationen mit langem Schutzbedarf—etwa Finanzunterlagen, Betriebsgeheimnisse, medizinische Historien oder behördliche Verschlusssachen. Wer Daten über 10–20 Jahre vertraulich halten muss, sollte jetzt handeln.
| Verfahren | Typ | Schlüsselgröße | Klassische Sicherheit | Quantensicherheit | Status |
|---|---|---|---|---|---|
| RSA-2048 | Signatur/KEM | 256 Byte | ✅ Stark | ❌ Durch Shor angreifbar | Aktueller Standard |
| X25519 | Schlüsselaustausch | 32 Byte | ✅ Stark | ❌ Durch Shor angreifbar | Aktueller Standard |
| ML-KEM-768 | KEM | 1.184 Byte | ✅ Stark | ✅ Resistent | NIST FIPS 203 |
| X25519 + ML-KEM-768 | Hybrides KEM | 1.216 Byte | ✅ Stark | ✅ Resistent | Empfohlen |
| ML-DSA-65 | Signatur | 1.952 Byte | ✅ Stark | ✅ Resistent | NIST FIPS 204 |
Daher priorisiert die Community derzeit quantensicheren Schlüsselaustausch vor quantensicheren Signaturen. Der Schlüsselaustausch muss Vertraulichkeit über die Lebensdauer der Verbindung hinaus sicherstellen, während Signaturen nur zum Zeitpunkt der Verifikation wirken. Wird eine Signatur erst in zehn Jahren gebrochen, kompromittiert das nicht die damals ausgetauschten Daten.
Hybrider Schlüsselaustausch mit ML-KEM-768 und X25519
Post-Quanten-Kryptographie (PQC) ist eine neue Generation von Verfahren, die sowohl klassischen als auch Quantenangriffen standhalten sollen. Dazu zählt ML-KEM (früher Kyber), ein gitterbasiertes Key-Encapsulation-Mechanism, das NIST in FIPS 203 standardisiert hat. Anstatt Bewährtes zu verwerfen, schlägt die IETF einen hybriden Ansatz vor, der klassische und PQC-Verfahren kombiniert.
Die Gruppe X25519MLKEM768 steht exemplarisch für diesen „Gürtel-und-Hosenträger“-Ansatz. Sie
kombiniert einen X25519‑öffentlichen Schlüssel mit einem ML‑KEM‑768‑öffentlichen Schlüssel, wie in der IETF‑Spezifikation beschrieben.
Während des Handshakes führen Client und Server zwei Operationen aus: einen klassischen Diffie‑Hellman‑Austausch
über elliptische Kurven und eine ML‑KEM‑Kapselung. Anschließend werden beide Geheimnisse (meist mittels
kryptographischer Hashfunktion) kombiniert, um den Sitzungsschlüssel herzuleiten. Der Clou: Falls
Quantencomputer X25519 eines Tages brechen, schützt ML‑KEM weiterhin. Und falls Forschende eine Schwäche in
ML‑KEM finden, springt X25519 ein. Wie Sicherheitsexperten betonen,
müsste man beide Algorithmen brechen, um die Sitzung zu kompromittieren.
In der Kryptographie gibt es keinen „Free Lunch“: Die Einführung hybrider KEMs bringt praktische Hürden mit sich. Laut NIST FIPS 203 umfasst ein ML‑KEM‑768‑öffentlicher Schlüssel 1.184 Byte. Zusammen mit den 32 Byte von X25519 ergibt das im ClientHello etwa 1.216 Byte (siehe unsere Demo‑Seite für Details).
Diese Zunahme kann Kopfschmerzen bereiten—Akamais Untersuchung zeigt, dass sie Paketfragmentierung begünstigen oder ältere Netzausrüstung, die kleinere Handshakes erwartet, verwirren kann. Trotz dieser Anlaufschwierigkeiten bewegt sich die Branche schnell: Große Cloud‑Anbieter, CDNs und TLS‑Bibliotheken rollen bereits Unterstützung für hybride Gruppen aus.
Digitale Signaturen – warum RSA weiterhin ausreicht
Während der Schlüsselaustausch die Vertraulichkeit schützt, übernehmen digitale Signaturen in TLS die Authentifizierung. Der Ablauf: Der Server weist seine Identität nach, indem er das Handshake‑Protokoll signiert; der Client prüft diese Signatur mit dem öffentlichen Schlüssel aus dem Serverzertifikat. Entscheidend ist: Das geschieht im initialen Handshake, bevor sensible Daten übertragen werden.
Diese zeitliche Abfolge ist entscheidend: Wie Cloudflares Analyse zeigt, ermöglicht selbst das spätere Faktorisieren eines RSA‑Schlüssels keine nachträgliche Kompromittierung von Sitzungen, die einen sicheren Schlüsselaustausch verwendeten.
Darum sind PQ‑Signaturen nicht dringend nötig, um die „Harvest‑Now‑Decrypt‑Later“-Bedrohung zu adressieren. Ein RSA‑2048‑ oder ECDSA‑P256‑Zertifikat mit angemessener Laufzeit (z. B. ein Jahr) bietet für heutige Zwecke ausreichend Sicherheit. Allerdings dürfen wir Root‑Zertifizierungsstellen nicht ignorieren, deren Zertifikate oft zwanzig Jahre oder länger gültig sind, wie dieser IETF‑Entwurf betont. Treffen Quantencomputer während dieser Gültigkeit ein, könnten Angreifer die CA imitieren und Scheinzertifikate ausstellen.
Für solche Hochrisiko‑Szenarien werden bereits PQ‑Signaturverfahren wie ML‑DSA (Dilithium) und SLH‑DSA (SPHINCS+) sondiert. Diese Verfahren bringen jedoch Trade‑offs mit sich—größere Schlüssel und Signaturen sowie derzeit spürbare Performanceeinbußen. Die Einführung wird voraussichtlich schrittweise erfolgen, wenn Implementierungen reifen und Hardware nachzieht.
Sinnvoll ist derzeit: Zertifikatslaufzeiten kurz halten, den Fortschritt bei PQC‑Signaturen beobachten und die eigene Infrastruktur so auslegen, dass sie neue Algorithmen aufnehmen kann. Durch die Kombination aus hybridem Schlüsselaustausch (für langfristige Vertraulichkeit) und etablierten Signaturen (für die aktuelle Authentifizierung) erreichen wir einen robusten Schutz gegen Quantenbedrohungen, ohne die heute nötige Performance und Kompatibilität einzubüßen.
📋 Schnelle Implementierungs‑Checkliste
- ✅ Hybride Gruppen (X25519MLKEM768) in der TLS‑Konfiguration aktivieren
- ✅ Auf Paketfragmentierung und Middlebox‑Kompatibilität testen
- ✅ Zertifikatslaufzeiten kurz halten (≤ 1 Jahr für Endentitäts‑Zertifikate)
- ✅ NIST‑ und IETF‑Fortschritt bei PQC‑Signaturen beobachten
- ✅ Systeme mit langfristig sensiblen Daten für priorisierte Migration inventarisieren
- ✅ Infrastruktur‑Updates für größere Handshakes einplanen