Récolter maintenant, déchiffrer plus tard

Éditorial

La menace de collecte rétroactive ne concerne pas « les données », mais celles dont la sensibilité dure plus longtemps que l'horizon crédible d'un ordinateur quantique et qui passent par un échange de clés à clé publique. Tout le reste relève de la panique commerciale ou du déni confortable, et une priorisation honnête commence par le tri.

Mis à jour le 25 septembre 2026~27 min de lecture13 sections

papy cyber

→ Lire l’explication complète de la marmotte

Un disque dur et beaucoup de patience

Il existe des menaces spectaculaires, qui demandent du génie, de l’audace et un sweat à capuche. Celle-ci n’en fait pas partie. Elle demande un point de capture sur le réseau, des disques, et une vertu qu’on croyait réservée aux pêcheurs à la ligne et aux notaires : la patience.

Le mécanisme tient en deux phrases. Un attaquant enregistre aujourd’hui un échange chiffré qu’il ne sait pas lire. Il le conserve jusqu’au jour où un ordinateur quantique suffisamment puissant lui permettra de retrouver la clé de session, par exemple en résolvant le Diffie-Hellman sur courbe elliptique qui l’a établie. Ce jour-là, l’échange de 2026 devient lisible, et tout ce qu’il contenait avec.

La menace a trois propriétés qui la rendent à la fois sérieuse et exploitable par les marchands d’angoisse. Elle est déjà active, puisque la collecte a lieu maintenant, quelle que soit la date de la machine. Elle est invisible, puisqu’une écoute passive ne laisse aucune trace chez la victime. Et elle est irréversible, puisqu’on ne rechiffre pas un paquet qui est déjà sur le disque de quelqu’un d’autre.

De là, deux discours symétriques. Le premier dit : tout ce que vous chiffrez aujourd’hui sera lu demain, migrez tout, maintenant, et d’ailleurs voici notre offre. Le second dit : l’ordinateur quantique utile est une chimère qui recule chaque année d’un an, on verra bien. Les deux ont en commun de dispenser de réfléchir, ce qui explique leur succès.

Cet éditorial part d’une question plus étroite : quelles données sont réellement concernées, lesquelles ne le seront jamais, et comment en déduire un ordre de migration qui ne soit ni une capitulation devant la peur, ni une sieste déguisée en prudence. Le chapitre sur la préparation de la migration post-quantique pose le cadre général ; on s’occupe ici du tri.

L’inégalité qui ne dit pas ce qu’on croit

Le raisonnement de référence est connu sous le nom d’inégalité de Mosca, du nom du chercheur qui l’a popularisée. Soit x la durée pendant laquelle une donnée doit rester confidentielle, y le temps nécessaire pour migrer les systèmes qui la protègent, et z le temps avant qu’un ordinateur quantique capable de casser la cryptographie en place existe. Si x + y > z, on a un problème.

C’est une inégalité remarquable, parce qu’elle est à la fois juste et presque inutilisable telle quelle. Elle contient trois variables : l’une est inconnue (z), l’autre est systématiquement sous-estimée (y), et la troisième est la seule qu’on puisse réellement estimer, mais c’est celle que personne ne prend la peine d’estimer (x).

Ce que z n’est pas

Commençons par l’inconnue, pour s’en débarrasser. Personne ne sait quand, ni si, un ordinateur quantique cryptographiquement pertinent existera. Les estimations de ressources nécessaires pour casser RSA ou les courbes elliptiques ont baissé au fil des publications, à mesure que les algorithmes et les techniques de correction d’erreurs s’amélioraient ; les machines réelles ont progressé, mais restent loin de ces estimations. Entre ces deux courbes, il y a un intervalle qu’on remplit selon son tempérament, son employeur ou son produit.

La bonne manière de traiter z n’est pas de le deviner, mais de le traiter comme une distribution et de se demander à partir de quelle probabilité on juge le risque inacceptable pour une donnée donnée. Une probabilité faible d’une machine dans quinze ans est négligeable pour un catalogue de produits, et parfaitement inacceptable pour l’identité d’une source journalistique. Le même z donne deux décisions opposées. C’est normal : z décrit le monde, la décision dépend de ce qu’on a à perdre.

