SSH et TLS post-quantiques

La cryptographie post-quantique a passé une décennie comme sujet de conférence, puis elle est devenue, sans bruit, la valeur par défaut de votre ordinateur portable. Si vous utilisez OpenSSH 10 et un navigateur des deux dernières années, l'essentiel de votre trafic est déjà protégé contre un adversaire quantique et personne ne vous a prévenu. Ce qu'il reste à faire est étroit, peu spectaculaire et très concret : retrouver les connexions restées en arrière. Ce guide explique comment procéder sur une infrastructure réelle — quoi vérifier, quoi changer, comment le contrôler ensuite, et quelle partie du problème il vaut mieux ne pas toucher pour l'instant.

Ce qui rend le sujet abordable, c'est une séparation. La cryptographie protège vos connexions de deux manières : l'échange de clés, qui détermine le secret chiffrant la session, et les signatures, qui prouvent à qui vous parlez. Un ordinateur quantique casse les deux. Mais une seule est urgente aujourd'hui, et confondre les deux explique pourquoi tant de programmes post-quantiques s'enlisent dans un tableur. Tout ce qui suit découle de cette distinction.

Où en est réellement la cryptographie post-quantique en 2026

L'échange de clés, c'est fait. Ni planifié ni en pilote : publié, activé par défaut et en production. OpenSSH propose un échange de clés post-quantique depuis la version 9.0 d'avril 2022, et depuis OpenSSH 10.0 en avril 2025 l'hybride mlkem768x25519-sha256 est l'algorithme par défaut. OpenSSL 3.5.0, publié la veille, a modifié sa liste par défaut de groupes TLS pour inclure et privilégier les groupes hybrides post-quantiques, et propose désormais X25519MLKEM768 comme keyshare par défaut. Si vous avez mis à jour l'un de ces paquets dans l'année, vous avez activé tout cela sans rien faire.^{[ssh100][ossl35]}

Les mesures confirment. Cloudflare publie depuis 2023 des chiffres d'adoption de l'échange de clés post-quantique, et la courbe est passée d'une erreur d'arrondi à la majorité du trafic web humain en deux ans environ. Consultez le chiffre en direct plutôt que de faire confiance à un article, y compris celui-ci : l'important n'est pas le pourcentage exact mais la forme de la courbe, qui vous dit que les retardataires forment désormais un ensemble fini et énumérable, et non plus tout l'internet.^{[cfpq][cfradar]}

Pour les signatures, c'est l'histoire inverse. Le NIST a normalisé ML-DSA et SLH-DSA en 2024, les implémentations existent, et rien de tout cela n'est déployable sur le web public, car un certificat ne sert que si la partie qui le valide fait déjà confiance à la racine qui l'a signé — et aucune racine post-quantique ne figure dans les magasins de confiance des navigateurs. Ce n'est pas un problème temporaire d'empaquetage que l'on contourne par l'ingénierie : c'est un problème de séquencement de l'écosystème, et cela prendra des années.

Moissonner maintenant, déchiffrer plus tard — et ce que cette attaque ne couvre pas

Si l'échange de clés est urgent et pas les signatures, cela tient à une seule asymétrie, qu'OpenSSH énonce plus clairement que la plupart des documents commerciaux :^[pq]

Toute la confidentialité d'une connexion SSH repose sur l'échange cryptographique de clés. Si un attaquant parvient à le casser, il peut déchiffrer et lire la session entière. Il n'a pas besoin de mener l'attaque en temps réel : il peut collecter aujourd'hui des sessions SSH chiffrées et les déchiffrer plus tard, une fois qu'il aura accès à un ordinateur quantique.^[pq]

C'est la moisson maintenant, déchiffrement plus tard, une attaque rétroactive. Une session capturée aujourd'hui sur le câble, avec un échange classique, est un passif permanent : elle dort dans une archive jusqu'à l'existence d'un ordinateur quantique cryptographiquement pertinent, puis elle s'ouvre. Rien de ce que vous ferez en 2032 ne réparera une session enregistrée en 2026. Les signatures n'ont pas d'équivalent, car falsifier une signature après coup ne permet pas de revenir usurper une identité dans une conversation déjà tenue. D'où une règle de priorisation nette :

• Données confidentielles à longue durée de vie sur des liens durables. Réplication de bases de données sur WAN, transferts de sauvegardes, tunnels VPN entre sites, sessions SSH où vous collez des identifiants. À traiter en premier : la charge utile conserve sa valeur une décennie ou plus.
• Trafic empruntant un chemin non fiable. Tout ce qui sort de votre réseau et, dans un modèle de menace sérieux, tout ce qui traverse le backbone d'un fournisseur cloud. La capture coûte peu à qui détient la position ; le stockage coûte encore moins.
• Liens machine à machine où personne ne se connecte. Ce sont ceux que l'audit rate, faute d'un humain pour voir un avertissement. Maillages de services, files de messages, canaux de réplication, agents de supervision.
• Trafic interne, éphémère et de faible valeur. Un health check entre deux pods du même nœud ne justifie pas un ticket de migration. Écrivez-le, pour que l'exception soit une décision et non un oubli.

