Post-quantique : TLS et NTS#

Pourquoi#

Un ordinateur quantique suffisamment puissant casserait en temps polynomial les algorithmes à clé publique utilisés aujourd’hui par TLS (RSA, ECDSA/ECDHE) : c’est l’algorithme de Shor (1994). Aucune machine actuelle n’a la stabilité nécessaire pour y parvenir sur des tailles de clé réalistes, mais la menace concrète n’est pas future : elle est déjà là, sous la forme de l’attaque “harvest now, decrypt later”. Un adversaire peut enregistrer aujourd’hui du trafic chiffré intercepté, et le déchiffrer dans dix ou vingt ans une fois l’ordinateur quantique disponible. Pour un serveur destiné à fonctionner sur le long terme, s’en prémunir dès maintenant est pertinent, même si personne n’espionne activement ce trafic aujourd’hui. Ce n’est plus un sujet de niche : en mai 2026, sous présidence française du G7 et sous l’égide de l’ANSSI, le G7 Cybersecurity Working Group a fait de la transition post-quantique l’une de ses priorités déclarées, jugeant qu’organisations publiques et privées ne peuvent plus se permettre de la repousser.

Soyons honnêtes sur l’enjeu réel. Appliqué au trafic NTP/NTS spécifiquement, le scénario “harvest now, decrypt later” est un peu comique si on le prend au pied de la lettre : la valeur d’un enregistrement chiffré de “il était 14h37m22s le 12 mars” déchiffré dans quinze ans est… proche de zéro. Ce n’est pas comme intercepter des dossiers médicaux ou des communications diplomatiques. La vraie motivation de ce chapitre n’est donc pas “protéger un secret critique”, mais de démontrer que se positionner à l’état de l’art post-quantique est accessible, y compris sur un projet à vocation amateur, la même hygiène cryptographique protège ailleurs (SSH notamment, où le contenu des sessions a une valeur bien réelle) et ne coûte qu’une ligne de configuration une fois comprise. Une enquête de l’ANSSI menée en 2023 auprès de ses bénéficiaires (grandes organisations et opérateurs régulés) constate que plus de la moitié sont déjà exposés à la menace sans le savoir, et que la quasi-totalité n’a ni plan de transition ni échéance identifiée, faute de moyens ou de compréhension des enjeux (ANSSI, Étude sur la transition post-quantique, mars 2025) : la ligne de configuration ci-dessous va, très concrètement, plus loin que ce que beaucoup de grandes structures ont accompli à ce jour.

Ce guide ne vise pas l’exhaustivité en matière de sécurité. Ce chapitre couvre un mécanisme précis (l’échange de clé hybride), pas une politique cryptographique complète. Voir le chapitre Lynis pour une démarche d’audit plus large.

Comment : l’échange de clé hybride#

La parade adoptée par l’industrie n’est pas de remplacer la cryptographie classique par la post-quantique, mais de les combiner :

X25519MLKEM768 = ML-KEM-768 ‖ X25519

Le secret partagé final dérive de la concaténation des deux secrets, le KEM post-quantique ML-KEM-768 (ex-CRYSTALS-Kyber, standardisé NIST FIPS 203) et l’échange de clé elliptique classique X25519, injectée dans le key schedule de TLS 1.3. La propriété de sécurité qui en résulte est simple et robuste : le secret combiné reste indistinguable de l’aléatoire tant qu’au moins un des deux mécanismes reste sûr.

 Si ML-KEM-768 a un défaut     → X25519 sauve la mise
 Si X25519 est cassé (quantique) → ML-KEM-768 sauve la mise
 Il faut casser LES DEUX simultanément pour compromettre l'échange

Activer le hybride pour la page web#

ssl_ecdh_curve X25519MLKEM768:X25519:secp256r1;

L’ordre de cette liste est une liste de préférence décroissante, pas une énumération arbitraire : nginx propose X25519MLKEM768 en premier, et ne retombe sur X25519 (classique, mais rapide et largement supporté) puis secp256r1 (courbe NIST, la plus universellement compatible) que si le client ne sait pas négocier l’option précédente. Un client ancien continue donc de fonctionner sans coupure, tout en profitant du hybride post-quantique dès qu’il le supporte. L’ANSSI détaille ce mécanisme et recommande cette hybridation dans sa fiche technique Transition post-quantique de TLS 1.3 (ANSSI-FT-115, février 2026).

# Vérifier qu'un serveur négocie bien le groupe hybride
openssl s_client -connect time.example.org:443 -groups X25519MLKEM768 </dev/null 2>/dev/null \
    | grep "Negotiated TLS1.3 group"
# Attendu : "Negotiated TLS1.3 group: X25519MLKEM768"

Activer le hybride pour SSH#

# Dans /etc/ssh/sshd_config.d/99-hardening.conf (chapitre Durcissement SSH)
KexAlgorithms mlkem768x25519-sha256,curve25519-sha256@libssh.org,...

La même hybridation, appliquée cette fois au protocole Transport Layer de SSHv2, est détaillée par l’ANSSI dans sa fiche technique Transition post-quantique de SSHv2 (ANSSI-FT-116, février 2026).

