PQC StatusHarvest now, decrypt later (HNDL), ou « collecter maintenant, déchiffrer plus tard », est une attaque patiente : capturer aujourd'hui du trafic chiffré, le stocker, puis le déchiffrer des années plus tard, lorsque l'accord de clés qui le protégeait ne tient plus. Elle ne nécessite aujourd'hui aucun ordinateur quantique, seulement une capacité de capture et de l'espace disque. La question utile pour une équipe sécurité n'est donc pas de savoir quand existera un ordinateur quantique cryptographiquement pertinent, mais combien de temps chaque flux de données doit rester confidentiel, et quels systèmes transportent les flux dont la durée de vie est la plus longue.
Le modèle de menace, formulé précisément
Distinguez chez l'adversaire deux capacités séparées dans le temps.
- Aujourd'hui : la collecte. Capture passive sur un tap réseau, chez un fournisseur de transit en amont, sur un point de peering, via un répartiteur de charge ou un équipement intermédiaire compromis, ou par le vol d'une archive de sessions déjà enregistrées. Le texte chiffré est stocké, pas lu.
- Plus tard : le calcul. La récupération d'une clé privée à partir d'une clé publique. L'algorithme de Shor, sur un ordinateur quantique suffisamment puissant, casse RSA, ECDH, Diffie-Hellman sur corps finis, ECDSA, EdDSA et DSA, quelle que soit la taille de clé. Passer de RSA-2048 à RSA-4096, ou d'une courbe elliptique à une courbe plus grande, n'y change rien.
La cryptographie symétrique se comporte différemment. AES, SHA-2 et SHA-3 ne sont pas cassés par Shor. L'algorithme de Grover offre un avantage plus modeste, quadratique, contre les clés symétriques, et c'est la raison pour laquelle AES-256 est préféré lorsque les données doivent rester confidentielles longtemps. Une session enregistrée n'est pas menacée parce qu'AES-GCM a protégé la charge utile. Elle est menacée par la manière dont la clé AES a été convenue.
La confidentialité persistante ne résout pas ce problème
TLS 1.3 utilise toujours un accord de clés éphémère, en pratique ECDH sur X25519 ou sur une courbe NIST. La confidentialité persistante (forward secrecy) signifie que le vol, demain, de la clé privée de long terme du serveur ne révèle pas les sessions d'hier, car le secret de session provient de parts éphémères. Mais ces parts publiques éphémères circulent en clair dans la poignée de main. Une poignée de main enregistrée contient donc tout ce qui est nécessaire pour reconstruire le secret de session, pour quiconque est capable de résoudre cette unique instance d'accord de clés. La confidentialité persistante protège contre le vol de clé. Elle ne protège pas contre une cryptanalyse ultérieure de l'accord de clés lui-même. Tout le problème HNDL réside dans cet écart.
Pourquoi l'échange de clés migre en premier et les signatures ensuite
Une signature est vérifiée au moment de la connexion. Si un algorithme de signature devient falsifiable dans dix ans, cela ne permet à personne de lire une session enregistrée aujourd'hui : les clés de session n'ont jamais été dérivées du certificat. Ce qu'une signature cassée permet, c'est l'usurpation d'identité à l'avenir, ainsi que des artefacts falsifiés qui restent considérés comme fiables longtemps.
D'où l'ordre que suivent toutes les feuilles de route officielles. L'accord de clés hybride post-quantique vient en premier, fondé sur ML-KEM, le mécanisme d'encapsulation de clés (KEM) normalisé par le NIST sous FIPS 203 le 13 août 2024 (FIPS 203). Les signatures post-quantiques telles que ML-DSA (FIPS 204) suivent, pour les chaînes de certificats. Les groupes TLS hybrides X25519MLKEM768, SecP256r1MLKEM768 et SecP384r1MLKEM1024 figurent dans le registre IANA des paramètres TLS, et la RFC 10024 (août 2026) spécifie l'accord de clés hybride post-quantique/traditionnel (PQ/T) pour TLS 1.3. Les versions actuelles de Chrome, Edge et Firefox proposent X25519MLKEM768 par défaut : pour de nombreux points de terminaison publics, il s'agit donc d'un changement de configuration plutôt que d'un projet.
Ensuite ne veut pas dire jamais, et deux catégories de signatures méritent malgré tout une attention précoce :
- Les signatures dont la vérification doit rester fiable après un long délai : signature des mises à jour de firmware et de logiciels, racines de confiance du démarrage sécurisé, signatures d'archives et de documents, horodatage.
- Les certificats et identifiants à longue durée de validité, dont la réémission est coûteuse ou physiquement malaisée : produits embarqués, équipements industriels, cartes à puce.
La CNSA 2.0 de la NSA, qui s'applique aux National Security Systems américains, reflète cette distinction. Elle prévoit l'usage exclusif de ML-KEM-1024 et ML-DSA-87 d'ici fin 2030 pour la signature des logiciels et firmwares et pour les équipements réseau traditionnels, et d'ici fin 2033 pour les navigateurs et serveurs web, les services cloud et les systèmes d'exploitation.
Quelles données ont une durée de confidentialité suffisamment longue pour compter
La durée de confidentialité est la période pendant laquelle une divulgation causerait encore un préjudice. C'est une propriété métier et juridique de la donnée, non une propriété du protocole, et c'est le seul paramètre de la priorisation HNDL que vous maîtrisez entièrement. Des ordres de grandeur suffisent pour commencer.
| Catégorie de données | Pourquoi la durée est longue ou courte | Ordre de grandeur |
|---|---|---|
| Données de santé, génomiques et biométriques | Identifient une personne à vie et ne peuvent pas être réémises | Décennies |
| Informations gouvernementales, de défense et diplomatiques | Les durées de classification sont fixées par des règles, non par la technologie | Décennies |
| Secrets d'affaires, formules, conceptions, code source | La valeur suit la durée de vie de la gamme de produits | Années à décennies |
| Secret professionnel des avocats, dossiers contentieux, documents de conseil d'administration et de transactions | Restent sensibles longtemps après la clôture de l'opération ou de l'affaire | Années à décennies |
| Identifiants et éléments de clés en transit | Héritent de la durée de vie de ce qu'ils permettent d'ouvrir | Années |
| Données personnelles conservées au titre d'obligations de conservation | Le préjudice persiste tant que les enregistrements existent | Années |
| Prix en temps réel, jetons de session courts, télémétrie opérationnelle | La valeur décroît rapidement après la capture | Jours à mois |
Deux corrections s'imposent dans la plupart des inventaires. Premièrement, des données à courte durée de vie circulant dans un tunnel de longue durée héritent du tunnel : une liaison site à site qui transporte aussi la réplication d'une base de données a la durée de vie de cette base. Deuxièmement, les secrets en transit ont la durée de vie des systèmes qu'ils ouvrent, et non celle de la requête qui les a transportés.
Comment classer les systèmes selon la durée de vie des données
Pour chaque système, notez deux chiffres. X est la durée de confidentialité des données qu'il transporte. Y est la durée qu'exigerait de manière réaliste la migration de ce système, compatibilité des clients, firmware des appliances et fenêtres de changement compris. Il existe une troisième grandeur, le moment où le calcul en question deviendra réalisable, et personne ne peut lui attribuer une date crédible : considérez-la donc comme inconnue. Reste la règle praticable : réduire Y, et l'investir d'abord là où X est le plus grand, car le trafic déjà enregistré ne peut pas être rappelé.
| Niveau | Critères | Action |
|---|---|---|
| Agir maintenant | Durée de confidentialité supérieure à une dizaine d'années, ou le flux transporte des clés et des identifiants, ou il traverse des réseaux que vous ne contrôlez pas | Activer l'accord de clés hybride ML-KEM sur le transport, privilégier TLS 1.3 exclusivement, privilégier AES-256 lorsque la pile le permet |
| Planifier ensuite | Durée de quelques années, trafic interne qui transite néanmoins par des réseaux de fournisseurs ou de partenaires | Rattacher le changement à la prochaine mise à niveau de plateforme ou d'appliance, activer les groupes hybrides à mesure que les clients les prennent en charge |
| Suivre la plateforme | Durée inférieure à un an, aucun secret ni identifiant de longue durée | Hériter des paramètres par défaut du système d'exploitation, de la bibliothèque et du navigateur |
Ce classement doit s'appuyer sur un inventaire. L'exigence 12.3.3 de PCI DSS v4.0.1, obligatoire depuis le 31 mars 2025, demande déjà un inventaire documenté des suites de chiffrement et protocoles utilisés, revu au moins tous les 12 mois, avec un suivi de leur viabilité dans la durée. Les normes techniques de réglementation de DORA, le Commission Delegated Regulation (EU) 2024/1774, exigent à l'article 6 une politique de chiffrement comprenant des dispositions pour mettre à jour ou changer la technologie cryptographique en fonction des évolutions de la cryptanalyse, et à l'article 7 une gestion des clés sur l'ensemble de leur cycle de vie ainsi qu'un registre des certificats pour les actifs soutenant des fonctions critiques ou importantes. L'article 21(2)(h) de NIS2 exige des politiques relatives à l'utilisation de la cryptographie. Aucun de ces textes ne mentionne une colonne de durée de vie des données : ajouter cette colonne à l'inventaire que vous tenez déjà relève de notre interprétation d'un moyen pratique de justifier la priorisation, et non d'une exigence littérale. Cet article a une vocation informative et ne constitue pas un avis juridique.
Ce que les calendriers officiels ont en commun
Les calendriers publiés diffèrent par leur statut et leur formulation, et les nuances comptent. La feuille de route coordonnée de l'UE (EU Coordinated Implementation Roadmap) v1.1 (publiée le 23 juin 2025) est une orientation coordonnée à l'intention des États membres, et non un règlement contraignant pour les entreprises : premières étapes, dont un inventaire cryptographique et des feuilles de route nationales, d'ici fin 2026, cas d'usage à haut risque migrés d'ici fin 2030, risque moyen d'ici fin 2035. Les recommandations du NCSC britannique fixent la découverte et un plan initial d'ici 2028, les migrations les plus prioritaires d'ici 2031 et l'achèvement d'ici 2035. Le BSI TR-02102-1 (version 2026-01) est une directive technique : il recommande l'accord de clés hybride et ne considère l'accord de clés classique utilisé seul acceptable que jusqu'à fin 2031, ou fin 2030 pour les besoins de protection très élevés. NIST IR 8547 reste un projet initial soumis à consultation publique ; il propose de déprécier les algorithmes vulnérables au quantique offrant une sécurité de 112 bits après 2030 et d'interdire les algorithmes à clé publique vulnérables au quantique après 2035. L'ANSSI rend l'hybridation obligatoire dans son périmètre réglementé et indique que ses recommandations post-quantiques ne constituent pas encore des obligations réglementaires ailleurs. Notre page sur les échéances de la migration post-quantique rassemble le détail daté en un seul endroit.
La structure commune est plus instructive que n'importe quelle date isolée : un groupe le plus prioritaire autour de 2030 à 2031, le reste d'ici 2035, et un critère de sélection du premier groupe qui est essentiellement la longue durée de vie des données. C'est l'argument HNDL, inscrit dans les politiques publiques.
Vérifiez ce que vos poignées de main négocient réellement
Mesurez avant de planifier. Avec OpenSSL 3.5 ou ultérieur, version minimale fournissant les groupes TLS ML-KEM, demandez explicitement un groupe hybride et relisez ce qui a été négocié :
openssl s_client -connect example.com:443 -tls1_3 \
-groups X25519MLKEM768 </dev/null 2>&1 | grep -i groupPour les accès d'administration, vérifiez l'accord de clés d'une session SSH. OpenSSH 9.9 (19 septembre 2024) a ajouté mlkem768x25519-sha256, OpenSSH 10.0 (9 avril 2025) en a fait l'accord de clés par défaut, et OpenSSH 10.1 (6 octobre 2025) avertit lorsqu'une connexion négocie un accord de clés non post-quantique, via WarnWeakCrypto, activé par défaut. Les notes de version sont publiées sur openssh.com.
ssh -v -o KexAlgorithms=mlkem768x25519-sha256 user@host 2>&1 | grep -i kexPlacez le groupe hybride en premier et conservez derrière lui un repli classique, par exemple X25519MLKEM768 puis X25519, afin que les clients plus anciens puissent toujours se connecter. Testez en préproduction avant la production, et surveillez la taille des poignées de main sur les liaisons contraintes et sur les appliances qui inspectent le ClientHello.
Votre prochaine étape
Commencez par les deux éléments qui rendent le reste mécanique : une colonne de durée de vie des données ajoutée à votre inventaire cryptographique, et une mesure de ce que vos points de terminaison externes négocient aujourd'hui. Pour le second, vous pouvez analyser votre domaine avec PQC Status gratuitement : l'analyse indique les groupes hybrides ML-KEM proposés, les versions de TLS et les suites de chiffrement, ainsi que la chaîne de certificats. Une analyse ne décrit que la configuration TLS visible de l'extérieur : considérez-la comme un élément de preuve pour votre inventaire, et non comme une certification ou une attestation de conformité. Prenez ensuite les systèmes de votre niveau « agir maintenant » et dotez-les d'un accord de clés hybride, dans cet ordre.