Ce que y coûte

La deuxième variable est celle qu’on sous-estime avec une constance admirable. Migrer la cryptographie d’une organisation, ce n’est pas changer un paramètre dans un fichier de configuration. C’est inventorier ce qui chiffre quoi, découvrir qu’une partie tourne sur des équipements qui ne se mettent plus à jour, négocier avec des fournisseurs, attendre des bibliothèques, tester des interopérabilités, et découvrir, au détour d’un protocole métier, qu’une taille de clé était codée en dur dans un format de fichier écrit il y a vingt ans par quelqu’un qui est depuis parti élever des chèvres.

L’histoire des migrations cryptographiques précédentes (retrait de MD5 et de SHA-1, abandon des anciennes versions de TLS) montre qu’elles se comptent en années, souvent en décennies pour la longue traîne. Rien n’indique que celle-ci ira plus vite ; tout indique qu’elle ira moins vite, puisqu’elle touche la cryptographie à clé publique, qui est partout et que personne n’a inventoriée. Le chapitre sur l’inventaire cryptographique décrit le travail ; il ne le rend pas plus court.

Ce que x devrait être

Reste la seule variable qui dépende de nous, et c’est là que le raisonnement devient intéressant, parce que x n’est pas une propriété du système, c’est une propriété de la donnée. Un même tunnel VPN transporte des requêtes DNS sans intérêt au bout de dix minutes, des courriels commerciaux sensibles quelques mois, et, peut-être, un dossier judiciaire sensible jusqu’à la mort de l’intéressé et au-delà. Appliquer l’inégalité au tunnel n’a aucun sens. Il faut l’appliquer à ce qui passe dedans.

C’est l’erreur la plus fréquente dans les analyses de risque post-quantique : raisonner par système, par protocole, par équipement, alors que la menace de collecte rétroactive porte sur le contenu. Le système n’est que le chemin. On le migrera en fonction de ce qu’il transporte de plus durable.

Ce que la menace touche réellement

Pour qu’une donnée soit concernée par la collecte rétroactive, il faut que plusieurs conditions soient réunies. Aucune n’est exotique, mais leur conjonction réduit considérablement le périmètre.

Première condition : la donnée a transité, ou est stockée, sous une protection qui repose in fine sur de la cryptographie à clé publique vulnérable à Shor. C’est le cas de l’immense majorité des échanges réseau chiffrés : TLS, SSH, la plupart des VPN, qui établissent leurs clés de session par un Diffie-Hellman sur courbe elliptique ou, plus anciennement, par un transport RSA. C’est aussi le cas du courrier chiffré de bout en bout avec OpenPGP ou S/MIME, où la clé de chaque message est chiffrée pour la clé publique du destinataire, et des archives dont la clé de chiffrement est protégée par une clé RSA ou une courbe.

Deuxième condition : l’attaquant a pu en obtenir une copie chiffrée. Pour le trafic réseau, cela suppose une position d’écoute sur le chemin, à un moment où l’échange passait. Pour les données stockées, cela suppose un accès au support ou à une sauvegarde.

Troisième condition : la donnée est encore sensible au moment où l’attaquant saura la lire. C’est la condition x > z − maintenant, qu’on a vue plus haut, et c’est celle qui élimine le plus de cas.

La confidentialité persistante ne sauve rien

Un point mérite d’être dit clairement, parce qu’il surprend encore. La confidentialité persistante (forward secrecy), qu’on obtient en utilisant des clés Diffie-Hellman éphémères jetées après chaque session, protège contre la compromission ultérieure de la clé longue durée du serveur. Elle ne protège pas contre un attaquant capable de résoudre le Diffie-Hellman lui-même à partir des valeurs publiques échangées, qui sont précisément dans la capture. Le chapitre sur TLS explique ce qu’elle garantit ; contre Shor, elle ne garantit rien.

