🔑Schlüsselaustausch

Das Kernproblem: Client und Server brauchen einen gemeinsamen symmetrischen Schlüssel – aber jede Nachricht zwischen ihnen kann mitgelesen werden. Die Lösung von Diffie und Hellman (1976) ist bis heute das Herz von TLS.

🎨1. Die Idee mit Farben

Die bekannte Analogie: Farben mischen ist leicht, entmischen praktisch unmöglich.
👩 Alice
Grundfarbe
🌐 Öffentliches Netz · 🕵️ Eve sieht
Grundfarbe
👨 Bob
Grundfarbe

Schritt 1: Alice und Bob einigen sich öffentlich auf eine gemeinsame Grundfarbe (Gelb). Eve hört mit – egal.

Schritt 1 / 5 · Tasten ← →

Die Analogie trägt, weil sich Farben leicht mischen, aber kaum „entmischen“ lassen. In der Mathematik entspricht Mischen dem Potenziereng^a mod p – leicht zu rechnen, schwer umzukehren (diskreter Logarithmus).

🧮2. Diffie-Hellman mit echten Zahlen

Mischen heißt jetzt g^x mod p. Wähle eigene Werte oder eine Voreinstellung und gehe Schritt für Schritt durch – alles wird mit BigInt exakt gerechnet.
👩 Alice
geheim: a = 6
🕵️ Eve sieht
p = 23, g = 5
👨 Bob
geheim: b = 15
Öffentliche Parameter. Rot = geheim, Blau = öffentlich.
Schritt 1 / 5 · Tasten ← →

📈3. ECDHE mit X25519 – echt im Browser

Statt Zahlen modulo p nimmt man Punkte auf einer elliptischen Kurve. Curve25519 liefert mit 32-Byte-Schlüsseln etwa die Sicherheit von 3072-Bit-RSA/DH und ist in TLS 1.3 die häufigste Gruppe.
Werte aus RFC 7748 – nachprüfbar
👩 Alice (Client)
privater Schlüssel a (32 Byte, zufällig)
77076d0a7318a57d3c16c17251b26645df4c2f87ebc0992ab177fba51db92c2a
geklammert („clamped“): 70076d0a…1db92c6a – unterste 3 Bit 0, Bit 254 = 1
öffentlicher Schlüssel A = X25519(a, 9)
8520f0098930a754748b7ddcb43ef75a0dbf3a0d26381af4eba4a98eaa9b4e6a
geht als key_share in den ClientHello
gemeinsames Geheimnis = X25519(a, B)
4a5d9d5ba4ce2de1728e3bf480350f25e07e21c947d19e3376f09b3c1e161742
👨 Bob (Server)
privater Schlüssel b (32 Byte, zufällig)
5dab087e624a8a4b79e17f8b83800ee66f3bb1292618b6fd1c2f8b27ff88e0eb
öffentlicher Schlüssel B = X25519(b, 9)
de9edb7d7b7dc1b4d35b61c2ece435373f8343c85b78674dadfc7e146f882b4f
geht als key_share in den ServerHello
gemeinsames Geheimnis = X25519(b, A)
4a5d9d5ba4ce2de1728e3bf480350f25e07e21c947d19e3376f09b3c1e161742
✅ Beide Seiten haben dasselbe 32-Byte-Geheimnis – übertragen wurden nur A und B.
🕵️ Eve mit eigenem Schlüssel: X25519(e, A)
…
passt nicht – ohne a oder b kommt man nicht an das Geheimnis
Nie direkt verwenden: erst durch HKDF (hier Extract + Expand-Label „key“, 16 Byte)
…
TLS 1.3 macht daraus den kompletten Schlüsselplan → Handshake-Debugger

Punkt 9 ist der Basispunkt von Curve25519 (u-Koordinate 9). Die Rechnung läuft mit @noble/curves vollständig in deinem Browser; die Testvektoren sind in tests/crypto.test.ts geprüft.

⏳4. RSA-Schlüsseltransport vs. ECDHE: Forward Secrecy

In TLS 1.2 gab es zwei Wege zum gemeinsamen Geheimnis. Der Unterschied zeigt sich erst Jahre später – wenn der Serverschlüssel in falsche Hände gerät.
TLS 1.2 · RSA-Schlüsseltransportz. B. TLS_RSA_WITH_AES_128_GCM_SHA256