Les estimations sur l'arrivée d'un ordinateur quantique cryptographiquement pertinent vont de cinq à vingt ans, beaucoup d'observateurs visant le milieu des années 2030. Vous n'avez pas besoin d'avoir un avis sur ce chiffre. Vous devez savoir si les données que vous transmettez aujourd'hui seront encore sensibles à cette échéance — et pour l'essentiel des infrastructures, la réponse honnête est oui.^[pq]

Corriger SSH

SSH est le gain facile et le bon point de départ, parce qu'OpenSSH a déjà fait le plus dur. Aucun plugin, aucun fournisseur à installer, aucune branche expérimentale. Un numéro de version et une ligne de configuration, tous deux documentés par le projet.^{[ssh100][pq][ssh105][sshrel]}

Deux pièges se cachent dans ce tableau. Le premier est le nom : la forme courte sntrup761x25519-sha512 n'existe qu'à partir de la 9.9, il faut donc écrire la variante @openssh.com sur tout ce qui est antérieur, et sshd refuse de démarrer sur un nom qu'il ne reconnaît pas. Le second est plus insidieux. Figurer dans la liste par défaut n'est pas la même chose qu'y être choisi : sur OpenSSH 8.9, l'algorithme post-quantique est bien dans le KexAlgorithms par défaut, mais en sixième position, sous curve25519-sha256. Tout client moderne négocie donc un échange classique face à ce serveur, pendant que le serveur annonce en toute honnêteté une prise en charge post-quantique. C'est exactement pour cela que cet article insiste pour lire le résultat négocié plutôt que la liste des capacités.^{[ssh85][ssh99][ntru]}

Étape 1 : découvrir ce que vous négociez réellement

Avant de changer quoi que ce soit, mesurez. La distinction qui fait trébucher tout le monde est celle entre pris en charge et négocié : un serveur peut prendre en charge ML-KEM et conclure malgré tout un échange classique, parce qu'un client obsolète l'a demandé et que la liste de préférences du serveur l'autorisait. Seul l'algorithme négocié vous dit si une connexion donnée a réellement été protégée.

# 1. Your client. Anything older than 8.5 has no post-quantum key agreement
#    at all; 8.5 through 9.8 have it only under the @openssh.com vendor name.
ssh -V
# OpenSSH_10.5p1, OpenSSL 3.5.7 9 Jun 2026

# 2. The remote server's software version, straight from the protocol banner.
ssh -v server.example.com exit 2>&1 | grep 'remote software version'
# debug1: Remote protocol version 2.0, remote software version OpenSSH_10.3

# 3. Which key agreement algorithms your local build even supports.
ssh -Q kex | grep -E 'mlkem|sntrup'
# mlkem768x25519-sha256
# sntrup761x25519-sha512

# 4. Supported is not preferred. On OpenSSH 8.9, for example, the PQ algorithm
#    is in the default list but sixth in it, so it is offered and never chosen:
ssh -G server.example.com | grep -i '^kexalgorithms'
# kexalgorithms curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,
# ecdh-sha2-nistp384,ecdh-sha2-nistp521,sntrup761x25519-sha512@openssh.com,...
#                                       ^ present, but nothing will ever pick it

# 5. The only answer that matters: what did THIS connection actually agree on?
#    Everything above is capability; this line is the negotiated result.
ssh -v server.example.com exit 2>&1 | sed -n 's/.*kex: algorithm: /negotiated: /p'
# negotiated: mlkem768x25519-sha256

Dès que vous savez lire cette ligne pour un hôte, vous savez la lire pour tous. OpenSSH 10.1 a ajouté côté client un avertissement lorsque la connexion négocie un échange non post-quantique : excellent pour les humains, inutile pour les liens automatisés qui constituent l'essentiel d'une flotte réelle. Balayez donc vous-même :^[ssh101]

#!/usr/bin/env bash
# pq-ssh-sweep.sh - classify every host in hosts.txt by negotiated key agreement.
# Read-only: it opens a connection, runs `exit`, and reads the debug output.
set -uo pipefail

while read -r host; do
  [ -z "$host" ] && continue
  # </dev/null matters: without it ssh swallows the rest of hosts.txt from the
  # loop's stdin and you silently audit only the first host.
  alg=$(ssh -o BatchMode=yes -o ConnectTimeout=5 -o StrictHostKeyChecking=accept-new \
        -v "$host" exit </dev/null 2>&1 | sed -n 's/.*kex: algorithm: //p' | head -1)
  case "$alg" in
    mlkem*)   printf '%-38s PQ-ML-KEM  %s\n' "$host" "$alg" ;;
    sntrup*)  printf '%-38s PQ-LEGACY  %s\n' "$host" "$alg" ;;
    "")       printf '%-38s UNREACHED  (auth, firewall or timeout)\n' "$host" ;;
    *)        printf '%-38s CLASSICAL  %s\n' "$host" "$alg" ;;
  esac