Cela a une conséquence un peu cruelle : les organisations qui ont bien travaillé, qui ont généralisé les échanges éphémères et banni le transport de clé RSA, sont exactement aussi exposées à la collecte rétroactive que les autres. Le monde est ainsi fait que la vertu n’est récompensée qu’à la condition que l’adversaire reste dans le modèle de menace pour lequel on a été vertueux.

Le courrier chiffré, cet angle mort

S’il fallait désigner une catégorie sous-estimée, ce serait le courrier électronique chiffré de bout en bout. Dans le cas du trafic réseau, l’attaquant doit être sur le chemin au bon moment. Dans le cas du courrier chiffré, le message chiffré est conservé par construction : dans la boîte du destinataire, dans celle de l’expéditeur, sur des serveurs intermédiaires, dans des sauvegardes, parfois pendant des années. La collecte n’a pas besoin d’une écoute ; elle a besoin d’une fuite de boîte aux lettres, d’une saisie ou d’une sauvegarde mal protégée. Et chaque message porte, dans son en-tête, la clé de session chiffrée pour une clé publique RSA ou sur courbe elliptique.

Autrement dit, le courrier chiffré avec des algorithmes classiques est un stock de données déjà récoltées, qui attend seulement la machine. Le chapitre sur les messageries et le courrier sécurisé en décrit la mécanique. Ceux qui ont pris la peine de chiffrer leurs courriels les plus sensibles ont, par définition, désigné eux-mêmes ceux qui valaient la peine d’être gardés. C’est une forme d’étiquetage à l’usage des archivistes du futur, et il est fait gratuitement.

Ce qu’elle ne touchera jamais

L’inventaire de ce qui n’est pas concerné est plus reposant, et au moins aussi utile, parce qu’il permet de retirer de la liste de priorités des pans entiers que la peur y avait mis.

Les données dont la sensibilité expire avant la machine. Un jeton de session valide quinze minutes, un code à usage unique, une clé d’API qu’on fait tourner tous les mois, un prix de gros communiqué la veille d’une annonce publique : tout cela sera lisible en 2040 et n’intéressera personne. On peut déchiffrer un secret périmé avec la plus grande facilité ; on ne peut plus rien en faire, ce qui est une définition acceptable de la sécurité et, passé un certain âge, de la mémoire.

Les données protégées uniquement par de la cryptographie symétrique avec des clés qui n’ont jamais transité sous protection asymétrique. L’algorithme de Grover accélère la recherche exhaustive, mais de manière quadratique seulement, et dans des conditions pratiques peu favorables à l’attaquant. AES avec des clés de 256 bits reste confortable ; les clés de 128 bits font l’objet de discussions, mais ne sont pas dans la même catégorie de risque que RSA ou les courbes elliptiques. Un secret partagé installé à la main, un disque chiffré par une clé dérivée d’une phrase de passe robuste, un tunnel à clé pré-partagée bien générée : la collecte rétroactive ne les concerne pas. La condition est importante, cependant : il ne faut pas que la clé symétrique ait elle-même voyagé sous une protection à clé publique, ce qui est justement le cas le plus courant. Le chapitre sur les données au repos aide à débusquer où la clé symétrique est en réalité enveloppée par une clé asymétrique.

Les condensés et mots de passe correctement hachés. Un condensé n’est pas un chiffrement, et Shor n’a rien à lui dire. Les fonctions de dérivation de mots de passe souffrent bien davantage de la faiblesse des mots de passe que de tout ce qui est quantique.

Les signatures, au sens de la collecte rétroactive. Enregistrer aujourd’hui une signature ne permet rien de plus demain qu’aujourd’hui, sinon de forger d’autres signatures avec la même clé le jour où on saura la retrouver. C’est un vrai problème, mais c’en est un autre : celui de la validité à long terme des documents signés et des racines de confiance, qu’il faudra renouveler avant la machine. Il ne relève pas de l’écoute d’aujourd’hui.

