Préparer son infrastructure à la cryptographie post-quantique

En bref

#

• Le risque post-quantique n’est pas immédiat, mais le scénario Harvest Now, Decrypt Later est déjà réaliste.
• Les données à longue durée de vie (backups, secrets, archives) sont les premières concernées.
• La stratégie actuelle est l’hybridation : garder une protection classique tout en ajoutant une protection post-quantique.
• OpenSSH supporte déjà des mécanismes hybrides modernes (ML-KEM).
• Le vrai défi est opérationnel : compatibilité, MTU, performances et migration progressive.

Un backup de coffre-fort, une capture VPN, un dump de base de données, une archive Git privée : ce sont des données qui peuvent rester sensibles longtemps après leur création. C’est là que le sujet post-quantique devient concret pour l’infra.

Le problème n’est pas qu’un ordinateur quantique va casser vos accès demain matin. Le vrai sujet, c’est que certaines données capturées aujourd’hui peuvent garder de la valeur pendant dix ou vingt ans, surtout quand elles sont protégées par des mécanismes asymétriques classiques.

Mise à jour du 28 août 2026 : clarification de la négociation OpenSSH, du rôle de la rotation des clés et de l’impact réseau des handshakes. Une rotation classique ne protège pas rétroactivement un trafic déjà capturé.

Le risque Harvest Now, Decrypt Later

#

On entend souvent : “Un ordinateur quantique capable de briser le RSA, ça n’existe pas encore.” C’est vrai. Mais l’attaque “Harvest Now, Decrypt Later” (ou “Store Now, Decrypt Later”) est une menace réelle et actuelle.

Imaginez un scénario classique : un acteur malveillant (ou une agence de renseignement) intercepte et enregistre aujourd’hui tout le trafic chiffré de votre VPN, de vos sessions SSH, ou de vos accès cloud. Pour l’instant, ce flux de données n’est qu’un bruit inutile, un amas de bits illisibles. Mais si vos fichiers protégés (configurations de production, secrets industriels, données de santé, backups de coffre-forts) doivent rester confidentiels pendant 10 ou 20 ans, le danger est déjà là.

Si, dans dix ou quinze ans, le matériel quantique devient capable de casser RSA/ECC à grande échelle, ces archives de trafic “capturé” pourront être déchiffrées. Vos secrets de 2024 deviendront les vulnérabilités de 2040. Pour un administrateur qui gère des données de longue durée, la sécurité post-quantique n’est pas une option futuriste. C’est une question de gestion du risque, de confidentialité à long terme, et de préparation progressive face à des exigences réglementaires qui tendent à se durcir.

Le défi de la cryptographie post-quantique (PQC) n’est pas de comprendre les réseaux de modules ou le problème Learning With Errors (LWE). Le vrai défi, pour une équipe infra, est plus banal et plus important : intégrer de nouveaux algorithmes sans casser la compatibilité, sans dégrader les performances, et surtout sans provoquer des incidents de production.

Pourquoi l’hybridation est l’approche actuelle

#

Le remplacement brutal de l’ECC ou du RSA par des algorithmes post-quantiques serait une approche risquée. Les nouveaux algorithmes (comme ML-KEM, anciennement Kyber) sont récents. S’ils s’avéraient présenter une faille mathématique majeure dans deux ans, toute votre infrastructure serait vulnérable.

C’est pourquoi la communauté s’est accordée sur une approche pragmatique : l’hybridation. Elle ne rend pas une architecture magique, mais elle évite de remplacer brutalement une primitive éprouvée par une primitive plus récente.

L’idée est de combiner deux mécanismes de partage de clés dans un même “handshake” :

1. Un mécanisme classique (ex: X25519) : Il garantit que votre sécurité ne descend pas en dessous de ce que vous avez aujourd’hui. Si le nouvel algorithme échoue, le vieux protocole assure la protection.
2. Un mécanisme post-quantique (ex: ML-KEM) : Il apporte la barrière supplémentaire contre l’ordinateur quantique.

Exemple pratique avec OpenSSH

#

Si vous utilisez OpenSSH, ces mécanismes existent déjà dans les versions récentes. Depuis OpenSSH 9.0, des échanges de clés hybrides post-quantiques sont progressivement introduits et étendus.

Initialement, OpenSSH a introduit sntrup761x25519-sha512@openssh.com (Streamlined NTRU Prime + X25519). Depuis OpenSSH 9.9, mlkem768x25519-sha256 est également disponible, et OpenSSH 10.0 l’utilise par défaut pour l’échange de clés. Cet algorithme repose sur ML-KEM, standardisé par le NIST sous le nom FIPS 203.