done < hosts.txt

# PQ-ML-KEM  -> done, nothing to do.
# PQ-LEGACY  -> safe today (sntrup761 is quantum-resistant) but not the NIST
#               standard; schedule the upgrade to OpenSSH 9.9+ anyway.
# CLASSICAL  -> this is your harvest-now-decrypt-later exposure. Fix first.

Étape 2 : modifier la configuration, prudemment

Une fois le relevé en main, la modification est minime. Placez-la dans un fichier drop-in plutôt que de toucher à la configuration principale : elle reste repérable, réversible et manifestement la vôtre.^{[sshdcfg][ssh99]}

# /etc/ssh/sshd_config.d/50-post-quantum.conf
# Requires `Include /etc/ssh/sshd_config.d/*.conf` in the main sshd_config,
# which Debian, Ubuntu, RHEL and Fedora already ship. Check with:
#   grep -r '^Include' /etc/ssh/sshd_config

# --- OpenSSH 9.9 and newer ---
# Post-quantum first, classical last. The list is ordered by preference, and
# the two hybrids are the only entries here that resist a quantum adversary.
KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512,curve25519-sha256,curve25519-sha256@libssh.org

# --- OpenSSH 9.0 to 9.8: NEITHER name above exists on those builds. ---
# ML-KEM only arrived in 9.9, and until 9.9 the NTRU Prime hybrid existed
# solely under its vendor extension name. sshd refuses to start on an
# unknown algorithm name, so on those versions use exactly this line and
# nothing from the one above:
#   KexAlgorithms sntrup761x25519-sha512@openssh.com,curve25519-sha256
# Confirm which names your build accepts before editing:  ssh -Q kex

# Signatures are NOT the urgent problem (see the article), but this is a good
# moment to drop the algorithms that are weak for classical reasons too.
HostKeyAlgorithms ssh-ed25519,ssh-ed25519-cert-v01@openssh.com,rsa-sha2-512,rsa-sha2-256
PubkeyAcceptedAlgorithms ssh-ed25519,ssh-ed25519-cert-v01@openssh.com,sk-ssh-ed25519@openssh.com,rsa-sha2-512,rsa-sha2-256

Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com

# --- Validate BEFORE reloading, and keep your current session open. ---
#   sudo sshd -t && sudo systemctl reload ssh   # or sshd, depending on the distro
# Then open a SECOND session and confirm it works before closing the first.

Ne sautez pas le rituel de validation. Lancez sshd -t avant de recharger, gardez votre session ouverte et ouvrez-en une seconde pour confirmer avant de fermer la première. Une coquille dans KexAlgorithms vous verrouille hors de la machine, et sur un hôte sans accès console ce n'est pas un incident : c'est une réinstallation.

Côté client, vous pouvez vous permettre plus de rigueur : échouer bruyamment sur votre propre poste est acceptable, sur un rebond partagé non. Le motif qui survit au réel est un défaut strict assorti d'exceptions explicites et datées :^[sshcfg]

# ~/.ssh/config - client side
#
# ssh_config is FIRST-OBTAINED-VALUE-WINS, not last. The specific block must
# come BEFORE `Host *`, otherwise the general block wins and the exception
# below is silently dead. This is the single most common mistake in hardened
# client configs, and it fails in the direction you will not notice.

# Exceptions first: the boxes you have not fixed yet. Make each one explicit
# and dated, so it shows up in review instead of quietly becoming permanent.
Host legacy-nas.internal jump-2019.example.com
    # TODO(2026-11-30): appliance firmware pending, ticket OPS-4471
    # Note this REPLACES the list rather than using `+`, which would append to
    # the full compiled-in default and quietly re-enable every modp group.
    KexAlgorithms curve25519-sha256,diffie-hellman-group-exchange-sha256
    WarnWeakCrypto no-pq-kex

# ...and the hard default for everything else.
Host *
    KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512
    WarnWeakCrypto yes

# Verify the result rather than trusting the file. `ssh -G` prints the
# effective configuration for a given destination, after all matching:
#   ssh -G legacy-nas.internal | grep -i '^kexalgorithms'
#   ssh -G anything-else.example.com | grep -i '^kexalgorithms'

