Cinq semaines durant l'été 2026
La plupart d'entre nous attendent l'été avec impatience.
Les gens finissent de travailler un peu plus tôt, partent en vacances et se changent les idées pour oublier le train-train quotidien et le stress. Les cryptanalystes – ces personnes qui consacrent leur temps à rechercher des failles dans les systèmes cryptographiques – ne sont toutefois pas comme la plupart des gens, et l’été 2026 en est la parfaite illustration.
Au cours des dernières semaines (cinq au moment où nous écrivons ces lignes), on a assisté à une vague de développements (annonces d'attaques et résultats confirmés) concernant des éléments importants de la cryptographie post-quantique.
À partir du 23 juillet,, Woselowski a publié un prépublication présentant un algorithme qui améliore la solution la plus connue au problème de l’isogénie supersingulière. Cela se traduit par une réduction de la marge de sécurité estimée pour des schémas tels que SQIsign – qui fait actuellement l’objet d’un processus de normalisation par le NIST. Les conséquences concrètes sur les paramètres restent encore à déterminer.
Quelques jours plus tard seulement, le 28 juillet, un article de blog d’Anthropic a été publié, contenant deux attaques à la une. Anthropic affirme que ces travaux ont été principalement réalisés par l’intelligence artificielle, puis vérifiés par des humains. Les victimes étaient HAWK – qui faisait également l’objet d’un processus de normalisation par le NIST – et une version simplifiée de l’AES-128 – comportant 7 tours au lieu de 10. Si ce dernier résultat n’a pas de répercussions immédiates sur le schéma AES complet, l’attaque correspondante contre HAWK a effectivement réduit de moitié la longueur de la clé secrète, et l’équipe a retiré ce algorithme du processus de normalisation.
Le 31 juillet,, un avant-projet a fait la une de l’actualité dans la communauté cryptographique. Daniel Simon (connu pour ses contributions aux débuts du développement de l’informatique quantique) y décrivait un algorithme quantique qui permettrait de résoudre le problème des classes de cosets diédrales (DCP) en temps polynomial. Même si un tel algorithme peut ne pas sembler inquiétant à première vue pour la plupart des gens, il représenterait en réalité un coup dur pour la cryptographie sur réseau – menaçant la confiance que nous accordons à la sécurité quantique des algorithmes ML-KEM (FIPS 203), ML-DSA (FIPS 204), FalconDSA (FIPS 206), etc. Environ deux semaines plus tard, Gupte, Ragavan et Zhandry ont démontré que cet argument ne pouvait déboucher sur aucune solution efficace au problème DCP, et que par conséquent, le seraient affectés restent intacts.
Le dernière nouvelle a été publié par Ghoshal, Ishai, Jain et Sun le 10 août concernant le problème classique de McEliece. Cette contribution comporte deux volets. Le premier est un discriminateur classique en temps quasi-polynomial (c'est-à-dire quasi-efficace) pour une clé publique – un algorithme capable de distinguer une clé publique d'un bruit aléatoire. Il n'existait aucun discriminateur de ce type avant la publication de cet article ; toutefois, cela n'a pas non plus d'implications immédiates sur la sécurité du schéma. La deuxième contribution est une attaque de déchiffrement heuristique présentant la même complexité asymptotique. Aucun de ces deux algorithmes n’est applicable en pratique, et la validité du second n’a pas encore été confirmée. Néanmoins, si l’attaque de déchiffrement s’avérait exacte, elle pourrait entraîner une réévaluation complète de la sécurité et des paramètres du schéma. Un travail complémentaire de Vedenev a proposé un moyen de transformer le discriminateur en une attaque par récupération de clé, mais cette stratégie s’est par la suite s'est avérée remarquablement inefficace par Daniel Apon.
Cet été a sans aucun doute été un été inoubliable.
« Broken » n'est pas une valeur booléenne
La cryptographie fait l'objet d'attaques constantes.
La sécurité des systèmes cryptographiques à clé publique repose sur la difficulté à résoudre certains problèmes mathématiques. Ces problèmes deviennent plus faciles à résoudre avec le temps, grâce à de nouvelles découvertes mathématiques, à de nouvelles astuces algorithmiques et à l’amélioration des capacités de calcul. La communauté cryptographique s'efforce en permanence d'améliorer les algorithmes qui résolvent ces problèmes difficiles, en tentant de les contourner ou, à tout le moins, de les résoudre plus rapidement. Ces attaques ne débouchent pas toujours sur un contournement complet ; au contraire, la grande majorité d'entre elles ne constituent que des améliorations progressives, mais surtout, elles contribuent à une meilleure compréhension des raisons pour lesquelles le problème est difficile.
Cela dit, chacune des attaques présentées ces dernières semaines a eu des implications différentes pour le système concerné, ainsi que pour les utilisateurs et les personnes qui le mettent en œuvre.
| Travail | Cible | Position dans le cycle de vie | Ce que cela implique pour un RSSI / une équipe de sécurité |
| Wesolowski (ePrint 2026/1486, 23 juillet) Algorithme générique plus rapide pour le problème de l'isogénie supersingulière | SQIsign (et autres schémas d'isogénie apparentés) | Surpris avant normalisation. SQIsign fait actuellement l'objet d'un processus de normalisation. Il n'est déployé nulle part. | Il n'y a rien à faire. Les équipes n'utilisent pas SQIsign. Soyez attentifs aux éventuelles mises à jour des paramètres si vous suivez ce projet en tant qu'option compacte potentielle pour les signatures. |
| Anthropic (28 juillet), ainsi que des articles complémentaires indépendants | HAWK | Surpris pré-normalisation.
HAWK était en cours de normalisation, mais le projet a été abandonné après l'attaque. |
Il n'y a rien à faire. HAWK n'est plus dans la course. Il convient de noter que la manière dont il a été découvert (grâce à une approche basée sur l'IA). Il faut s'attendre à ce que le rythme de la cryptanalyse sur les algorithmes candidats s'accélère. |
| Anthropic (28 juillet) | AES-128 (7 tours sur 10) | Norme mise en œuvre, mais le résultat porte sur une variante affaiblie et, même dans ce cas, cela n’est pas réalisable (~2^105 textes en clair choisis) | Il n'y a rien à faire. L'AES complet n'est pas affecté ; il ne s'agit là que d'une avancée théorique progressive. C'est bon à savoir pour pouvoir répondre clairement à la question « L'IA a-t-elle cassé l'AES ? » « non ». |
| Simon (ePrint 2026/1591, 31 juillet) ; réfuté par Gupte–Ragavan–Zhandry (2026/1693, 15 août) | Problème des classes de coset diédrales → aurait aurait remis en cause les algorithmes ML-KEM, ML-DSA et d’autres schémas de treillis face aux ordinateurs quantiques | Normes mises en œuvre et constructions retenues. Cependant, cette affirmation a été réfutée par une preuve vérifiée par ordinateur en l'espace d'environ deux semaines. | Rien à faire. Poursuivre la migration vers PQC comme prévu. À retenir : même la contestation d’un chercheur sérieux à l’encontre des normes fondamentales a été examinée et réglée rapidement. Si une contestation venait à être retenue à l’avenir, il faudra s’attendre à des recommandations du NIST et de la CISA. Ne réagissez pas aux prépublications. |
Les travaux en cryptanalyse ont des répercussions de nature et d'ampleur variables. Nous présentons ici une liste informelle de catégories classées par ordre d'importance.
- Aucune faiblesse détectée. Il peut s'agir, par exemple, de tentatives infructueuses de résolution de problèmes fondamentaux (les travaux récents de Simon, l'article de Chen de article de 2024, l’article d’Eldar et Shor de 2016) ou encore des résultats qui renforcent les hypothèses de difficulté (résultat d’OpenAI sur le CVP).
- Une faille découverte dans une structure étroitement liée. Il s'agit d'efforts visant à comprendre la sécurité d'une construction importante en attaquant une variante étroitement liée (analyse récente de l'AES par Anthropic).
- Érosion asymptotique de la sécurité et petites améliorations algorithmiques. Il peut s’agir d’attaques marginales mais directes contre la construction principale, ou de résultats qui affinent l’estimation des ressources nécessaires à une attaque donnée. Les contributions des travaux de cette catégorie sont suffisamment modestes pour ne pas faire la une, et leur impact est souvent difficile à quantifier (travaux de Woselowski sur les isogénies).
- Une dégradation significative de la sécurité et des estimations de ressources inattendues. Il peut s’agir d’attaques directes (provenant souvent de directions peu explorées) qui ont des implications significatives sur la sécurité du système (comme la récente attaque d’Anthropic contre HAWK) ; ou bien d’une nouvelle estimation des ressources qui modifie le paradigme de modélisation des attaques réelles (l’estimation de Google concernant la résolution du DLP au début de cette année, qui a déplacé les repères et entraîné un resserrement des délais de migration vers la PQC).
- Attaque totale. Il s’agit d’attaques qui invalident complètement l’hypothèse de sécurité d’un schéma particulier (Castryck et Decru attaque contre SIKE en 2022).
- Effondrement des hypothèses fondamentales. Cela se produit lorsqu’une menace imminente pèse sur les fondements d’un ou plusieurs schémas (l’algorithme quantique de Shor pour factoriser la factorisation et DLog), ce qui entraîne l’abandon de tous les schémas concernés.
Érosion progressive et rupture soudaine : ce à quoi il est difficile de se préparer.
L'érosion est imperceptible d'un jour à l'autre, mais elle devient frappante au bout de quelques années.
Parmi les catégories (non officielles) ci-dessus, les catégories I et II n’ont que peu, voire aucune conséquence pratique immédiate sur la sécurité ; en revanche, les catégories IV, V et VI sont assez rares, mais suffisamment importantes pour attirer l’attention des acteurs tant à l’intérieur qu’à l’extérieur du domaine. Le seul type de résultat ayant des conséquences qui ne fait jamais la une des journaux est celui de la catégorie III, ce qui en fait, en quelque sorte, le plus dangereux. Lorsqu’un travail relevant de la catégorie III est publié, rien n’est réellement compromis ; tout continue de fonctionner, il n’y a pas de CVE, ni d’avis officiel, ni de date butoir concrète pour la migration. La seule chose qui s’est produite, c’est que le coût de la résolution du problème central difficile a changé : il est devenu plus facile. Dans bon nombre de ces cas, la transposition du résultat théorique en paramètres concrets reste une question ouverte, ce qui rend difficile pour tout le monde de savoir quelles en sont les conséquences réelles.
Il est épuisant de suivre le rythme des avancées constantes en matière de cryptanalyse, d’autant plus lorsqu’il faut évaluer les implications concrètes de chaque résultat. Il est donc déraisonnable d’attendre des équipes de sécurité qu’elles surveillent de près l’érosion progressive de la sécurité de leur infrastructure cryptographique. Il est également déraisonnable d’attendre de quiconque qu’il prédise l’avenir.
HAWK a été proposé en tant que schéma en 2022. Il a finalement été retiré du processus de normalisation du NIST en 2026 – après trois cycles – suite à une baisse significative (et inattendue) de son niveau de sécurité. Mais l’histoire de SIKE est encore plus extraordinaire. Ce schéma avait été initialement proposé en 2011, et ce n’est qu’en 2022 – lors du quatrième et dernier cycle du processus de normalisation du NIST pour les KEM – qu’une faille classique complète a été découverte. Aucun ordinateur quantique n’a été nécessaire. Si, pour certains cryptographes, cela n’était pas une surprise totale, cela a certainement été inattendu pour la majorité des personnes travaillant sur ces normes. Sinon, ce schéma n’aurait pas atteint la dernière phase. Cela constitue un exemple remarquable de la manière dont des vulnérabilités peuvent être découvertes de manière inattendue, même après plus d’une décennie d’analyse.
La fréquence d'horloge a changé, la fenêtre temporelle se rétrécit
L'IA change la donne.
Nous avons tous constaté une accélération du rythme du développement – dans tous les domaines – depuis l’émergence de l’IA générative. Les charges de travail agentiques, les « harnesses » et les modèles de pointe de plus en plus puissants ont encore élargi le champ des possibilités de l’IA. Ce qui prenait autrefois des années ne prend désormais plus que quelques semaines. Ce qui nécessitait auparavant plusieurs experts peut désormais être pris en charge par quelques personnes compétentes ayant accès à des modèles de pointe. Cela vaut également pour la cryptanalyse. Nous sommes déjà en passe d’atteindre près de 400 travaux sur la cryptanalyse (sur eprint.iacr.org) pour cette année, contre un total de 325 pour 2025 et 318 pour 2024. De plus, ces nouvelles attaques assistées ou menées par l’IA sont souvent de meilleure qualité. Les agents ayant accès à des outils de vérification formelle tels que Lean ou Tamarin peuvent les utiliser pour détecter des vulnérabilités dans les protocoles et primitives cryptographiques. Et cette accélération est visible si l’on examine le calendrier de HAWK : la construction a résisté à deux cycles complets et à quatre années d’examen par des experts humains, mais il n’a fallu que 60 heures de travail de l’IA (et 100 000 dollars d’utilisation de l’API) pour découvrir une vulnérabilité significative.
Les cryptanalystes ne manqueront pas de saisir l’occasion d’utiliser ces outils. De plus – et c’est là un aspect un peu plus inquiétant –, de nombreuses structures actuellement utilisées n’ont pas fait l’objet de toute l’attention et de tout l’examen minutieux qu’elles méritaient, et il y a fort à parier que bon nombre d’entre elles recèlent des failles restées latentes jusqu’à présent. Pour les normes du NIST et d’autres structures en vigueur depuis des décennies, cela semble peu probable. En revanche, pour les protocoles sur mesure, les solutions propriétaires obscures proposées par certains fournisseurs, les bibliothèques développées en interne et les normes qui n’ont fait l’objet que d’un examen superficiel, vous pouvez être certain que des vulnérabilités seront découvertes à un rythme sans précédent. Les outils de cryptanalyse n’ont jamais été aussi puissants et accessibles, et les barrières à l’entrée dans le domaine de la cryptanalyse n’ont jamais été aussi basses.
Et cela ne concerne pas uniquement l'IA.
La compréhension de la manière de mettre en œuvre des algorithmes sur de véritables ordinateurs quantiques s’est également considérablement améliorée au cours des derniers mois. Les travaux menés par le groupe Quantum AI de Google, Iceberg Quantumet Oratomic ont rapproché l’objectif quantique, en démontrant qu’un ordinateur quantique « suffisamment puissant » pour casser des algorithmes cryptographiques est en réalité bien plus petit que ce que l’on pensait auparavant. En réaction, plusieurs entreprises telles que Google, Microsoft et Cloudflare, ainsi que le gouvernement américain, ont réévalué et renforcé leurs plans de migration quantique. L’objectif est désormais fixé à 2029.
L'agilité : ce qui vous permet de dormir tranquille
Tu ne peux pas te faire du souci pour tout. Il faut quand même que tu dormes.
Si vous êtes RSSI, directeur des risques, responsable de la sécurité ou toute autre personne en charge de la sécurité au sein de votre entreprise, vous ne pouvez pas passer des nuits blanches à vous inquiéter de chaque attaque potentielle. Ce qui devrait réellement vous tenir éveillé, ce n’est pas la question « ML-KEM est-il sécurisé ? ». Cette question ne vous concerne pas, pas plus qu’elle ne concerne quiconque d’autre au sein de votre organisation. Tous les experts du monde capables d’analyser l’attaque de Simon contre la cryptographie en treillis pourraient probablement tenir dans une seule pièce. Vous êtes responsable de la sécurité de votre entreprise, et l’idée que devrait vous empêcher de dormir est
« Si ML-KEM n'est pas sécurisé, que se passera-t-il lundi ? »
Si vous vous retrouvez dans cette situation, votre réaction et les mesures que vous pourrez prendre dépendront de l'infrastructure dont vous disposez. Dans l'idéal, vous aurez accès à un bouton indiquant « Remplacer le ML-KEM par un KEM sécurisé ». Ce concept s’appelle l’ « agilité cryptographique ». Elle n’a pas pour but d’empêcher les attaques, ni de rendre un schéma cryptographique plus sûr. L’agilité vise à fournir à toute personne responsable de la sécurité un plan concret et applicable sur la marche à suivre au cas où un composant cryptographique ne serait plus sûr – que ce soit parce que sa sécurité s’est progressivement érodée, ou parce qu’une vulnérabilité grave et inattendue a été découverte.
Heureusement, ML-KEM reste sécurisé, vous avez donc encore le temps de vous procurer ce bouton d'échange magique.
L'agilité ne suffit pas
Il n'y a pas de solution miracle.
L'agilité cryptographique est un outil tourné vers l'avenir, et cela se ressent particulièrement en matière de confidentialité. Si un système de génération de clés ou un schéma de chiffrement est compromis, tous les textes chiffrés reposant sur ce schéma sont déjà lisibles – ils sont perdus – quelle que soit la rapidité avec laquelle vous changez de schéma après la violation. L’agilité protégera les sessions futures, ainsi que les signatures et les certificats, mais elle ne permettra pas de rétablir la confidentialité perdue. Collecter maintenant, déchiffrer plus tard ne sont pas l’apanage des adversaires quantiques, et seuls des choix prudents – tels que les schémas hybrides – peuvent réellement y remédier.
L'agilité sans visibilité, c'est comme une brigade de pompiers sans plan de la ville. Vous pouvez certes changer rapidement de schéma d'un simple clic, mais ce clic ne peut modifier le schéma que là où le système sait qu'il est utilisé. La découverte et l’inventaire constituent donc la première étape, et la plus fondamentale, pour mener toute action au sein de votre infrastructure cryptographique. Un CBOM ne suffit pas. Pour être efficace, vous avez besoin d’un inventaire à jour qui vous offre une visibilité sur les éléments cryptographiques les plus importants de l’organisation.
Un dernier aspect à prendre en compte est que l'agilité, si elle n'est pas mise en œuvre correctement, peut faire plus de mal que de bien. Une agilité mal appliquée constitue un point de défaillance potentiel ; elle peut être la cible d'attaques par dégradation, de manipulation de paramètres, de substitution d'algorithmes, etc. L'agilité elle-même devient alors une cible pour les attaques ; il est donc nécessaire de la déployer correctement, de la tester et de la maintenir de manière appropriée.
Ton programme pour lundi matin
Prépare-toi une bonne tasse de café. La journée sera longue, mais enrichissante.
L'agilité cryptographique résulte d'une organisation adéquate de l'ensemble du système autour de votre infrastructure cryptographique. Le lundi matin est le moment idéal pour commencer à mettre cela en place. Vous pouvez vous poser, ainsi qu'à votre équipe, les questions suivantes pour vous guider dans cette démarche.
- Disposez-vous d'une visibilité suffisante ? Avez-vous mis en place un processus permettant d'évaluer et de hiérarchiser les risques ? Mettre en place l'inventaire des éléments cryptographiques et la constitution d’un inventaire centralisé, exhaustif et à jour constituent la première étape, et la plus fondamentale, pour aller de l’avant.
- Tout ce qui doit être protégé l’est-il réellement ? Identifiez les charges de travail et les agents d’IA qui ne sont pas correctement identifiés, puis émettez les certificats; identifiez les appareils et les pipelines utilisant des méthodes de cryptographie obsolètes et mettez-la à jour; identifiez les limites de confiance qui nécessitent une signature de code.
- Disposez-vous d'un contrôle centralisé et suffisant sur votre infrastructure cryptographique ? Le cycle de vie des clés et des certificats est-il correctement automatisé ? La cryptographie est omniprésente, et une gestion manuelle et décentralisée n'est pas évolutive. Qu'est-ce qui est évolutif ? Un contrôle centralisé et automatisé.
C'est ainsi qu'on développe l'agilité.
Tes projets pour le week-end
Repose-toi bien, ML-KEM est en sécurité.
L'attaque de Simon contre les treillis s'est révélée erronée à peine quelques semaines après avoir été rendue publique. Ce n'est pas la première fois qu'un chercheur de renom tente sincèrement de remettre en cause les fondements d'une cryptographie largement répandue : en 2022, Yilei Chen avait proposé un algorithme quantique visant à contourner les treillis ; Claus P. Schnorr avait quant à lui tenté de casser le RSA de manière classique en 2021 ; Lior Eldar et Peter Schorr ont également proposé une autre méthode quantique pour casser les treillis en 2016. Dans tous ces cas, une faille a été découverte en quelques semaines par la communauté scientifique. Le système fonctionne. Mais, dans ce cas précis, « le système fonctionne » décrit l’aspect « découverte » de la cryptanalyse – vous pouvez laisser cela aux cryptographes – cela ne décrit pas l’aspect « correction », et c’est cet aspect-là qui relève de votre responsabilité.
Une fois que l'agilité cryptographique sera mise en place, vous pourrez profiter du week-end pour vous reposer.
