Chapitre 3.2 — Symétrique, asymétrique, TLS

⏱️ TL;DR — Deux familles de chiffrement. Symétrique : une seule clé partagée chiffre et déchiffre (ex. AES-GCM) — rapide, mais il faut transmettre la clé de façon sûre. Asymétrique : une paire clé publique / clé privée ; ce que l’une chiffre, seule l’autre déchiffre (ex. RSA, courbes elliptiques) — pas besoin de partager un secret au préalable, mais c’est lent. La solution du monde réel, dont TLS : utiliser l’asymétrique pour échanger en sûreté une clé de session, puis l’symétrique (rapide) pour chiffrer le reste. Comprendre ce mariage éclaire TLS, SSH, les JWT signés et les signatures.

🎯 Objectifs

• Distinguer chiffrement symétrique et asymétrique (clés, vitesse, usage).
• Comprendre le problème de distribution de clé que l’asymétrique résout.
• Expliquer comment TLS combine les deux (handshake asymétrique → session symétrique).
• Relier ces notions à la signature (asymétrique inversé) vue au chapitre 3.4.

Symétrique : une clé pour tout

En chiffrement symétrique, la même clé secrète sert à chiffrer et à déchiffrer. C’est l’analogie du cadenas à clé unique : qui a la clé ouvre et ferme.

clair --AES(clé K)--> chiffré --AES(clé K)--> clair

• Avantage : rapide et efficace, adapté à de gros volumes (tout le trafic d’une session, un fichier). L’algorithme moderne de référence est AES (souvent en mode GCM, qui apporte aussi l’intégrité/authenticité), ou ChaCha20-Poly1305.
• Le problème : les deux parties doivent partager la même clé secrète — mais comment la transmettre sans qu’un espion l’intercepte ? Si Alice envoie la clé à Bob sur un réseau surveillé, l’attaquant la capte et lit tout. C’est le problème de distribution de clé, que le symétrique seul ne résout pas.

💡 Réflexe — Quand tu chiffres des données « au repos » (un champ en base, un fichier), tu es presque toujours en symétrique (AES-GCM) : une clé, que tu détiens des deux côtés (c’est le même serveur). Le vrai sujet devient alors où ranger cette clé en sûreté (vault, pas le code) — voir Partie 13. Le mode compte : privilégie un mode authentifié (GCM) qui garantit aussi l’intégrité, pas seulement la confidentialité.

Asymétrique : deux clés liées

Le chiffrement asymétrique (à clé publique) utilise une paire de clés mathématiquement liées :

• une clé publique, qu’on distribue à tout le monde ;
• une clé privée, gardée secrète.

La propriété clé : ce que l’une chiffre, seule l’autre peut le déchiffrer. Deux usages en découlent :

• Avantage : pas besoin de partager un secret au préalable. On peut publier sa clé publique au grand jour ; elle ne permet pas de retrouver la privée. Cela résout le problème de distribution.
• Le problème : c’est lent et limité en taille de données. On ne chiffre pas des mégaoctets en asymétrique — ce serait inefficace.

💡 Réflexe — Retiens l’asymétrie par le cadenas : ta clé publique est un cadenas ouvert que tu sèmes partout ; n’importe qui peut fermer un message pour toi avec, mais seule ta clé privée l’ouvre. Pour la signature, c’est l’inverse : tu fermes avec ta privée, et tout le monde vérifie avec ta publique que c’est bien toi qui as fermé.

Le mariage des deux : TLS

Chaque famille a une faiblesse que l’autre comble : le symétrique est rapide mais peine à distribuer la clé ; l’asymétrique distribue sans secret préalable mais est lent. La solution universelle — celle de TLS, de SSH, de la messagerie chiffrée — est de les combiner :

1. Handshake asymétrique : le client vérifie le certificat du serveur (sa clé publique, signée par une CA — voir chapitre 2.3) et, via un échange de clés, les deux parties établissent une clé de session partagée sans jamais la transmettre en clair.
2. Session symétrique : tout le trafic qui suit est chiffré symétriquement avec cette clé de session — rapide, pour tout le volume.

C’est le meilleur des deux mondes : l’asymétrique pour s’entendre en sûreté sur une clé (et authentifier le serveur), le symétrique pour chiffrer vite ensuite. Les protocoles modernes ajoutent la forward secrecy (une clé de session compromise ne compromet pas les sessions passées).

🎯 Côté attaquant — L’attaquant qui écoute un handshake TLS ne voit passer aucune clé de session en clair : elle est établie de façon à ce qu’un observateur passif ne puisse pas la reconstituer. Sa cible se déplace alors ailleurs : voler la clé privée du serveur (d’où l’importance de la protéger), pousser un certificat frauduleux (d’où la vérification par CA), ou exploiter de vieux protocoles faibles (d’où « TLS 1.2/1.3 seulement »). La crypto bien utilisée déplace l’attaque vers la gestion des clés et la configuration.

Où le dev rencontre tout ça

• TLS/HTTPS : géré par la plateforme et le serveur web ; ton job est de l’activer et de le configurer correctement (protocoles récents, certificats valides — Serveur Linux).
• JWT signés : un JWT en RS256 utilise une signature asymétrique (le serveur signe avec sa privée, les autres vérifient avec la publique) ; en HS256, une HMAC symétrique (secret partagé). Voir chapitre 3.4.
• Chiffrement de données au repos : presque toujours symétrique (AES-GCM), avec la question de la clé.
• SSH, signatures de paquets, provenance : asymétrique.

Dans tous les cas : tu utilises des bibliothèques éprouvées (libsodium/crypto de Node, sodium/OpenSSL de PHP, le composant Symfony\Component\...), tu ne réimplémentes jamais l’algorithme.

🧭 Sur FormaCampus — FormaCampus s’appuie sur TLS (asymétrique + symétrique) pour tout son trafic, et sur des clés asymétriques pour ses jetons inter-services signés en RS256 (l’API signe avec sa clé privée, les autres services vérifient avec la publique — pas de secret partagé à diffuser). Le peu de données chiffrées au repos l’est en AES-GCM (symétrique), la clé vivant dans le vault. Aucune primitive n’est réimplémentée : uniquement les bibliothèques standard.

✏️ Exercices

Exercice 1 — Symétrique ou asymétrique ? Pour chaque cas, dis quel type de chiffrement convient : (a) chiffrer 2 Go de sauvegarde sur un même serveur ; (b) permettre à n’importe qui de t’envoyer un message que toi seul peux lire, sans échange de secret préalable ; (c) tout le trafic d’une session web après le handshake.

Exercice 2 — Explique le mariage. En deux ou trois phrases, explique pourquoi TLS n’utilise pas uniquement de l’asymétrique (qui pourtant résout la distribution de clé).

🧠 Quiz de révision

Chapitre suivant : Hacher les mots de passe — pourquoi un SHA ne suffit pas, et comment stocker un mot de passe correctement avec argon2id.