Erreurs à éviter#

Ne pas s’attendre à ce que NTS-KE négocie le hybride post-quantique aujourd’hui, même avec un nginx et un OpenSSL à jour. C’est le piège le plus contre-intuitif de ce chapitre : nginx et la page web HTTPS peuvent négocier X25519MLKEM768 dès qu’OpenSSL ≥ 3.5 est disponible, mais chrony ne délègue pas sa couche TLS à OpenSSL : il utilise GnuTLS. La disponibilité du groupe hybride pour le NTS-KE de chrony dépend donc d’abord de la version de GnuTLS embarquée (et de la chaîne de priorités qu’elle expose), pas uniquement de la version de chrony. Au moment de la rédaction de ce guide, chrony 4.6.x ne négocie que des groupes ECDHE classiques (X25519, secp256r1) pour NTS-KE. L’état réel doit être vérifié avant de supposer une protection post-quantique acquise sur le trafic NTS lui-même.

Confondre “certificat post-quantique” et “échange de clé post-quantique”. Aucune autorité de certification publique (Let’s Encrypt incluse) n’émet à ce jour de certificats signés avec un algorithme post-quantique (ML-DSA, SLH-DSA), l’écosystème X.509 public n’est pas encore prêt pour ça, malgré la standardisation NIST de ces algorithmes de signature. Ce chapitre ne concerne que l’échange de clé (KEM), qui protège la confidentialité de la session, pas la chaîne de confiance du certificat lui-même.
Négliger la couche SSH sous prétexte que “c’est juste de l’administration”. Le trafic SSH intercepté et stocké aujourd’hui (commandes tapées, éventuellement des secrets affichés à l’écran) est tout aussi exposé à l’attaque harvest now, decrypt later que le trafic web. OpenSSH ≥ 9.9 supporte mlkem768x25519-sha256, l’activer coûte une ligne de configuration.

Vérifier#

# Web : le groupe hybride est-il proposé et négocié ?
openssl s_client -connect time.example.org:443 -groups X25519MLKEM768 </dev/null 2>/dev/null \
    | grep "Negotiated TLS1.3 group"

# SSH : quels KEX sont réellement actifs ?
ssh -Q kex | grep mlkem
sshd -T | grep -i kexalgorithms

# NTS-KE : constater l'état actuel (probablement classique, pas hybride)
openssl s_client -connect time.example.org:4460 </dev/null 2>/dev/null

Ce chapitre n’a pas vocation à rester figé : la disponibilité du post-quantique évolue rapidement (versions GnuTLS, chrony, OpenSSL). Ce qui compte est la méthode de vérification ci-dessus, pas la conclusion actuelle : ces commandes doivent être relancées périodiquement plutôt que de supposer qu’une conclusion d’aujourd’hui reste valable dans un an. Cette posture correspond à ce que l’ANSSI formalise sous le nom d’agilité cryptographique (crypto-agility) : faire coexister plusieurs mécanismes et pouvoir basculer vers le plus robuste sans casser le service, plutôt que de figer un choix une fois pour toutes (ANSSI, ANSSI’s views on crypto-agility, 2026). Les listes KexAlgorithms/ssl_ecdh_curve de ce guide, hybride post-quantique en tête et repli classique en cas d’incompatibilité, en sont une instance directe.

📚 Pour aller plus loin
L’algorithme de Shor (P. Shor, 1994) casse RSA et ECDSA en temps polynomial sur un ordinateur quantique suffisamment grand.
Le NIST Post-Quantum Cryptography Standardization Process (2016-2024) a sélectionné ML-KEM (ex-CRYSTALS-Kyber, FIPS 203) pour l’encapsulation de clé, et ML-DSA (ex-Dilithium, FIPS 204) / SLH-DSA (ex-SPHINCS+, FIPS 205) pour la signature.
La construction générale de l’échange hybride est spécifiée par l’IETF (draft-ietf-tls-hybrid-design) ; le groupe concret X25519MLKEM768 utilisé ici est défini par draft-ietf-tls-ecdhe-mlkem.
RFC 8446 (TLS 1.3) et RFC 8915 (NTS) restent les protocoles de transport sur lesquels ce mécanisme hybride se greffe, voir les chapitres NGINX/NTS et Chrony pour le protocole lui-même.
ANSSI, Transition post-quantique de TLS 1.3 (ANSSI-FT-115) et Transition post-quantique de SSHv2 (ANSSI-FT-116), février 2026 : les fiches techniques dont ce chapitre reprend les recommandations d’hybridation.
ANSSI, ANSSI’s views on crypto-agility, 2026 : le cadre général (paramétrage vs. remplacement algorithmique, mécanismes statiques vs. actualisables) derrière la recommandation de ne jamais figer un choix cryptographique.
ANSSI, Étude sur la transition post-quantique (enquête auprès des bénéficiaires de l’ANSSI), mars 2025 : l’état des lieux, encore très en retard, qui met en perspective ce que ce chapitre accomplit en une ligne de configuration.
cyber.gouv.fr, dossier « Cryptographie post-quantique » et sa FAQ dédiée, pour une entrée en matière plus large que ce chapitre.