Diffie-Hellman (DH) est un protocole qui permet à deux parties de se mettre d’accord sur un secret partagé, en communiquant uniquement sur un canal public — surveillé par un attaquant — sans jamais transmettre ce secret directement. C’est ce secret qui devient ensuite la clé de chiffrement symétrique utilisée pour protéger la conversation.
Le problème qu’il résout
Le chiffrement symétrique (AES…) est rapide, mais il exige que les deux parties connaissent déjà la même clé avant même de commencer à communiquer. Sur Internet, client et serveur ne se sont jamais parlé auparavant — comment échanger cette première clé sans qu’un espion (Mallory), qui voit tout le trafic, puisse la voler au passage ?
L’analogie du mélange de peinture
Étape par étape :
- Une couleur de départ publique : Alice et Bob se mettent d’accord, à voix haute, sur JAUNE. Mallory l’entend aussi — sans conséquence, ce n’est pas un secret.
- Chacun choisit un secret, pour soi seul : Alice choisit ROUGE, Bob choisit BLEU — ni l’un ni l’autre ne le dit à qui que ce soit.
- Chacun mélange son secret à la couleur publique, et envoie le résultat : Alice envoie ORANGE (JAUNE+ROUGE), Bob envoie VERT (JAUNE+BLEU) — sur la ligne publique, vue par Mallory.
- Chacun ajoute son propre secret à ce qu’il vient de recevoir : Alice fait VERT+ROUGE, Bob fait ORANGE+BLEU. Les deux calculs contiennent les mêmes trois couleurs (JAUNE+ROUGE+BLEU), juste ajoutées dans un ordre différent — et mélanger des couleurs, l’ordre ne change pas le résultat final. Les deux obtiennent donc exactement la même couleur finale, sans jamais se l’être envoyée.
Mallory, elle, n’a vu passer que JAUNE, ORANGE et VERT — jamais ROUGE, BLEU, ni la couleur finale. Pour retrouver le secret, il lui faudrait “démélanger” une couleur pour en extraire un ingrédient — une opération qui, avec de la vraie peinture comme en cryptographie réelle, est infaisable en pratique.
Le vrai mécanisme mathématique (résumé)
La peinture est une image ; en réalité, l’opération est une puissance modulaire, pas un mélange de couleurs :
Base publique : g (un nombre, connu de tous)
Secret d'Alice : a Secret de Bob : b
Alice envoie : g^a mod p (publique)
Bob envoie : g^b mod p (publique)
Alice calcule : (g^b mod p)^a mod p = g^(b×a) mod p
Bob calcule : (g^a mod p)^b mod p = g^(a×b) mod p
→ a×b = b×a (la multiplication est commutative)
→ Alice et Bob obtiennent le MÊME nombre final : g^(ab) mod p
Pourquoi Mallory ne peut pas le casser : calculer g^a mod p à partir de g et a est rapide. Mais l’inverse — retrouver a à partir de g^a mod p seul — est un problème appelé logarithme discret, qui devient impraticable à résoudre (même avec beaucoup de puissance de calcul) dès que les nombres utilisés sont assez grands. C’est cette asymétrie (facile dans un sens, quasi impossible dans l’autre) qui rend le protocole sûr — exactement comme “démélanger” une peinture.
ECDHE — la variante utilisée par TLS moderne
Le TLS moderne (1.2/1.3) n’utilise pas le DH “classique” (puissances modulaires sur de grands nombres premiers) mais ECDHE — Elliptic Curve Diffie-Hellman Ephemeral :
- Elliptic Curve (EC) : le même principe, mais basé sur les courbes elliptiques plutôt que sur l’exponentiation modulaire classique — des clés beaucoup plus petites pour un niveau de sécurité équivalent (même logique que ECDSA vu dans X.509 — Format des certificats).
- Ephemeral (E) : une nouvelle paire de clés DH est générée à chaque connexion, puis jetée immédiatement après — jamais réutilisée, jamais stockée.
Application dans TLS et mTLS
C’est exactement le key_share qu’on voit dans le handshake TLS 1.3 :
ClientHello → key_share : g^a mod p (clé publique DH éphémère du client)
ServerHello → key_share : g^b mod p (clé publique DH éphémère du serveur)
→ Les deux parties calculent g^(ab) mod p, en interne, sans jamais l'échanger
→ Ce secret dérive la clé symétrique (AES-256-GCM) qui chiffre tout le reste
de la conversation, handshake inclus à partir de ce point
Voir TLS et SSL pour le détail complet du handshake — tls13_handshake.svg.
Ce mécanisme est strictement identique en mTLS : l’échange DH ne change pas, mTLS ajoute uniquement une étape d’authentification en plus (le client présente aussi son certificat) — voir TLS et SSL section mTLS.
Pourquoi l’aspect “éphémère” (E) est essentiel — Forward Secrecy : les clés DH ne sont jamais stockées et disparaissent après la connexion. Si la clé privée du certificat du serveur fuit plus tard, un attaquant qui aurait enregistré tout le trafic chiffré passé ne peut toujours pas le déchiffrer — parce que ce trafic n’a jamais été chiffré avec cette clé-là, seulement avec un secret DH éphémère depuis longtemps disparu. C’est la propriété “Forward Secrecy” déjà listée dans le tableau de TLS et SSL.
Ce que Diffie-Hellman NE fait PAS
- Il n’authentifie personne — Alice pourrait tout aussi bien être en train de faire cet échange avec Mallory sans le savoir (attaque MITM), si rien ne vient prouver l’identité de l’autre partie. C’est le rôle du certificat X.509 et de sa signature (
CertificateVerify), un mécanisme complètement séparé — voir Chiffrement symétrique vs asymétrique et Comprendre les certificats — Exemple détaillé. - Il ne chiffre rien lui-même — il ne fait que produire un secret partagé, ensuite transformé en clé pour un algorithme de chiffrement symétrique (AES-256-GCM).
En relation avec
- Chiffrement symétrique vs asymétrique — pourquoi TLS a besoin des deux
- TLS et SSL — handshake complet, Forward Secrecy, cipher suites (ECDHE)
- Comprendre les certificats — Exemple détaillé — la signature, qui authentifie séparément
- PKI — Infrastructure à Clés Publiques — hiérarchie de confiance des certificats
- Algorithmes — Vue d’ensemble — les briques cryptographiques utilisées (AES, ECC…)