Pour vérifier quels algorithmes hybrides sont disponibles sur votre système :

# Lister les KEX supportés, filtrer les implémentations post-quantiques
ssh -Q kex | grep -Ei "mlkem|sntrup"

Si mlkem768x25519-sha256 apparaît, vous pouvez forcer son utilisation pour tester :

# Tester une connexion avec l'algorithme hybride ML-KEM + X25519
ssh -o KexAlgorithms=mlkem768x25519-sha256 user@remote-host

En tant qu’admin, vérifiez quels algorithmes sont réellement négociés lors de vos sessions critiques. Ici, on parle bien du Key Exchange SSH, pas des clés d’authentification utilisateur comme RSA ou Ed25519. Si vous voyez toujours uniquement ecdh-sha2-nistp256 ou diffie-hellman-group14-sha1 dans vos traces de connexion, vous êtes en zone à moderniser.

Impact opérationnel : taille et compatibilité des handshakes

#

Le changement n’est pas gratuit. Les clés, signatures et messages post-quantiques sont généralement plus volumineux que leurs équivalents classiques. Il faut mesurer le coût en bande passante, en latence et en CPU, surtout sur les équipements contraints ou les connexions à forte latence.

Pour SSH sur TCP, une augmentation de la taille du KEX ne provoque pas automatiquement une fragmentation IP : TCP segmente normalement le flux selon la MSS négociée. Les problèmes de Path MTU Discovery restent possibles sur un réseau déjà mal configuré, mais baisser arbitrairement la MTU n’est pas une mitigation post-quantique.

Les points à tester sont plus larges :

• compatibilité des clients et serveurs avec les mêmes algorithmes hybrides ;
• limites de taille dans les bibliothèques, proxies et équipements intermédiaires ;
• temps de négociation sur les liens lents ;
• consommation CPU lors d’un grand nombre de connexions simultanées ;
• comportement des protocoles sur UDP, pour lesquels les contraintes de datagramme et d’amplification sont différentes de SSH.

Avant un déploiement large, mesurer le taux d’échec, la durée du handshake et la charge sur un échantillon représentatif. Ne modifier la MTU qu’après avoir diagnostiqué un problème réseau réel.

Un point à ne pas mélanger avec RSA/ECC : le chiffrement symétrique ne casse pas de la même manière. Shor vise surtout les problèmes mathématiques utilisés par RSA et les courbes elliptiques. Grover peut réduire théoriquement la marge de sécurité d’un chiffrement symétrique, mais AES-256 garde une marge confortable. En pratique, le risque prioritaire reste souvent l’asymétrique qui protège les clés, les sessions ou les archives.

Audit post-quantique de l’infrastructure

#

Comment savoir si votre infrastructure est prête ? Voici un tableau d’audit pour vos services les plus critiques. L’idée est de hiérarchiser vos actions par niveau de risque.

La lecture utile est simple : P0/P1 pour ce qui protège des données longues durées ou des accès d’administration, P2/P3 pour ce qui dépend surtout du support des outils et des bibliothèques.

Automatiser l’audit

#

Ne faites pas cet audit à la main pour chaque serveur. Utilisez les outils que vous utilisez déjà pour vos scans de vulnérabilités.

Scanner vos serveurs Web (Nginx/Caddy)

#

Vous pouvez utiliser nmap et openssl pour vérifier ce que votre proxy TLS expose réellement aujourd’hui.

# Lister les versions TLS et suites de chiffrement visibles depuis l'extérieur
nmap --script ssl-enum-ciphers -p 443 votre-service.com

# Vérifier le certificat, la version TLS 1.3 et les paramètres négociés
openssl s_client -connect votre-service.com:443 -servername votre-service.com -tls1_3 </dev/null

Regardez au minimum :

• la version TLS négociée ;
• l’algorithme de signature du certificat ;
• les suites de chiffrement encore acceptées ;
• la présence de TLS 1.0/1.1 ou de suites faibles.

Aujourd’hui, l’objectif réaliste n’est pas de “forcer du post-quantique” sur Nginx en production. Il est d’abord de supprimer l’ancien, de garder TLS 1.3 propre, puis de suivre le support des groupes hybrides dans OpenSSL, BoringSSL, nginx, Caddy et vos CDN.

Sur un parc réel, cette étape vaut déjà le temps passé. Un proxy encore ouvert à TLS 1.0 ou à des suites faibles est un problème plus immédiat qu’un manque de ML-KEM.