Les données qui n’ont jamais été chiffrées, ou qui ont déjà fui. On sourira, mais une partie des inquiétudes post-quantiques porte sur des données qui transitent par ailleurs en clair dans un courriel non chiffré, qui sont stockées sans protection dans un partage réseau, ou qui ont déjà été publiées dans une fuite précédente. Protéger contre l’ordinateur quantique une information qu’un stagiaire a transférée par messagerie grand public la semaine dernière relève d’une conception décorative de la sécurité.

Les métadonnées. Qui parle à qui, quand, combien : la plupart ne sont pas chiffrées du tout, et l’attaquant qui enregistre les connaissait avant de déchiffrer quoi que ce soit.

La durée de sensibilité, cette inconnue familière

On revient à x, la seule variable qu’on maîtrise, et qu’on estime très mal. La durée de sensibilité d’une donnée n’est presque jamais documentée. Les classifications usuelles disent à quel point une donnée est sensible, rarement pendant combien de temps. C’est pourtant la seule dimension qui compte ici.

On peut, grossièrement, ranger les données en quelques familles.

Les données éphémères, dont la valeur s’éteint en heures ou en jours : authentifiants temporaires, états de session, données opérationnelles du moment. Elles sont hors du champ.

Les données commerciales ordinaires, dont la sensibilité dure le temps d’un cycle : offres, négociations, prévisions, résultats avant publication. Quelques mois, rarement plus de quelques années. Elles sont hors du champ dans la plupart des scénarios crédibles.

Les données stratégiques d’entreprise, dont la sensibilité dure le temps d’une vie de produit ou d’un avantage concurrentiel : procédés de fabrication, formules, plans d’architecture de systèmes qui resteront en service, code source d’un produit qui vivra longtemps. On entre dans la zone grise, et la réponse dépend du rythme du secteur.

Les données personnelles de longue durée : génétique, données judiciaires, orientation, identité réelle derrière un pseudonyme. Leur sensibilité dure une vie, parfois davantage, puisque certaines touchent les descendants. Elles sont clairement dans le champ, et elles ont un défaut supplémentaire : la personne concernée n’a rien décidé, et c’est elle qui paiera.

Les secrets d’État et les sources, pour lesquels on raisonne en décennies par construction. Ils sont dans le champ, et leurs détenteurs le savent généralement mieux que nous.

La sensibilité qui augmente

Un point contre-intuitif complique ce tableau : certaines données deviennent plus sensibles avec le temps. L’identité d’un opposant anodin aujourd’hui peut devenir compromettante après un changement de régime. Une correspondance banale peut acquérir une valeur rétrospective si l’un des correspondants devient une personnalité publique. Un détail d’architecture sans intérêt en soi devient précieux le jour où ce système est la cible d’une campagne.

Il n’existe pas de manière rigoureuse d’anticiper cela. On peut seulement se rappeler que x n’est pas une constante, et qu’une estimation prudente vaut mieux qu’une estimation optimiste, surtout lorsque ce n’est pas soi qui paie l’erreur.

L’agrégation

Enfin, comme toujours en matière de fuite, la valeur d’un corpus récolté excède la somme de ses parties. Un attaquant qui déchiffre en 2040 dix ans de trafic d’une organisation ne lit pas des messages isolés ; il reconstitue un organigramme, des habitudes, des relations, des décisions. Des données individuellement périmées redeviennent, ensemble, une source de renseignement. C’est un argument pour ne pas rejeter trop vite la catégorie « commerciale ordinaire » quand le volume est important et que l’attaquant est de ceux qui ont le temps de lire.

Qui récolte, où et quoi

La menace a un auteur, et il est utile de le décrire plutôt que de le laisser flotter dans l’abstraction, où il grossit.

Récolter du trafic pour le déchiffrer dans dix ou quinze ans suppose trois capacités. Une position de capture : un accès aux liens, aux points d’échange, aux câbles, aux équipements d’un opérateur, ou à un réseau local compromis. Une capacité de stockage proportionnée, et une discipline de conservation sur une durée qui dépasse celle de la plupart des projets humains. Une capacité de sélection, parce que personne ne garde tout, et que le tri doit se faire au moment de la capture, sur des critères de métadonnées.