Deux détails à intégrer. D'abord, tous les algorithmes post-quantiques implémentés par OpenSSH sont hybrides : mlkem768x25519-sha256 exécute ML-KEM aux côtés de X25519 et combine les deux, de sorte que si une cryptanalyse future casse ML-KEM, le résultat n'est pas plus faible que l'échange classique que vous utilisiez auparavant. Il n'existe pas de scénario perdant. Ensuite, si vous êtes sur OpenSSH 9.x sans pouvoir migrer, l'hybride NTRU Prime est résistant au quantique et disponible depuis la 9.0, mais attention au nom : avant la 9.9 il n'existe que sous la forme sntrup761x25519-sha512@openssh.com, la forme courte étant rejetée. Ce n'est pas l'algorithme du NIST, mais il stoppe l'attaque par moisson dès aujourd'hui, ce qui est l'essentiel.^[pq]

Corriger TLS

TLS suit la même forme avec un autre levier. Les primitives résident dans OpenSSL, pas dans votre serveur web : avec OpenSSL 3.5 ou plus récent, ni correctif, ni oqs-provider, ni nginx forké. Vérifiez d'abord la bibliothèque, car c'est là que se nichent la plupart des surprises : une distribution peut livrer un nginx à jour lié à un OpenSSL parfaitement incapable de faire du ML-KEM.^{[ossl35][tlsdraft][mlkemkex]}

# 1. ML-KEM needs OpenSSL 3.5.0 or newer. No 3.x before 3.5 can do it at all,
#    however recent the rest of the stack looks.
openssl version
# OpenSSL 3.5.7 9 Jun 2026

# 2. Confirm the provider actually exposes the primitives.
openssl list -kem-algorithms | grep -i mlkem
openssl list -signature-algorithms | grep -iE 'ML-DSA|SLH-DSA'

# 3. What does a live endpoint negotiate when the client offers the hybrid?
openssl s_client -connect www.example.com:443 -servername www.example.com \
  -groups X25519MLKEM768 -tls1_3 </dev/null 2>/dev/null \
  | grep -E 'Negotiated TLS1.3 group|Protocol  :|Cipher    :'
# Negotiated TLS1.3 group: X25519MLKEM768

# 4. Control test: the same endpoint must still serve a classical-only client,
#    otherwise you have not hardened it, you have broken it.
openssl s_client -connect www.example.com:443 -servername www.example.com \
  -groups X25519 -tls1_3 </dev/null 2>/dev/null \
  | grep 'Negotiated TLS1.3 group'
# Negotiated TLS1.3 group: X25519

Notez le test de contrôle à l'étape quatre. Activer un groupe hybride n'est pas censé casser les clients classiques ; si cela arrive, vous avez mal configuré la liste, vous n'avez pas durci quoi que ce soit. L'ordre compte, l'exclusivité non : hybride devant, courbes classiques derrière.^[osslgroups]

# Pick the ONE stanza that matches your terminator - this is four different
# config syntaxes in one block, not a file you can paste as-is.

### nginx (built against OpenSSL 3.5+; no patches, no oqs-provider needed)
# ssl_ecdh_curve feeds the TLS supported-groups list. Hybrid first, then the
# classical curves that keep older clients working.
ssl_protocols       TLSv1.3 TLSv1.2;
ssl_ecdh_curve      X25519MLKEM768:X25519:secp256r1;
ssl_prefer_server_ciphers off;

### HAProxy 3.x
ssl-default-bind-curves X25519MLKEM768:X25519:secp256r1

### Apache httpd (mod_ssl passes the list straight to OpenSSL)
SSLOpenSSLConfCmd Groups X25519MLKEM768:X25519:P-256

### OpenSSL system-wide default, for everything that reads openssl.cnf
# [openssl_init] -> ssl_conf -> system_default
Groups = X25519MLKEM768:X25519:secp256r1

La configuration tient en une ligne par serveur et alimente dans tous les cas la même liste de groupes OpenSSL :^{[nginxssl][haproxy][osslconf]}

Un seul point d'architecture à ne pas rater : cela ne vaut que là où TLS est terminé. Si un CDN ou un répartiteur de charge termine pour vous, c'est ce saut qui a besoin du groupe hybride, et la configuration de votre origine est une question distincte — tout comme le lien entre les deux, précisément le segment interne que l'on oublie. Si vous terminez dans Kubernetes, cela relève de la passerelle, et la migration depuis ingress-nginx est le moment naturel pour le faire, puisque vous réécrivez ces objets de toute façon.^[rfc8446]

Un inventaire défendable

Tout ce qui précède se raisonne par hôte. Ce que les auditeurs — et votre vous futur — demanderont, c'est la couverture : non pas « cet endpoint est-il corrigé » mais « combien y en a-t-il et lesquels ne le sont pas ». Construisez la liste depuis la source de vérité en laquelle vous avez déjà confiance, et non depuis un scan, pour que l'absence ait un sens :

#!/usr/bin/env bash
# pq-inventory.sh - a starting point, not a CBOM. One line per listener, with
# the negotiated group, so the output diffs cleanly between runs.
set -uo pipefail
printf '%-34s %-9s %-22s %s\n' HOST PORT GROUP NOTE