Der Client würfelt das Pre-Master-Secret und schickt es mit dem öffentlichen RSA-Schlüssel des Servers verschlüsselt (ClientKeyExchange). Lehrbuch-RSA mit winzigen Zahlen: p = 61, q = 53, n = 3233, e = 17, d = 2753.

c = m^e mod n = 65^17 mod 3233 = 2790
📼 Eve schneidet c im Jahr 2026 mit und speichert es.

Hinweis: Echtes TLS 1.2 nutzt 2048-Bit-RSA mit PKCS#1-v1.5-Padding (anfällig für Bleichenbacher-/ROBOT-Angriffe). TLS 1.3 hat den RSA-Schlüsseltransport ganz gestrichen.

ECDHE (TLS 1.2 mit ECDHE, TLS 1.3 immer)

Beide Seiten erzeugen pro Verbindung ein frisches X25519-Schlüsselpaar und vergessen es nach dem Handshake. Der langlebige Serverschlüssel (im Zertifikat) wird nur zum Signieren benutzt (CertificateVerify) – er verschlüsselt nichts.

Verbindung 1
eigenes a1, b1
🔑 nur im RAM
Verbindung 2
eigenes a2, b2
🔑 nur im RAM
Verbindung 3
eigenes a3, b3
🔑 nur im RAM

Klicke links auf „gestohlen“ und vergleiche.

✅ Forward Secrecy in einem Satz
Der Schlüssel einer Verbindung hängt nur an Einmal-Geheimnissen, die nach dem Handshake gelöscht werden – deshalb kann ein später erbeuteter Langzeitschlüssel alte Mitschnitte nicht öffnen. TLS 1.3 kennt nur noch (EC)DHE und PSK mit (EC)DHE (psk_dhe_ke); der reine PSK-Modus psk_ke hat keine Forward Secrecy.

⚛️5. Post-Quanten: hybrid X25519 + ML-KEM

Aktueller Stand (September 2026), mit Quellen.

Größe des key_share (Byte)

x25519 0x001Dgemeinsames Geheimnis: 32 Byte
Client
32
Server
32
secp256r1 0x0017gemeinsames Geheimnis: 32 Byte
Client
65
Server
65
X25519MLKEM768 0x11ECgemeinsames Geheimnis: 64 Byte
Client
1216
Server
1120

Client-Anteil = ML-KEM-768-Kapselschlüssel (1184 Byte) + X25519 (32 Byte); Server-Anteil = ML-KEM-Chiffrat (1088 Byte) + X25519 (32 Byte). Das Geheimnis ist die Verkettung beider Einzelgeheimnisse (ML-KEM zuerst) und geht als (EC)DHE-Eingang in denselben HKDF-Schlüsselplan. Der ClientHello wird dadurch größer als ein typisches TCP-Segment.

📚 Quelle: RFC 10024 (August 2026, Standards Track) · secp256r1: unkomprimierter Punkt 1 + 2 × 32 Byte (RFC 8446 §4.2.8.2)

Warum schon jetzt? „Harvest now, decrypt later“

Ein großer Quantencomputer könnte mit dem Shor-Algorithmus diskrete Logarithmen auch auf elliptischen Kurven lösen – X25519 allein wäre dann gebrochen. Wer heute Verkehr mitschneidet, könnte ihn später entschlüsseln. Deshalb wird der Schlüsselaustausch hybrid gemacht: sicher, solange eines der beiden Verfahren hält.

  • 📜 Standard: X25519MLKEM768 ist seit August 2026 als RFC 10024 veröffentlicht (Codepoint 0x11EC).
  • 🌐 Chrome bietet seit Version 131 (Ende 2024) standardmäßig X25519MLKEM768 an (vorher Kyber, 0x6399).
  • 🔧 OpenSSL 3.5 (April 2025) bietet standardmäßig die Keyshares X25519MLKEM768 und X25519 an.
  • ✍️ Zertifikate/Signaturen sind noch klassisch (ECDSA/RSA) – Post-Quanten-Signaturen (ML-DSA) sind größer und werden noch erprobt. Für Signaturen eilt es weniger: sie müssen nur zum Zeitpunkt des Handshakes halten.

📚 Quelle: Google Security Blog, 13.09.2024 · OpenSSL 3.5 NEWS.md · Stand: September 2026