Cette combinaison désigne principalement des acteurs étatiques ou assimilés, disposant d’une infrastructure d’interception, et intéressés par des cibles précises : gouvernements, défense, diplomatie, recherche sensible, grands industriels stratégiques, journalistes et leurs sources, dissidents. Pour ces cibles, la menace est plausible et il serait imprudent de l’ignorer. L’ANSSI et ses homologues ont d’ailleurs clairement indiqué que la protection contre la collecte rétroactive justifiait de commencer la migration de l’établissement de clés sans attendre.

Pour une PME de vingt postes qui vend du matériel de jardinage, la question se pose différemment. Il est peu probable qu’un service de renseignement conserve pendant quinze ans ses échanges avec son expert-comptable dans l’espoir d’en extraire, en 2041, la marge brute de l’exercice 2026. Ce n’est pas impossible, puisque la collecte massive existe et que le tri peut être grossier. Mais la probabilité que ces données soient à la fois capturées, conservées, déchiffrées et exploitées est sans commune mesure avec celle qu’elles fuient demain par une boîte aux lettres compromise ou une sauvegarde exposée.

La collecte rétroactive est une menace de riche contre des cibles qui intéressent les riches. Elle n’en est pas moins réelle. Elle n’en impose pas moins un ordre de priorité qui n’est pas le même pour tout le monde.

Le cas du prestataire

Une nuance importante, pourtant : la PME de jardinage n’intéresse personne, mais son prestataire informatique, qui administre à distance deux cents clients dont un sous-traitant de la défense, intéresse davantage. Le trafic d’administration de ce prestataire (sessions SSH, accès distants, transferts de sauvegardes) transporte des secrets dont la durée de vie est celle des systèmes administrés, parfois longue, et agrège de nombreuses cibles en un seul point de capture. La menace se situe souvent là où l’on concentre, pas là où l’on stocke.

Raisonner une priorisation

Tout cela ne sert que si l’on en tire un ordre de travail. Voici une manière de le construire, qui n’a rien de révolutionnaire et qui a le mérite de pouvoir être tenue sur une feuille.

Trois questions par flux

Pour chaque flux ou stock identifié, trois questions suffisent à une première passe.

Quelle est la durée de sensibilité la plus longue de ce qui y passe ? Pas la moyenne : la plus longue. Un tunnel qui transporte une fois par an un dossier sensible pour vingt ans hérite de ces vingt ans, parce que l’attaquant qui enregistre ne sait pas à l’avance quelle session contiendra quoi, et n’a donc aucune raison de ne pas tout garder.

Quelle est l’exposition à la capture ? Un flux qui traverse Internet ou des réseaux d’opérateurs est exposé ; un flux interne à un réseau local physique maîtrisé l’est beaucoup moins ; un stock chiffré qui ne quitte jamais un support hors ligne l’est encore moins. Pour les stocks, l’exposition est celle des copies : sauvegardes externalisées, archives dans des services tiers, boîtes aux lettres chez un fournisseur.

Quel est l’effort de migration ? Une connexion TLS entre un navigateur récent et un serveur qu’on contrôle peut passer en échange hybride par une mise à jour ; un protocole métier propriétaire entre des automates industriels peut ne jamais le faire. Voir à ce sujet l’éditorial sur le post-quantique hybride, qui détaille ce que coûte réellement la bascule.

La priorité va aux flux où la durée de sensibilité est longue et l’exposition forte. L’effort ne change pas la priorité ; il change le délai et la manière. Un flux prioritaire difficile à migrer ne justifie pas l’inaction ; il justifie des mesures compensatoires (réduire ce qui y passe, déplacer les données les plus durables vers un autre chemin, ajouter une couche de chiffrement symétrique à clé pré-partagée sur le segment exposé) en attendant.

Un exemple hypothétique

Supposons une association de taille moyenne qui accompagne des victimes de violences et héberge un dossier par personne suivie, avec un site public, une messagerie, un outil de gestion des dossiers accessible à distance, et des sauvegardes chez un prestataire.