while IFS=: read -r host port; do
  out=$(openssl s_client -connect "$host:$port" -servername "$host" \
        -groups X25519MLKEM768:X25519 -tls1_3 </dev/null 2>/dev/null)
  grp=$(printf '%s' "$out" | sed -n 's/^Negotiated TLS1.3 group: //p')
  sig=$(printf '%s' "$out" | sed -n 's/^Peer signature type: //p')
  case "$grp" in
    *MLKEM*) note="pq-ok" ;;
    "")      note="no-tls1.3-or-unreachable" ;;
    *)       note="classical-only" ;;
  esac
  printf '%-34s %-9s %-22s %s (sig %s)\n' "$host" "$port" "${grp:--}" "$note" "${sig:--}"
done < endpoints.txt

# endpoints.txt is one host:port per line. Feed it from whatever you already
# trust as the source of truth - the load balancer config, Consul, the CMDB -
# rather than from a network scan, so that absence is meaningful.

Résistez à l'envie d'acheter un produit d'inventaire cryptographique avant d'avoir fait tourner quelque chose de ce genre. L'outillage progresse réellement, mais la première passe mérite d'être faite à la main : elle vous apprend la forme de votre propre parc, ce qu'aucun éditeur ne peut vous fournir. Ordre de travail :

1. Terminaison TLS externe. Tous les noms publics. Liste la plus courte, exposition la plus forte, généralement réglée par un changement en bordure.
2. SSH, partout. Les rebonds d'abord, puis tout ce qui est joignable depuis eux. C'est là qu'émerge la longue traîne d'appliances, d'équipements réseau et de machines virtuelles oubliées.
3. TLS interne entre services. Maillage de services, connexions bases de données, brokers de messages. Liste plus longue, plus difficile à énumérer, et endroit où les valeurs par défaut du maillage ont peut-être déjà réglé la question.
4. VPN et tunnels site à site. Durables, à forte valeur et souvent sur firmware constructeur avec son propre calendrier. Engagez tôt la discussion avec le fournisseur : c'est plus un problème d'achats qu'un problème technique.
5. Tout l'embarqué. Équipements, agents, imprimantes, caméras, automates industriels. Documentez, acceptez explicitement le risque et datez cette acceptation.

Gardez une sortie comparable et relancez-la périodiquement. Un chiffre qui évolue dans le mauvais sens est le signal le plus précoce qu'une image reconstruite ou un paquet rétrogradé a discrètement annulé le travail — et cette défaillance est bien plus fréquente qu'une migration ratée.

Signatures et certificats : pourquoi il faut attendre

Vient maintenant la partie où le bon conseil consiste à en faire moins. Le NIST a normalisé en 2024 deux schémas de signature post-quantiques, ML-DSA et SLH-DSA, tous deux implémentés dans OpenSSL 3.5. Vous pouvez générer les clés aujourd'hui. Vous ne devriez pas les mettre dans votre chaîne de certificats.^{[fips204][fips205][fips203]}

La raison est celle qu'OpenSSH avance pour justifier la priorité donnée à l'échange de clés : il n'existe pas d'attaque « stocker maintenant, falsifier plus tard ». Une signature doit seulement être infalsifiable à l'instant où elle est vérifiée. L'urgence sur les signatures ne concerne pas le trafic d'aujourd'hui, mais le retrait des clés de signature classiques avant l'existence d'un ordinateur quantique cryptographiquement pertinent — une échéance qui se mesure en années, pas en paquets capturés.^[pq]

Les blocages pratiques ont la forme de l'écosystème, et aucun ne vous appartient :

• Aucune racine post-quantique n'est reconnue par les navigateurs. Une chaîne de certificats ne vaut que par la racine à laquelle la partie validante fait déjà confiance, et ces magasins évoluent sur plusieurs années, pour de bonnes raisons.
• Le problème de taille est réel. Les signatures et clés publiques ML-DSA sont sensiblement plus grandes que celles d'ECDSA. Dans une poignée de main transportant la chaîne complète, cela se mesure en allers-retours supplémentaires sur des liens à pertes, pas en octets abstraits.
• OpenSSH n'a qu'un schéma de signature post-quantique expérimental. Le projet a retiré la prise en charge expérimentale de XMSS en 10.1, puis ajouté en 10.4 (juillet 2026) un schéma composite mldsa44-ed25519 associant ML-DSA-44 et Ed25519. Il est explicitement expérimental et non activé par défaut : c'est à vous de l'ajouter à HostKeyAlgorithms et PubkeyAcceptedAlgorithms et de générer les clés avec ssh-keygen -t mldsa44-ed25519. Bon à savoir ; pas encore bon à mettre sous des clés d'hôte de production.^{[ssh104][mldsased][ssh101]}
• Tous les intermédiaires doivent être d'accord. La validation implique votre serveur, le client, chaque middlebox qui inspecte et tout pinning ajouté par quelqu'un en 2019. Les signatures échouent en mode fermé, et pour tout le monde à la fois.

