Le chiffrement hybride

TLS emploie à la fois de la cryptographie à clé publique et du chiffrement symétrique. Ce mariage n'est pas un caprice : chacune des deux familles compense le défaut de l'autre.

Le problème de vitesse

La cryptographie à clé publique est lente. Les opérations portent sur des nombres de centaines de chiffres. Chiffrer une vidéo entière avec RSA prendrait un temps absurde.

Le chiffrement symétrique, lui, est très rapide — les processeurs modernes exécutent AES avec des instructions dédiées et traitent des gigaoctets par seconde. Mais il exige une clé partagée à l'avance, ce qui nous ramène au problème de départ.

La solution hybride

(1)   DH  ----------------->  K      (une seule fois, couteux)
(2)   P  --[ AES-GCM, K ]-->  C      (tout le trafic, rapide)

La partie asymétrique, coûteuse, ne sert qu'une fois à établir une clé de session courte. Tout le trafic passe ensuite par le chiffrement symétrique.

Tu obtiens la souplesse de la clé publique — pas de secret préalable — et la vitesse du symétrique.

La confidentialité persistante

Les versions modernes vont plus loin. La clé de session est produite par un Diffie-Hellman éphémère : les exposants sont tirés au hasard pour chaque connexion, puis effacés.

Conséquence remarquable : si la clé privée du serveur est volée l'an prochain, les conversations enregistrées aujourd'hui restent illisibles. Le voleur peut se faire passer pour le serveur à l'avenir, mais ne peut pas remonter le passé.

C'est la confidentialité persistante (forward secrecy), obligatoire en TLS 1.3.

Ce que cela change

Cette propriété répond à une menace bien réelle : enregistrer aujourd'hui du trafic chiffré en pariant sur une clé obtenue plus tard. Sans confidentialité persistante, une seule clé volée déverrouille des années d'archives. Avec elle, il faudrait casser chaque connexion séparément.