Le site public transporte des informations publiques : hors champ, sauf le formulaire de contact, qui peut contenir des signalements. L’accès distant à l’outil de dossiers transporte des données dont la sensibilité dure la vie des personnes, et il traverse Internet : priorité haute, et c’est précisément le type de flux que l’échange hybride dans TLS protège déjà si le serveur et les navigateurs sont à jour. Les sauvegardes externalisées sont un stock durable chez un tiers : il faut savoir comment leur clé de chiffrement est protégée, et si elle est enveloppée par une clé asymétrique classique, le stock tout entier est à la merci d’une future machine. La messagerie interne, si elle sert à échanger des éléments de dossier, hérite de leur durée ; il vaudrait mieux qu’elle ne serve pas à cela.

On remarquera que la moitié de ces décisions n’ont rien de cryptographique. Décider que la messagerie ne transportera pas les dossiers, c’est réduire x sur un flux, sans migrer quoi que ce soit. La mesure post-quantique la moins chère est souvent de faire circuler moins de choses durables par des chemins exposés.

Ce qu’on peut faire sans attendre

Trois gestes n’attendent ni budget ni norme.

Le premier est de documenter la durée de sensibilité dans la classification existante. Ajouter une colonne « jusqu’à quand » à un inventaire de données coûte peu et change la lecture de tout le reste.

Le deuxième est de tirer parti de ce qui est déjà disponible : navigateurs, serveurs web récents et OpenSSH proposent des échanges hybrides, souvent activés par défaut dans les versions récentes. Vérifier qu’on en bénéficie réellement, sur les flux prioritaires, relève de la mise à jour et de la vérification, pas du projet de transformation.

Le troisième est de raccourcir ce qui peut l’être : purger les boîtes aux lettres des messages chiffrés qu’on n’a plus besoin de garder, réduire les durées de conservation des sauvegardes et des archives, cesser de conserver des captures réseau « au cas où ». Ce qu’on n’a plus ne peut pas être récolté chez soi. Cela n’efface pas ce qui a déjà été capté ailleurs, mais cela cesse d’alimenter le stock.

Ni panique ni déni

Les deux attitudes qu’on rencontre le plus souvent ont ceci de commun qu’elles évitent le tri, et ceci de différent qu’elles coûtent de l’argent à des gens différents.

La panique consiste à traiter toutes les données comme si leur sensibilité était éternelle et tous les attaquants comme s’ils disposaient d’une infrastructure d’interception mondiale. Elle produit des plans de migration totaux, chiffrés à l’échelle du système d’information, et qui échouent pour cette raison même, parce qu’un projet qui veut tout faire en même temps finit par ne rien faire du tout, sinon consommer son budget en études préliminaires. Elle a aussi un effet pervers : elle détourne l’attention et les moyens de menaces moins spectaculaires et beaucoup plus probables, qui n’ont pas eu la chance d’avoir un nom anglais aussi évocateur.

Le déni consiste à déclarer que l’ordinateur quantique utile n’existera pas de notre vivant, ou pas avant qu’on ait eu le temps de voir venir. Il oublie la propriété essentielle de la menace : elle est déjà active. Voir venir la machine ne sert à rien si le trafic a été récolté avant. Le déni est une stratégie qui fonctionne parfaitement, jusqu’au jour où elle a échoué depuis dix ans.

Entre les deux, il n’y a pas un juste milieu tiède, il y a un travail. Il consiste à dire, pour chaque flux : cette donnée, contre cet attaquant, pendant cette durée. C’est exactement le travail que les deux attitudes permettent d’éviter, et c’est pour cela qu’elles sont populaires.

Le meilleur argument contre

Il existe une objection sérieuse à tout ce raisonnement, et elle ne vient pas des négationnistes du quantique. Elle vient de gens qui pensent que la priorisation elle-même est mal posée.

Elle dit ceci : l’attaquant capable de récolter et de conserver pendant quinze ans a presque toujours un moyen plus court d’obtenir la donnée, et c’est ce moyen-là qu’il faut fermer d’abord.