Scanner vos accès SSH

#

Utilisez ssh-audit, ssh -Q kex ou une inspection manuelle de la configuration pour vérifier la présence d’algorithmes de Key Exchange modernes et hybrides.

Commandes d’audit rapide

#

Quelques commandes concrètes pour prendre le pouls de votre infrastructure :

# Vérifier la version d'OpenSSH installée
ssh -V

# Voir les algorithmes KEX réellement négociés lors d'une connexion
ssh -vv user@host 2>&1 | rg 'kex: algorithm:'

ssh -V indique la version du client. La trace ssh -vv affiche l’algorithme de Key Exchange effectivement choisi. OpenSSH 9.0 et versions ultérieures proposent sntrup761x25519-sha512@openssh.com. mlkem768x25519-sha256 apparaît à partir d’OpenSSH 9.9 et devient le choix par défaut dans OpenSSH 10.0.

Ce contrôle couvre la confidentialité de la session face au scénario de collecte puis déchiffrement. Il ne rend pas les signatures RSA ou Ed25519 post-quantiques.

Forcer l’hybridation côté serveur ou client

#

Pour désactiver explicitement les KEX legacy et forcer l’hybridation, vous pouvez restreindre la liste dans sshd_config (serveur) ou ssh_config (client) :

# sshd_config : autoriser uniquement les algorithmes hybrides
KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512@openssh.com

# ssh_config : même politique côté client
KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512@openssh.com

Avant toute modification, vérifier les algorithmes supportés avec ssh -Q kex et la configuration effective du serveur avec sshd -T. Après modification, valider la syntaxe avec sudo sshd -t, puis recharger le service ssh sur Debian et Ubuntu ou sshd sur les distributions qui utilisent ce nom. Garder une session parallèle ouverte pour pouvoir revenir en arrière.

C’est le genre de changement à tester sur une machine de bord ou un serveur non critique avant de toucher au bastion principal. La crypto post-quantique ne sert à rien si la première conséquence est de perdre l’accès d’administration.

Rotation de clés et durée de vie dans un contexte post-quantique

#

Une rotation régulière reste utile pour limiter l’impact d’une clé volée et maintenir l’agilité cryptographique. Elle ne protège toutefois pas un trafic ou une archive déjà capturés sous RSA ou ECC : si l’algorithme devient cassable, la rotation ultérieure de la clé n’annule pas cette exposition.

Pour les données qui doivent rester confidentielles longtemps, la réponse est de migrer le mécanisme de protection, puis de ré-encrypter les archives lorsque le format et les outils le permettent. La durée de vie des certificats répond à d’autres objectifs opérationnels et ne constitue pas, seule, une défense contre Harvest Now, Decrypt Later.

Erreurs à éviter

#

La migration post-quantique doit rester progressive. Quelques erreurs classiques peuvent créer plus d’incidents qu’elles n’en résolvent :

• Forcer ML-KEM partout sans vérifier la version des clients, des serveurs et des middleboxes.
• Supprimer tous les algorithmes de repli SSH avant d’avoir testé une session parallèle.
• Confondre chiffrement symétrique et asymétrique : AES-256 n’est pas cassé par Shor comme RSA ou ECC, même si Grover réduit théoriquement sa marge.
• Lancer une migration globale sans inventaire des certificats, clés SSH, archives, VPN et dépendances TLS.
• Oublier les sauvegardes anciennes : ce sont souvent elles qui gardent le plus longtemps des secrets protégés par de vieilles clés.

Conclusion

#

La transition post-quantique ne demande pas de devenir un expert en mathématiques. Elle demande surtout de savoir où la cryptographie asymétrique est utilisée, combien de temps les données doivent rester confidentielles, et quels composants peuvent être mis à jour sans casser la production.

Commencez par les sauvegardes, les accès d’administration, les certificats et les tunnels. Le reste peut suivre progressivement, au rythme du support réel dans les clients, les bibliothèques TLS et les équipements réseau. C’est moins spectaculaire qu’une migration globale, mais beaucoup plus proche de la manière dont une infra tient réellement dans le temps.

Sources

#

Sources vérifiées le 28 août 2026 :

• NIST Post-Quantum Cryptography Standardization
• NIST FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard
• OpenSSH Release Notes (9.0 / 10.0)
• OpenSSH: Post-Quantum Cryptography
• CISA: Quantum-Readiness, Migration to Post-Quantum Cryptography
• IETF draft on hybrid ML-KEM key exchange for SSH