Que faire alors des signatures en 2026 ? Deux choses, toutes deux peu coûteuses. Retirer les algorithmes déjà faibles pour des raisons classiques : DSA a totalement disparu d'OpenSSH 10.0, et les signatures SHA-1 auraient dû partir depuis des années. Et rendre l'émission de certificats automatique et à courte durée de vie, pour que le jour où des certificats post-quantiques deviendront émissibles, les remplacer soit un changement de configuration et non un projet. L'agilité cryptographique n'est pas un produit qu'on achète : c'est la propriété de savoir déjà tourner vite, que vous devriez souhaiter pour des raisons sans rapport. On retrouve ici l'instinct des architectures ennuyeuses : l'option exotique n'est pas l'option sûre.^[ssh103]

Le calendrier réglementaire, énoncé avec exactitude

Les échéances sont l'endroit où les articles techniques deviennent faux sans s'en rendre compte, alors voici la version soigneuse. NIST IR 8547, le document que tout le monde cite pour « RSA est déprécié en 2030 », est un projet public initial publié en novembre 2024. Sa période de commentaires s'est close en janvier 2025 et les commentaires reçus sont publics. Il signale l'approche attendue du NIST et constitue la bonne base de planification, mais le citer comme une norme finale et contraignante est inexact — et quelqu'un dans votre revue le saura.^[ir8547]

La distinction compte en pratique : un projet vous indique vers où se déplace le plancher, ce qui suffit pour planifier. Cela ne suffit pas pour écrire « exigé par le NIST » dans un document de conception. Citez-le pour ce qu'il est, et votre programme survivra à sa première revue sérieuse.^[ir8547]

L'Europe suit une voie parallèle avec une autre mécanique. Les États membres ont adopté, via le groupe de coopération NIS, une feuille de route coordonnée de mise en œuvre : transition engagée et pilotes en cours d'ici fin 2026, cas d'usage à haut risque et infrastructures critiques d'ici 2030, achèvement dans la mesure du possible d'ici 2035. C'est un instrument de coordination plutôt qu'un règlement, mais c'est le texte au regard duquel s'écrivent les feuilles de route nationales : si vous opérez dans l'UE, c'est le document qu'a lu votre régulateur sectoriel.^[euroadmap]

Pour le marché francophone, une précision utile : en pratique, les auditeurs se réfèrent aux positions de l'ANSSI plutôt qu'aux documents du NIST, même si les deux convergent vers les mêmes algorithmes hybrides. Si vous documentez pour un audit, consultez directement la référence nationale en vigueur au lieu de la déduire de synthèses internationales — et anticipez que le firmware constructeur est la contrainte bloquante dans chacun de ces calendriers. Si un équipement suit un cycle de remplacement de cinq ans, l'achat de cette année est une décision post-quantique, que quelqu'un le formule ou non dans le dossier d'achat.

Un plan à 90 jours

Si vous voulez tout cela sur une page, la voici. La prémisse : l'échange de clés est un problème résolu que vous ne faites que déployer, et tout le reste est de la préparation.

Quatre-vingt-dix jours sont réalistes pour les trois premières phases dans la plupart des parcs, parce que les modifications sont petites et que le risque se concentre dans le relevé plutôt que dans l'édition. Ce qui prend plus longtemps est toujours identique : les appliances impossibles à mettre à jour et les liens dont personne ne connaissait l'existence. Les deux se découvrent en semaine un si l'inventaire est bien fait, ce qui est l'argument pour commencer par là.

Cinq erreurs à éviter

Motifs récurrents dans les migrations réelles, à peu près classés par temps perdu :

1. Auditer la capacité au lieu de la négociation. « Nos serveurs prennent en charge ML-KEM » n'est pas un constat. Un serveur peut le prendre en charge et conclure toute la journée des poignées de main classiques pour un client obsolète. Lisez l'algorithme négocié sur la connexion, pas la liste des algorithmes pris en charge.
2. Supprimer les algorithmes classiques. Les hybrides existent précisément pour vous éviter de choisir. Groupe post-quantique devant, X25519 derrière : vous gagnez la protection sans incident de disponibilité.
3. Courir après les certificats. Le temps passé à tenter de déployer des certificats ML-DSA en 2026 n'est pas passé sur l'échange réellement moissonné. Automatisez plutôt l'émission ; c'est ce travail qui paiera plus tard.
4. S'arrêter à la bordure. La poignée de main du CDN est post-quantique et le lien vers l'origine ne l'est pas. C'est de loin la lacune la plus fréquente, parce que le test externe passe et que le segment interne n'a aucun utilisateur pour se plaindre.
5. Traiter cela comme une opération ponctuelle. Une image de base reconstruite, un paquet figé, une configuration rétrogradée, et un hôte conforme en mars négocie en classique en septembre. Mettez le balayage sur une minuterie et alertez quand le compteur remonte.

