Comment deux ordinateurs peuvent-ils se mettre d’accord sur une clé secrète sans la transmettre directement ? Et comment les probabilités permettent-elles de mesurer la difficulté de la deviner ?
Le candidat relie un usage quotidien — la navigation HTTPS — à des calculs de Terminale : puissances, dénombrement, estimation d’une probabilité et logarithmes. L’exemple d’échange de clés utilise seulement des restes de division, présentés comme une courte ouverture arithmétique hors programme.
Une distinction essentielle structure le raisonnement : échanger un secret, chiffrer les données et authentifier un serveur sont trois opérations différentes.
Chaque fois que je me connecte à un compte ou que je consulte une page en HTTPS, des informations traversent Internet. Elles passent par plusieurs machines et réseaux que je ne contrôle pas. Une question apparaît : comment éviter qu’un intermédiaire puisse lire mon message ou le modifier discrètement ? On répond souvent : « les données sont chiffrées ». Mais cela cache une difficulté : si deux ordinateurs ne se sont jamais rencontrés, comment peuvent-ils se mettre d’accord sur une clé secrète sans transmettre cette clé en clair ? Ma problématique est donc : comment sont chiffrées nos données sur Internet ? Je partirai d’un chiffrement élémentaire, puis je montrerai comment les puissances, les restes de division et les probabilités aident à comprendre une connexion HTTPS. Je distinguerai également la confidentialité des données de l’identité du site visité.
Le principe du chiffrement est de transformer un message lisible, appelé « texte en clair », en un texte incompréhensible pour celui qui ne possède pas la bonne clé. Pour comprendre, imaginons un alphabet numéroté de zéro à vingt-cinq. Avec un décalage de trois lettres, la lettre A, numéro zéro, devient D, numéro trois. Une lettre numérotée \(x\) est transformée selon :
C’est le chiffrement de César : il illustre l’idée d’une clé commune mais il n’est pas sécurisé, car il n’existe que vingt-six décalages possibles. Le chiffrement moderne repose lui aussi sur des transformations calculables dans un sens avec la clé, mais elles sont bien plus complexes et conçues pour résister à de très nombreux essais.
Une méthode de chiffrement est dite symétrique lorsque les deux correspondants utilisent une clé secrète partagée. C’est très efficace pour protéger beaucoup de données : une fois la communication établie, le navigateur et le serveur utilisent des clés de session pour sécuriser les échanges. Mais un problème logique surgit : si j’envoie directement cette clé secrète sur un réseau observable, un espion peut la récupérer. Comment fabriquer un même secret de part et d’autre, sans l’avoir transmis ? Le protocole Diffie–Hellman fournit une idée mathématique remarquable : échanger certaines valeurs publiques calculées à partir de puissances, tout en conservant des exposants privés. Je vais en montrer une version miniature que l’on peut entièrement calculer au tableau.
Choisissons deux nombres publics : \(p=11\) et \(g=2\). Pour simplifier, lorsque j’écris « modulo onze », je ne conserve que le reste de la division euclidienne par onze. Cette petite technique arithmétique est une ouverture au-delà des notions centrales du programme, mais elle ne demande ici que des puissances et des divisions. Alice choisit secrètement \(a=3\), et Bob choisit secrètement \(b=4\). Alice calcule :
Bob calcule :
Alice transmet publiquement huit, Bob transmet publiquement cinq. L’observateur voit donc les nombres onze, deux, huit et cinq ; il ne reçoit pas les exposants privés trois et quatre. Les deux correspondants peuvent maintenant combiner la valeur publique reçue avec leur propre exposant privé. C’est ce calcul qui va créer un secret identique.
Alice reçoit le nombre cinq et élève à sa puissance secrète trois :
Le reste de la division par onze est donc quatre. De son côté, Bob reçoit le nombre huit et l’élève à sa puissance secrète quatre :
Lui aussi obtient quatre ! Les correspondants ont donc calculé le même résultat sans envoyer ce résultat directement sur Internet. Pourquoi cela fonctionne-t-il ? Parce qu’au fond, ils calculent chacun une puissance équivalente à \(g^{ab}\) :
On retrouve exactement les mêmes restes après division par onze. Ici le secret quatre serait évidemment très facile à retrouver : les nombres ont été choisis volontairement trop petits pour être sûrs. Dans la réalité, le mécanisme utilise des paramètres beaucoup plus difficiles à attaquer, souvent liés aux courbes elliptiques, et le secret commun sert ensuite à dériver des clés de session.
Il faut faire une distinction très importante : établir un secret commun ne signifie pas encore chiffrer les données. En HTTPS, le protocole TLS met en place une connexion sécurisée. Il vérifie notamment l’identité du serveur à l’aide d’un certificat et de signatures numériques, puis établit des clés de session. Cette étape d’authentification est essentielle : sans elle, un attaquant placé au milieu pourrait essayer d’établir un secret différent avec chaque correspondant, en se faisant passer pour l’autre. Une fois la connexion établie, les données sont protégées par un chiffrement symétrique authentifié, par exemple AES-GCM ou ChaCha20-Poly1305. Le chiffrement vise la confidentialité ; l’authentification des messages permet également de détecter une modification. Notre petit calcul n’est donc qu’une analogie mathématique du mécanisme d’échange de clés, et non une reproduction complète de TLS.
Une clé binaire de \(n\) bits est une suite de \(n\) chiffres, chacun valant zéro ou un. Pour chaque position, il y a deux choix. Le principe multiplicatif donne donc :
Pour une clé de cent vingt-huit bits, comme dans AES-128, cela représente environ :
Ce chiffre devient encore plus parlant avec une probabilité. Supposons une clé choisie uniformément parmi toutes les possibilités et un adversaire effectuant \(q\) essais distincts sans aucune autre information. La probabilité qu’il devine la clé est alors \(q/2^n\), tant que \(q\le2^n\). Avec mille milliards d’essais, soit \(10^{12}\), et une clé de cent vingt-huit bits, cela donne seulement :
Cette estimation n’est valable que dans notre modèle idéal de recherche exhaustive d’une clé aléatoire ; elle ne mesure pas toutes les façons réelles de compromettre un système.
On peut maintenant utiliser les logarithmes pour répondre à un vrai problème de dimensionnement. Imaginons qu’on autorise \(10^{12}\) essais et qu’on souhaite, dans le modèle précédent, une probabilité de réussite au plus égale à \(10^{-9}\), c’est-à-dire une chance sur un milliard. Il faut imposer :
Cela revient à écrire :
En prenant le logarithme népérien :
Comme \(n\) est un entier :
Attention : ce seuil est un simple exercice de probabilités. Ce n’est pas une recommandation de sécurité. Les systèmes actuels utilisent des tailles et protocoles standardisés, avec des marges de sécurité plus importantes.
Le cadenas du navigateur indique qu’une connexion chiffrée et authentifiée avec le site est établie, mais il ne garantit pas que le site soit honnête. Si je donne mes informations à un site malveillant utilisant HTTPS, il les recevra quand même. De plus, le site destinataire doit généralement pouvoir lire les informations qu’il traite. HTTPS protège donc essentiellement le transport entre le navigateur et le serveur : ce n’est pas automatiquement du chiffrement de bout en bout entre personnes. Enfin, un mot de passe ne devrait normalement pas être conservé en clair sur le serveur. Il est en général vérifié grâce à une fonction de hachage adaptée avec un sel : le hachage n’est pas la même opération que le chiffrement, puisqu’il n’est pas conçu pour être inversé.
Pour comprendre le chiffrement des données sur Internet, il faut donc assembler plusieurs idées. Les puissances et les restes illustrent comment créer un secret commun. Le chiffrement symétrique protège ensuite les échanges. Le certificat permet de vérifier à qui on parle. Enfin, les probabilités, les puissances de deux et les logarithmes permettent d’évaluer l’ampleur d’une recherche exhaustive de clé. La conclusion est que les données sont protégées non par un calcul magique, mais par une coopération de mécanismes mathématiques et de règles de sécurité. Et surtout, la protection du canal ne remplace jamais la vigilance sur le site auquel on confie ses informations.
Le candidat peut tracer deux colonnes « Alice » et « Bob », recopier les nombres publics \(p=11\), \(g=2\), montrer que les deux restes valent \(4\), puis encadrer \(2^128\) et la probabilité de recherche exhaustive.
C’est transformer une donnée lisible en un texte chiffré au moyen d’une clé, afin que la récupération du texte clair nécessite la clé correspondante.
C’est une information utilisée par un algorithme pour chiffrer ou déchiffrer. Il faut la distinguer de l’algorithme, qui peut être public.
En symétrique, les correspondants partagent un secret. En asymétrique, on distingue des informations publiques et privées ; ces mécanismes servent notamment à établir des clés et à authentifier des correspondants.
Un décalage sur vingt-six lettres ne donne que \(26\) possibilités ; un adversaire peut essayer tous les décalages rapidement.
On ne garde que le reste de la division euclidienne par \(11\). Par exemple \(16=11+5\), donc \(16\equiv5\pmod{11}\).
Alice garde \(a=3\) secret, calcule \(2^3=8\) puis publie \(8\).
Bob garde \(b=4\) secret, calcule \(2^4=16\equiv5\pmod{11}\), puis publie \(5\).
Parce que chacun reconstitue une puissance équivalente à \(g^{ab}\) : \((g^a)^b=(g^b)^a\). Ici \(5^3=125\equiv4\pmod{11}\) et \(8^4=4096\equiv4\pmod{11}\).
Les paramètres sont minuscules : avec seulement onze restes possibles, un adversaire retrouve les exposants facilement. Le but est pédagogique, pas cryptographique.
Non. Il utilise des groupes et des paramètres cryptographiques sûrs, souvent un échange éphémère sur courbes elliptiques (ECDHE), dérive plusieurs clés et authentifie le serveur.
Il aide le navigateur à vérifier l’identité du serveur au moyen d’une chaîne de confiance et de signatures. L’échange de clés sans authentification peut être vulnérable à une attaque de l’homme du milieu.
Chaque bit a deux valeurs possibles, donc il existe \(\boxed{2^n}\) chaînes binaires de longueur \(n\).
Parce que \(n\) se trouve dans l’exposant de \(2^n\). Avec \(q\) essais et un risque-cible \(\varepsilon\), on résout \(q/2^n\le\varepsilon\), ce qui conduit à \(n\ge\ln(q/\varepsilon)/\ln2\).
Non. HTTPS sécurise une connexion de transport entre le navigateur et son interlocuteur serveur. Un service peut techniquement lire les données qu’il reçoit.
Non. Le chiffrement est réversible avec une clé ; le hachage calcule une empreinte et n’est pas conçu pour être inversé. Pour les mots de passe, on utilise des procédés de hachage adaptés et salés.
Bob publie \(2^5=32\equiv10\pmod{11}\). Alice calcule \(10^3=1000\equiv10\pmod{11}\). Bob calcule \(8^5=32768\equiv10\pmod{11}\). On retrouve le même secret : \(\boxed{10}\).
Il faut \(10^{15}/2^n\le10^{-12}\), soit \(2^n\ge10^{27}\). Donc \(n\ge27\ln10/\ln2\approx89{,}69\) : \(\boxed{90\text{ bits}}\) dans ce seul modèle de recherche exhaustive.
Un attaquant actif pourrait intercepter les valeurs publiques et exécuter deux échanges différents, l’un avec Alice et l’autre avec Bob. Il faut authentifier le serveur, notamment avec un certificat et une signature.
Il peut viser un logiciel vulnérable, une mauvaise configuration, un mot de passe volé ou un site trompeur. L’espace des clés ne mesure pas à lui seul la sécurité globale d’un système.
Le serveur est l’une des deux extrémités de la connexion TLS. Il déchiffre les données de transport pour traiter la requête. Un chiffrement de bout en bout entre utilisateurs nécessite une couche supplémentaire.
Le petit exemple avec \(p=11\) n’a aucune valeur de sécurité : il sert uniquement à faire apparaître la propriété commune des puissances. Les échanges TLS modernes utilisent notamment des mécanismes éphémères sur courbes elliptiques, des signatures et des algorithmes symétriques sécurisés.
Le nombre \(2^128\) ne suffit pas, seul, à garantir une sécurité réelle : il faut une clé aléatoire, un algorithme sûr, une implémentation correcte et une protection des appareils. Et HTTPS n’empêche pas de transmettre volontairement des données sensibles à un site malveillant.
Phrase de conclusion à retenir : « Les données sont sécurisées grâce à la rencontre de trois idées : établir un secret, prouver l’identité du serveur et chiffrer les échanges avec une clé suffisamment résistante. »