LLM · tout ou partie
Un des points majeurs en cryptographie est l’établissement des clés : même un excellent algorithme de chiffrement devient inutile si un tiers connaît la clé secrète. Comment Alice et Bob peuvent-ils obtenir un secret commun en communiquant sur un réseau observable ?
Fiche complétée avec l’aide d’un LLM le 27 octobre 2026. La date de publication initiale est conservée.
Échanger une clé ou établir un secret ?
On parle couramment d’« échange de clés », mais deux mécanismes doivent être distingués. Dans un transport de clé, une partie choisit une clé et la transmet sous une forme protégée. Dans un accord de clé, les deux parties contribuent au calcul d’un secret commun. Diffie-Hellman appartient à la seconde famille : le secret final ne traverse pas le réseau.
Diffie-Hellman : un exemple miniature
Le principe repose sur des calculs faciles à effectuer dans un sens, mais difficiles à inverser avec des paramètres correctement choisis. Voici un exemple volontairement minuscule, totalement impropre à la sécurité réelle.
| Étape | Alice | Bob |
|---|---|---|
| Paramètres publics | Nombre premier p = 23 ; base g = 5 | |
| Secret privé | a = 6 | b = 15 |
| Valeur publique envoyée | A = 5⁶ mod 23 = 8 | B = 5¹⁵ mod 23 = 19 |
| Calcul local du secret | Bᵃ mod p = 19⁶ mod 23 = 2 | Aᵇ mod p = 8¹⁵ mod 23 = 2 |
« Modulo » désigne le reste d’une division. Alice et Bob obtiennent le même résultat parce que (gᵇ)ᵃ = (gᵃ)ᵇ = gᵃᵇ, modulo p. Un observateur voit p, g, A et B, mais pas a ni b. Dans ce petit exemple, il retrouverait facilement les secrets ; avec des groupes adaptés, le problème devient beaucoup plus difficile. RFC 2631.
Le résultat n’est pas encore la clé de chiffrement
Le secret calculé est une matière première cryptographique. Une fonction de dérivation, ou KDF, en tire les clés utilisables par le protocole. Elle peut produire des clés distinctes pour chaque sens de communication et les lier au contexte de l’échange.
HKDF en est un exemple courant. Ce traitement évite de confondre le résultat mathématique brut avec une clé directement exploitable par un algorithme comme AES. Il ne remplace toutefois ni un bon générateur aléatoire ni l’authentification. RFC 5869.
Le piège : avec qui partage-t-on le secret ?
Un accord Diffie-Hellman non authentifié ne prouve pas l’identité du correspondant. Un attaquant actif peut intercepter les valeurs publiques et les remplacer. Alice établit alors un secret avec l’attaquant, qui en établit un autre avec Bob : chacun croit parler directement à l’autre.
Un protocole complet doit donc authentifier l’échange : signatures et certificats, clé prépartagée, ou autre mécanisme prévu et vérifié par le protocole. Dans TLS avec certificat, la possession de la clé privée sert à authentifier la négociation ; elle ne doit pas être confondue avec la clé symétrique qui protège ensuite les données. RFC 8446.
Courbes elliptiques et clés éphémères
ECDH applique le principe d’accord de secret à des groupes de points sur une courbe elliptique. Les calculs changent, mais chaque partie conserve une valeur privée, transmet une valeur publique et calcule un secret commun. X25519 est une fonction normalisée permettant de réaliser cet accord ; le nom désigne une primitive, pas un protocole complet. Les validations requises restent celles de la bibliothèque et du protocole utilisés. RFC 7748.
Le « E » final de DHE ou ECDHE signifie éphémère : les secrets privés d’échange sont renouvelés pour la session, puis effacés. Cela permet la confidentialité persistante (forward secrecy) : une compromission ultérieure de la clé d’authentification à long terme ne permet pas, à elle seule, de déchiffrer les sessions anciennes enregistrées.
Cette propriété ne protège pas une session dont les clés ou les extrémités sont déjà compromises. Dans TLS 1.3, les échanges à clé publique utilisent des mécanismes éphémères ; les modes à clé prépartagée doivent être distingués, notamment pour les données anticipées 0-RTT. RFC 8446.
En pratique
- Utiliser un protocole éprouvé et une bibliothèque maintenue, plutôt qu’implémenter cet exemple.
- Vérifier l’identité attendue du correspondant : un secret partagé avec la mauvaise personne reste un secret partagé… avec la mauvaise personne.
- Laisser la bibliothèque gérer les paramètres, l’aléa, les validations et la dérivation des clés.
- Distinguer les clés d’authentification à long terme des secrets éphémères et des clés de trafic.
À retenir
Diffie-Hellman permet de construire un secret commun sans l’envoyer. L’authentification indique avec qui on le partage ; la dérivation fournit les clés utilisables ; le chiffrement protège ensuite les données. Ce sont des rôles complémentaires.