La version courte

L'échange de clés post-quantique n'est pas un projet d'avenir. C'est une valeur par défaut dont vous avez probablement déjà hérité, et tout le travail consiste à retrouver les connexions qui l'ont manquée. Passez à OpenSSH 10.x et OpenSSL 3.5+, placez le groupe hybride en tête dans les deux, balayez la flotte pour ce qui est réellement négocié, et consignez les exceptions avec des dates. Pour la plupart des équipes c'est une semaine de travail, et cela ferme la seule attaque de ce domaine qui soit en cours aujourd'hui.

Puis arrêtez-vous. Ne migrez pas les certificats, n'achetez pas de plateforme d'agilité cryptographique et n'écrivez pas « quantique » dans un document de stratégie. Rendez l'émission de certificats automatique et courte, maintenez l'inventaire à jour, et attendez l'écosystème — car lorsque les signatures post-quantiques deviendront déployables, les organisations qui s'en sortiront bien ne seront pas celles qui auront commencé le plus tôt. Ce seront celles qui savent déjà remplacer un certificat sans fenêtre de changement.

Questions fréquentes

Dois-je faire quelque chose si je suis déjà sur OpenSSH 10 ?

Vérifier, puis probablement non. Le défaut est mlkem768x25519-sha256, mais une base de durcissement, un modèle dérivé de CIS ou un module de gestion de configuration peut avoir écrit sa propre ligne KexAlgorithms, antérieure à ML-KEM, qui l'exclut silencieusement. Lancez ssh -v hôte exit 2>&1 | grep 'kex: algorithm' contre un hôte réel et lisez le résultat négocié. Pour les sessions entrantes, c'est le côté serveur qui compte.

Activer l'échange post-quantique casse-t-il les anciens clients ?

Pas si vous le configurez comme une préférence et non comme une restriction. KexAlgorithms côté SSH et la liste des groupes côté TLS sont des préférences ordonnées : mettez l'hybride devant et gardez curve25519-sha256 ou X25519 derrière, et les pairs modernes obtiennent l'échange post-quantique tandis que les anciens retombent sur le classique. La casse survient quand vous retirez complètement les entrées classiques — choix défendable pour une flotte fermée que vous maîtrisez entièrement, mauvais pour tout ce qui est public.

sntrup761x25519-sha512 suffit-il, ou faut-il passer à ML-KEM ?

Il est réellement résistant au quantique et stoppe dès aujourd'hui l'attaque par moisson, qui est la propriété dont vous avez besoin. Sa faiblesse relève de la normalisation, pas de la cryptographie : NTRU Prime n'a pas été retenu par le NIST, il ne satisfera donc pas un régime de conformité écrit autour de FIPS 203, et le support d'implémentation à long terme est moins assuré. Si vous êtes sur OpenSSH 9.0–9.8 sans pouvoir migrer ce trimestre, vous êtes protégé. Planifiez tout de même le passage en 9.9+.

Pourquoi ne puis-je pas déployer dès maintenant des certificats post-quantiques ?

Parce qu'un certificat ne sert que si la partie qui le valide fait déjà confiance à la racine signataire, et qu'aucune racine post-quantique ne figure dans les magasins de confiance des navigateurs. Vous pouvez générer des clés ML-DSA avec OpenSSL 3.5 et monter une autorité interne avec elles, ce qui est une expérimentation raisonnable pour un système fermé. Pour tout ce qu'un navigateur touche, la chaîne ne validera pas. C'est un problème de séquencement de l'écosystème, pas de configuration, et il se résoudra en années.

Comment vérifier ce que mon endpoint TLS négocie réellement ?

openssl s_client -connect hôte:443 -servername hôte -groups X25519MLKEM768 -tls1_3 </dev/null 2>/dev/null | grep 'Negotiated TLS1.3 group'. Il vous faut un client OpenSSL 3.5+ pour le test lui-même : tester avec un client plus ancien produit un faux négatif, puisque votre client n'a jamais proposé le groupe. Lancez toujours aussi le test de contrôle avec -groups X25519, pour confirmer que vous avez durci l'endpoint et non cassé.

Faut-il s'inquiéter pour AES et SHA-256 ?

Non. L'algorithme de Grover offre une accélération quadratique contre les primitives symétriques, ce qui divise en pratique la longueur de clé par deux : AES-256 conserve une marge de sécurité de 128 bits, et SHA-256 reste adéquat. AES-128 fait davantage débat mais n'est pas la préoccupation pratique. Les algorithmes asymétriques — RSA, ECDH, ECDSA — sont ceux que l'algorithme de Shor casse purement et simplement, et ils constituent tout le sujet de cet article.

