Diffie-Hellman

Abkürzung: DH

1976 von Whitfield Diffie und Martin Hellman veröffentlicht, war es die erste Antwort auf eine Frage, die bis dahin als unlösbar galt: Wie vereinbaren zwei Parteien ein Geheimnis, wenn jeder ihre gesamte Unterhaltung mithört? Das Verfahren trägt heute die Schlüsseleinigung in TLS, IPsec und SSH.

Das Grundverfahren

Beide Seiten einigen sich zunächst öffentlich auf zwei Werte: eine große Primzahl p und einen Generator g. Dann rechnet jede Seite für sich:

Alice                                    Bob
wählt geheimes a                         wählt geheimes b
berechnet A = g^a mod p                  berechnet B = g^b mod p

         A  ───────────────────────────────▶
         ◀───────────────────────────────  B

berechnet B^a mod p                      berechnet A^b mod p
           └──────────  identisch  ─────────┘

Beide landen beim selben Wert, weil (g^b)^a und (g^a)^b dasselbe sind. Der Mithörer kennt p, g, A und B — aber um daraus das gemeinsame Geheimnis zu gewinnen, müsste er a oder b bestimmen. Das ist das Problem des diskreten Logarithmus, und für große p ist es praktisch unlösbar.

Bemerkenswert daran: Das Geheimnis wird nie übertragen. Es entsteht auf beiden Seiten unabhängig. Und anders als bei RSA kann mit Diffie-Hellman nichts verschlüsselt und nichts signiert werden — das Verfahren leistet genau eine Sache.

Was es nicht leistet

Hier liegt die wichtigste Einschränkung: Diffie-Hellman authentifiziert nicht. Beide Seiten erhalten ein gemeinsames Geheimnis, aber keine Auskunft darüber, mit wem.

Ein Angreifer in der Mitte kann deshalb zwei Durchläufe führen — einen mit jeder Seite — und sitzt anschließend mit zwei gültigen Schlüsseln dazwischen. Er entschlüsselt, liest, verschlüsselt neu und reicht weiter. Beide Seiten sehen eine einwandfrei verschlüsselte Verbindung.

Deshalb kommt Diffie-Hellman nie allein zum Einsatz. In TLS signiert der Server seinen Anteil mit dem Schlüssel aus seinem Zertifikat; bei IPsec und SSH treten andere Nachweise an diese Stelle. Die Schlüsseleinigung und die Authentifizierung sind zwei getrennte Aufgaben, und das Verfahren erledigt nur die erste.

Ephemeral oder statisch

Der Unterschied steckt in der Frage, wie lange die geheimen Werte a und b leben.

Statisches DH verwendet dauerhafte Schlüssel. Werden sie später bekannt, lässt sich aufgezeichneter Verkehr rückwirkend entschlüsseln.

Ephemeral DH erzeugt für jede Verbindung neue Werte und verwirft sie danach. Ein später kompromittierter Langzeitschlüssel gibt vergangene Sitzungen damit nicht preis — das ist genau Perfect Forward Secrecy.

In Cipher-Suite-Namen ist das als DHE beziehungsweise ECDHE kenntlich, mit dem E für ephemeral. In TLS 1.3 ist die Frage erledigt: Dort gibt es nur noch die flüchtige Variante.

Elliptische Kurven

Dasselbe Verfahren lässt sich in der Gruppe einer elliptischen Kurve ausführen, statt modulo einer Primzahl. Das Ergebnis heißt ECDH und ist heute der Normalfall.

Der Grund ist der Aufwand: Gegen den klassischen diskreten Logarithmus greifen Siebverfahren, die Angriffe deutlich beschleunigen; auf elliptischen Kurven sind sie nicht anwendbar. Entsprechend genügen dort viel kürzere Werte für dasselbe Sicherheitsniveau.

Praktisch verbreitet sind zwei Kurven: NIST P-256 und X25519. Letztere ist jünger, rechnet schneller und ist so entworfen, dass sich die klassischen Implementierungsfehler schwerer machen lassen — sie ist in TLS 1.3 die übliche Wahl.

Die Gruppenfrage

Historisch durften beide Seiten die Parameter frei wählen, was sich als Fehlerquelle erwiesen hat. Ein Server mit einer zu kleinen oder ungeeigneten Primzahl bietet keine verlässliche Sicherheit, und der Client konnte das kaum beurteilen.

Die Antwort sind benannte Gruppen: feste, geprüfte Parametersätze, auf die sich beide Seiten durch Nennung einigen. RFC 7919 definiert sie für DH modulo Primzahl, in TLS 1.3 wird nur noch so verhandelt — über die Erweiterung supported_groups.

Dort schickt der Client im ClientHello bereits einen Schlüsselanteil für die Gruppe, die er für wahrscheinlich hält. Trifft er richtig, steht der Handshake nach einem Umlauf. Trifft er falsch, antwortet der Server mit HelloRetryRequest und benennt die Gruppe, die er erwartet — der Preis ist ein zweiter Umlauf.

Wo es schiefgegangen ist

Logjam, 2015. Die absichtlich geschwächten Export-Parameter aus den neunziger Jahren standen in vielen Serverkonfigurationen noch zur Verfügung. Ein Angreifer konnte eine Verbindung gezielt darauf herunterhandeln, obwohl beide Seiten Besseres beherrschten. Verschärfend kam hinzu, dass sich die aufwändige Vorberechnung bei einer verbreiteten 512-Bit-Gruppe nur einmal lohnt und danach für jede Verbindung mit dieser Gruppe wiederverwendbar ist.

Gemeinsame Gruppen. Dasselbe Argument betrifft auch Gruppen, die niemand für schwach hält: Je verbreiteter eine Gruppe, desto attraktiver die einmalige Vorberechnung. 1024 Bit gelten deshalb heute nicht mehr als ausreichend; die IKE-Gruppen 1, 2 und 5 aus der IPsec-Welt sind abzulehnen.

Fehlende Prüfung des Gegenwerts. Nimmt eine Seite den empfangenen Wert ungeprüft an, lässt sich das gemeinsame Geheimnis in einen sehr kleinen Wertebereich zwingen. Bei elliptischen Kurven kommt die Variante hinzu, dass ein Punkt übermittelt wird, der nicht auf der vereinbarten Kurve liegt.

Hybrid mit Post-Quantum-Verfahren

Der diskrete Logarithmus fällt dem Shor-Algorithmus, auf Kurven ebenso wie modulo einer Primzahl. Für die Schlüsseleinigung ist das die dringlichste Baustelle überhaupt, weil heute mitgeschnittener Verkehr später entschlüsselt werden kann.

Die Übergangslösung ist der hybride Betrieb: Zwei Verfahren laufen parallel, ihre Ergebnisse gehen beide in den Sitzungsschlüssel ein. Die Verbindung bleibt damit sicher, solange mindestens eines hält. In TLS ist das als X25519MLKEM768 in Verbreitung — X25519 und das standardisierte Verfahren ML-KEM nebeneinander. Das BSI verlangt für PQ-Schlüsseleinigung ausdrücklich diese hybride Anwendung. Siehe Post-Quantum-Kryptografie.