Un acteur doté d’une infrastructure d’interception à l’échelle d’un pays dispose aussi, en général, de capacités d’intrusion. Pourquoi attendrait-il quinze ans pour lire un échange qu’il peut obtenir demain en compromettant l’un des deux postes qui le terminent ? Les extrémités sont presque toujours plus faibles que le canal. Un chiffrement post-quantique parfait entre deux ordinateurs dont l’un exécute un logiciel malveillant protège exactement autant qu’un chiffrement classique, c’est-à-dire pas du tout.

L’argument va plus loin : les ressources consacrées à la migration post-quantique seraient mieux employées, pour l’immense majorité des organisations, à durcir les postes, les identités, les sauvegardes et les processus. Et la migration elle-même introduit du code neuf, donc des failles neuves, aujourd’hui, pour une menace qui se concrétisera peut-être dans quinze ans.

Je trouve cet argument juste pour la plupart des organisations, et c’est d’ailleurs ce que la section sur les attaquants disait déjà : pour la PME de jardinage, le chantier prioritaire est ailleurs.

Il cède sur deux points. D’abord, la compromission d’une extrémité est active, donc détectable, risquée, coûteuse, et elle ne s’applique qu’aux cibles désignées au moment de l’attaque. La collecte rétroactive est passive, massive, et permet de choisir ses cibles après coup, une fois qu’on sait qui est devenu intéressant. Ce sont deux capacités différentes, et la seconde n’a pas d’équivalent dans le monde de l’intrusion. Ensuite, pour les flux qui passent déjà par des composants à jour (navigateurs, serveurs web, SSH), la migration de l’échange de clés est presque gratuite : elle vient avec les mises à jour. Ne pas en profiter serait refuser une assurance offerte.

La synthèse que je retiens est donc simple : pour la majorité, le post-quantique est une question de mise à jour et de tri, pas de programme ; pour une minorité exposée, c’est une urgence qui a déjà commencé. L’erreur est de croire qu’on appartient à la seconde catégorie quand on appartient à la première, ou l’inverse.

Ce que je ne sais pas

Je ne sais pas estimer z. Personne ne sait. Je sais seulement que les estimations de ressources nécessaires ont diminué au fil des publications, ce qui plaide contre l’optimisme, et que les machines réelles restent loin de ces estimations, ce qui plaide contre la panique. Toute affirmation plus précise que cela est un pari, et devrait être présentée comme tel.

Je ne sais pas ce qui est effectivement récolté. Les programmes de collecte massive existent, leurs capacités de stockage et leurs critères de sélection ne sont pas publics. Le raisonnement de cet éditorial suppose un attaquant rationnel, qui sélectionne ; il est possible que la sélection soit plus large que je ne le crois, auquel cas les données commerciales ordinaires en volume remontent dans la liste.

Je ne sais pas si les calendriers réglementaires tiendront. Des organismes de normalisation et des agences ont proposé des calendriers de dépréciation des algorithmes à clé publique classiques, qui visent la prochaine décennie. Ces calendriers ont déjà été ajustés et le seront probablement encore ; ils sont à vérifier auprès des sources officielles, qui ne sont pas ce texte.

Je ne sais pas mesurer la durée de sensibilité à l’avance. J’ai proposé des familles ; elles sont grossières, et la sensibilité qui augmente avec le temps les rend fragiles. C’est la limite de tout l’exercice : on prend une décision rigoureuse sur une variable qu’on estime à la louche. C’est encore mieux que de ne pas l’estimer du tout, et c’est à peu près tout ce qu’on peut en dire.

Ce qui reste

La collecte rétroactive est une menace sérieuse qui souffre d’une mauvaise réputation : trop d’annonces, pas assez de tri. Les annonces disent que tout est menacé. Le tri dit que la menace porte sur une intersection précise : des données dont la sensibilité dure plus longtemps que l’horizon crédible de la machine, qui passent par un échange de clés à clé publique, sur un chemin où un attaquant patient peut les capter. Cette intersection n’est pas vide, et elle n’est pas le monde entier.

