Les deux composants s’exécutent en parallèle et leurs secrets partagés alimentent ensemble la dérivation des clés (key schedule). La RFC 9954 (2026) décrit la conception générale pour TLS 1.3 : chaque hybride est un groupe nommé unique dont la key share est la concaténation des valeurs publiques des composants, et les secrets concaténés remplacent le secret ECDHE. La RFC 10024 enregistre les groupes X25519MLKEM768 (0x11EC), SecP256r1MLKEM768 (0x11EB) et SecP384r1MLKEM1024 (0x11ED).
La motivation est la menace « récolter maintenant, déchiffrer plus tard » : le trafic enregistré aujourd’hui doit rester confidentiel après l’arrivée d’un ordinateur quantique, alors que ML-KEM est encore assez jeune pour qu’il soit prudent de garder un filet de sécurité classique. La publication NIST SP 800-56C autorise cette combinaison, et le rapport NIST IR 8547 (à l’état de projet) propose d’exempter ces hybrides de l’interdiction des algorithmes classiques prévue pour 2035, à condition que la partie post-quantique soit approuvée.
Le déploiement est large : Chrome et Edge 131, Firefox 132 et Safari 26 proposent X25519MLKEM768 par défaut, tout comme OpenSSL 3.5 et Go 1.24, et OpenSSH utilise mlkem768x25519-sha256 par défaut. Le test TLS post-quantique du navigateur montre ce que négocie votre propre navigateur.