Et les VPN, bases de données et files de messages ?

Même règle, exécution plus difficile. WireGuard n'a pas d'échange de clés post-quantique dans son protocole de base et s'appuie sur son mécanisme de clé pré-partagée pour un montage hybride. La prise en charge d'IPsec dépend entièrement du firmware de votre constructeur. Le TLS des bases de données et des brokers suit en général la pile TLS du runtime plutôt que l'OpenSSL système : vérifiez donc chacun individuellement au lieu de supposer qu'un réglage global les a atteints. Ces liens sont aussi les cibles de plus grande valeur, puisque la charge utile est exactement la donnée confidentielle durable que l'attaque par moisson cherche à collecter.

Est-ce du théâtre de conformité ou une menace réelle ?

La menace est réelle mais décalée dans le temps, ce qui la rend facile à mal évaluer dans les deux sens. Personne ne déchiffre votre trafic aujourd'hui. La question est de savoir si le trafic capturé aujourd'hui sera encore sensible au milieu des années 2030 et, pour des dossiers médicaux, des données financières, du matériel juridique, des communications gouvernementales et des identifiants durables, la réponse est clairement oui. La particularité de ce risque est que l'atténuation est presque gratuite — un saut de version et une ligne de configuration — de sorte que le calcul coût-bénéfice ne vous oblige à croire à aucune date d'arrivée précise.

Tout ceci suppose que le système de base ne bouge pas, ce qui est faux : la mise à niveau d’Ubuntu 24.04 vers 26.04 sur serveur détaille la montée de version qui remplace six de ces valeurs par défaut sous vos pieds.

Sources

Toutes les sources ci-dessous ont été lues lors de la rédaction. Les notes de version des projets et les documents de normalisation sont cités de préférence aux couvertures secondaires, et lorsqu'un document est un projet et non une norme finale, il est décrit comme tel.

1. OpenSSH — Post-Quantum Cryptography (project page, FAQ and warning text)
2. OpenSSH 9.9 release notes (19 September 2024) — ML-KEM hybrid added; sntrup761x25519-sha512 gains its IANA name
3. OpenSSH 10.0 release notes (9 April 2025) — mlkem768x25519-sha256 becomes the default key agreement
4. OpenSSH 10.1 release notes (6 October 2025) — warning on non-post-quantum key agreement, WarnWeakCrypto
5. OpenSSH 8.5 release notes (3 March 2021) — sntrup761x25519-sha512@openssh.com replaces the older NTRU Prime hybrid, disabled by default
6. OpenSSH 10.3 release notes (2 April 2026)
7. OpenSSH 10.4 release notes (6 July 2026) — experimental mldsa44-ed25519 composite post-quantum signature scheme, not enabled by default
8. OpenSSH 10.5 release notes (11 August 2026) — current release at the time of writing
9. OpenSSH — full release notes index
10. ssh_config(5) — KexAlgorithms, WarnWeakCrypto, Match
11. sshd_config(5) — KexAlgorithms, HostKeyAlgorithms, Include
12. IETF draft-ietf-sshm-mlkem-hybrid-kex — hybrid ML-KEM key exchange for SSH
13. IETF draft-ietf-sshm-ntruprime-ssh — sntrup761x25519-sha512 for SSH (successor to the expired draft-josefsson document)
14. IETF draft-miller-sshm-mldsa44-ed25519-composite-sigs — the composite signature scheme OpenSSH 10.4 implements
15. OpenSSL 3.5 series release notes — PQC support and hybrid groups preferred by default (3.5.0, 8 April 2025)
16. OpenSSL documentation — SSL_CTX_set1_groups_list(3), the TLS supported-groups list
17. OpenSSL documentation — SSL_CONF_cmd(3), the Groups command Apache passes through
18. nginx documentation — ssl_ecdh_curve in ngx_http_ssl_module
19. HAProxy configuration manual — ssl-default-bind-curves
20. IETF draft-ietf-tls-ecdhe-mlkem — hybrid ECDHE + ML-KEM groups for TLS 1.3
21. RFC 8446 — The Transport Layer Security (TLS) Protocol Version 1.3
22. NIST FIPS 203 — Module-Lattice-Based Key-Encapsulation Mechanism Standard (ML-KEM)
23. NIST FIPS 204 — Module-Lattice-Based Digital Signature Standard (ML-DSA)
24. NIST FIPS 205 — Stateless Hash-Based Digital Signature Standard (SLH-DSA)
25. NIST IR 8547 (Initial Public Draft, 12 November 2024) — Transition to Post-Quantum Cryptography Standards
26. European Commission / NIS Cooperation Group — Coordinated Implementation Roadmap for the Transition to PQC
27. Cloudflare — State of the post-quantum Internet in 2025
28. Cloudflare Radar — post-quantum encryption adoption (live figures)