Trois choses me semblent acquises. Que la variable décisive est la durée de sensibilité de la donnée, pas le système qui la transporte : c’est la seule qu’on puisse estimer, et c’est celle que personne ne documente. Que la confidentialité persistante, les bonnes pratiques TLS et les clés éphémères ne protègent pas contre cette menace-là, ce qui ne les rend pas inutiles mais oblige à changer d’outil pour ce problème précis. Et que la mesure la moins chère est souvent de faire circuler moins de choses durables, ce qui ne demande aucune norme, aucun algorithme, et aucun ordinateur quantique.

Il reste une ironie qu’on me pardonnera de relever. Depuis des décennies, on répète que le chiffrement protège les données. La collecte rétroactive rappelle qu’il les protège pendant un temps, et que ce temps n’a jamais été écrit nulle part. On a chiffré comme on rédige un testament sans date : avec conviction, et en espérant ne pas avoir à le relire.

🐝 Ce qui arrive si on s’en passe

Une organisation qui ignore la collecte rétroactive laisse s’accumuler, chez un tiers patient, un stock qu’elle ne pourra jamais rappeler : chaque session capturée aujourd’hui reste acquise à l’attaquant, quelle que soit la migration décidée demain. Faute de durée de sensibilité documentée, les flux qui transportent des données durables ne se distinguent pas des autres, et la migration commence par les plus faciles plutôt que par les plus exposés. Les sauvegardes externalisées dont la clé est enveloppée par une clé publique classique restent, pendant tout ce temps, un coffre dont la serrure a une date de péremption inconnue. Le déni présente ainsi un avantage rare : son échec se constate dix ans après avoir eu lieu.

🦫 Explication de la marmotte 🍫

Sur Internet, la plupart des échanges protégés commencent par un calcul qui permet aux deux côtés de se mettre d’accord sur une clé secrète sans la transmettre. Ce calcul repose sur des problèmes mathématiques que les ordinateurs actuels ne savent pas résoudre en un temps raisonnable. Un ordinateur quantique assez puissant, qui n’existe pas encore et dont personne ne connaît la date d’arrivée, pourrait les résoudre. Un attaquant peut donc enregistrer aujourd’hui des échanges chiffrés, les stocker, puis les déchiffrer le jour où cette machine existera. Cette collecte est déjà possible, ne laisse aucune trace chez la victime et ne peut pas être annulée. Les clés jetées après chaque session n’y changent rien, car l’attaquant pourra recalculer la clé à partir de ce qu’il a enregistré. Les courriels chiffrés sont particulièrement exposés, car ils restent longtemps dans les boîtes et les sauvegardes. En revanche, beaucoup de données ne sont pas concernées : celles qui ne seront plus sensibles au moment du déchiffrement, celles protégées uniquement par une clé secrète installée à l’avance des deux côtés, les mots de passe correctement transformés, et celles qui ont déjà fui autrement. La méthode consiste donc à noter, pour chaque donnée, combien de temps elle reste sensible, à vérifier si elle passe par un chemin où l’on peut l’enregistrer, puis à migrer d’abord les échanges qui cumulent les deux. Réduire ce qui circule et raccourcir les durées de conservation protège aussi, sans aucun calcul nouveau.

Pages voisines

La citent

Récolter maintenant, déchiffrer plus tard

Elle cite

: les deux pages se citent l’une l’autre.

Récolter maintenant, déchiffrer plus tard

Un disque dur et beaucoup de patience

L’inégalité qui ne dit pas ce qu’on croit

Ce que z n’est pas

Ce que y coûte

Ce que x devrait être

Ce que la menace touche réellement

La confidentialité persistante ne sauve rien

Le courrier chiffré, cet angle mort

Ce qu’elle ne touchera jamais

La durée de sensibilité, cette inconnue familière

La sensibilité qui augmente

L’agrégation

Qui récolte, où et quoi

Le cas du prestataire

Raisonner une priorisation

Trois questions par flux

Un exemple hypothétique

Ce qu’on peut faire sans attendre

Ni panique ni déni

Le meilleur argument contre

Ce que je ne sais pas

Ce qui reste

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines