L'IA accélère la cryptanalyse. La cryptographie doit s'adapter. 

En juillet 2026, Anthropic a publié deux résultats de cryptanalyse obtenus avec Claude Mythos Preview. L'un améliorait une attaque contre HAWK, un système de signature post-quantique proposé. L'autre améliorait une attaque contre une version à sept tours de l'AES. Anthropic a clairement indiqué les limites de ces résultats : aucun n'affecte les systèmes en production actuels. 

Cette mise en garde est un bon point de départ. L'IA n'a pas rendu le chiffrement déployé obsolète du jour au lendemain. Elle a simplement transformé la rapidité avec laquelle les chercheurs peuvent explorer un vaste corpus de techniques, tester des hypothèses, concevoir des expériences et découvrir des constructions inédites. L'effet immédiat est une accélération du travail de cryptanalyse, et non un raccourci miraculeux vers des mathématiques complexes. 

La question pratique n’est donc pas de savoir si l’IA va « casser la cryptographie ». Il s’agit plutôt de déterminer quelles parties d’un système cryptographique sont mises à rude épreuve, ce que les résultats récents démontrent concrètement et si les défenseurs peuvent réagir avant qu’une découverte de recherche ne se transforme en incident opérationnel. 

Trois façons dont un système cryptographique peut échouer  

La sécurité cryptographique comporte au moins trois couches, et celles-ci ne doivent pas être considérées comme interchangeables. 

Le premier est le constructionL'algorithme, ses paramètres et les hypothèses mathématiques sous-jacentes sont essentiels. Un algorithme de chiffrement public est censé être examiné par tous. Sa sécurité repose sur l'impossibilité pour un attaquant de résoudre le problème concerné avec les ressources disponibles. Un système de signature numérique doit permettre à quiconque de vérifier une signature sans rendre la falsification possible. Les preuves de sécurité précisent ces affirmations, mais uniquement sous certaines hypothèses et pour un objectif de sécurité spécifique. 

Le second est le la mise en oeuvreUn algorithme mathématiquement correct peut présenter des fuites au niveau du timing, du comportement du cache, de la consommation d'énergie, des émissions électromagnétiques, etc.safe L'aléatoire ou les réponses erronées constituent des risques. Une implémentation peut également mal utiliser une primitive correcte ou exposer un secret par une simple erreur de programmation. Aucune de ces attaques ne nécessite de résoudre le problème mathématique sous-jacent. 

Le troisième est la vente au détail XNUMXh/XNUMXLes clés doivent être renouvelées. Les clients compromis doivent être révoqués. Les protocoles doivent pouvoir intégrer de nouveaux algorithmes. Les équipes de sécurité doivent savoir où la cryptographie est utilisée et quelles données dépendent de chaque clé. Un système qui ne peut être modifié après la découverte d'une faille présente une résilience pratique moindre que ne le suggère le nom de son algorithme. 

Cette distinction explique également pourquoi les récents résultats en matière d'IA ne doivent pas être résumés en une seule attaque indifférenciée contre le chiffrement. HAWK concerne une construction candidate. Le résultat concernant l'AES concerne une cible de recherche réduite. Les exemples de BSI concernent l'analyse de l'implémentation. Chaque résultat présente un modèle de menace différent et une signification pratique différente. 

La cryptographie s'inscrit dans une surface d'attaque plus vaste. 

La cryptographie échoue rarement de manière isolée. Le dispositif déployé autour d'une primitive influence la manière dont un attaquant l'observe, la teste et y réagit. 

Une étude de 2026 menée par Petar Radanliev aboutit à une conclusion similaire, mais sous un angle différent. Sa méthodologie combine une analyse bibliométrique avec vingt entretiens avec des experts et trois ateliers sectoriels afin d'examiner les attaques menées par l'IA contre les systèmes à clé publique. L'article soutient que la sécurité cryptographique doit être considérée comme une propriété adaptative du système plutôt que comme une simple fonction de la robustesse de l'algorithme. Les données issues des entretiens et des ateliers sont utiles pour appréhender les préoccupations des praticiens, mais la petite taille de l'échantillon qualitatif ne saurait être interprétée comme une estimation de la prévalence à l'échelle de la population. 

Cette approche systémique est utile ici car elle relie les couches de conception, d'implémentation et d'exploitation. L'IA peut détecter les failles d'un système, analyser les fuites de données lors de son implémentation et faciliter la reprise après une compromission. Ce sont des capacités différentes, mais elles valorisent toutes les systèmes qui peuvent être inspectés, vérifiés et modifiés. 

Cette même accélération peut rendre l'usurpation d'identité d'application moins coûteuse, y compris dans les systèmes utilisant la cryptographie à clé publique. Les applications peuvent transporter une clé publique ou un certificat dans le cadre de leur fonctionnement normal, par exemple pour identifier une autorité de signature ou vérifier les messages signés. Ces éléments sont censés être publics, mais ils peuvent néanmoins servir à l'usurpation d'identité. Un logiciel malveillant peut les extraire et les copier dans une application similaire lorsqu'un système dorsal ou un contrôle de sécurité considère la présentation d'une clé ou d'un certificat particulier comme une preuve d'identité de l'application. Un logiciel malveillant assisté par l'IA pourrait automatiser cette extraction, reconstituer les flux de requêtes, générer le client similaire et adapter son trafic en fonction des modifications apportées à l'application. 

Les éléments publics extraits ne permettent toujours pas de falsifier les signatures correspondantes ni de déchiffrer les données. La faiblesse réside dans le fait que le protocole sous-jacent confond les éléments cryptographiques publics avec la preuve qu'une requête provient de l'application légitime. Lorsque l'identité du client est cruciale, le serveur exige un signal plus fort, tel qu'une attestation de la plateforme (si disponible) ou une signature prouvant la possession d'une clé privée générée et protégée sur cette installation. L'IA accélère l'extraction et la construction du client usurpateur ; elle ne compromet pas l'algorithme à clé publique sous-jacent. 

Ce que démontrent les résultats récents 

HAWK : un résultat important contre un candidat 

Anthropic a signalé une attaque améliorée permettant de récupérer les clés de HAWK, un schéma de signature post-quantique proposé, basé sur le problème d'isomorphisme de réseau. HAWK avait franchi plusieurs étapes du processus d'évaluation des schémas de signature post-quantiques du NIST, mais n'était ni déployé ni normalisé. Le projet HAWK indique désormais que le schéma a été retiré du processus après la divulgation de l'attaque. 

Le résultat reste significatif. Anthropic affirme que l'attaque réduit de moitié l'atout majeur de HAWK. L'attaque demeure exponentielle au lieu de se transformer en une faille polynomiale exploitable, et les ensembles de paramètres plus importants restent difficiles à attaquer. Cependant, rétablir la marge de sécurité prévue exigerait des modifications qui compromettraient certains avantages de HAWK en termes d'efficacité. 

Il s'agit d'une découverte au niveau de la construction, et non d'un jugement sur la cryptographie post-quantique dans son ensemble. L'attaque est spécifique à HAWK. Elle ne s'applique pas directement à Falcon, qui repose sur un problème difficile différent, et ne démontre pas que la cryptographie sur réseau est vulnérable en général. L'intérêt de ce résultat réside précisément dans le fait qu'une analyse publique a permis de déceler une faille avant que HAWK ne devienne une norme déployée dans les systèmes. 

AES à nombre d'itérations réduit : une avancée pour la recherche, pas une rupture pratique 

Le second résultat d'Anthropic concerne une version à sept tours de l'AES-128. L'AES-128 complet utilise dix tours ; l'AES-192 et l'AES-256 en utilisent respectivement douze et quatorze. Les cryptanalystes étudient les versions à nombre de tours réduit car elles permettent de tester les techniques d'attaque et d'estimer les marges de sécurité sans avoir à déchiffrer le chiffrement complet. 

Anthropic décrit une nouvelle technique de rencontre au milieu qui améliore les attaques précédentes contre l'AES à sept tours d'un facteur 200 à 800 environ, selon la méthode de mesure du temps d'exécution. L'attaque repose toujours sur un contexte de texte clair choisi, où un attaquant peut demander le chiffrement de nombreuses entrées avec une clé inconnue fixe. Les travaux antérieurs nécessitent environ 2105 Des textes clairs choisis, rendant l'expérience totalement impraticable face à des systèmes ordinaires. 

Ceci constitue une preuve utile que l'IA peut contribuer à la recherche en cryptanalyse. Cela ne prouve pas pour autant que le protocole HTTPS, le chiffrement de disque ou d'autres systèmes utilisant l'AES complet nécessitent une migration d'urgence. Un résultat obtenu contre sept tours ne peut être présenté comme une preuve de cassure de l'AES à dix tours sans supprimer la condition qui donne tout son sens à ce résultat. 

CryptanalysisBench : mesurer les capacités de manière plus systématique 

Un benchmark ne constitue pas une attaque contre la cryptographie déployée, mais il peut montrer si les modèles deviennent utiles dans le travail qui conduit aux attaques. Banc d'analyse de cryptanalyse évalue les modèles de langage à travers 191 tâches couvrant six familles de primitives cryptographiques. 

L'article répartit les tâches en trois grands groupes : les schémas présentant des failles pratiques connues ; les schémas sans faille pratique connue, testés à pleine puissance et dans des variantes réduites ; et les tâches de défi destinées à représenter les avancées de la cryptanalyse. D'après les résultats présentés, les modèles de pointe résolvent une grande partie des tâches présentant des failles connues, plusieurs tâches à pleine puissance du deuxième groupe, et un nombre bien plus important de variantes réduites. 

Les auteurs signalent également une attaque par récupération de clé exploitant une faille de conception dans le système de chiffrement authentifié SpoC et une erreur dans la preuve de sécurité contre les attaques à texte chiffré choisi publiée par KINDI. Ces découvertes doivent être interprétées avec prudence : l’article les présente comme nouvelles à la connaissance des auteurs, et non comme une raison de supposer que toute construction similaire est sans danger.safeLeur importance réside dans le fait que les résultats des modèles peuvent désormais produire des affirmations concrètes que les chercheurs peuvent tester par rapport à des spécifications et des implémentations réelles. 

L'intérêt opérationnel de ce référentiel est donc double. Il permet aux chercheurs de mesurer leurs progrès et offre un test de résistance potentiel avant déploiement pour les solutions candidates. Il ne dispense toutefois pas d'une évaluation par des experts. Un modèle peut produire un argument convaincant qui cible une variante moins performante, qui repose sur une hypothèse erronée ou qui contient une erreur subtile. Plus la découverte est peu coûteuse, plus la vérification indépendante est précieuse. 

L'IA a déjà une importance au niveau de la mise en œuvre. 

Le lien entre l'IA et la cryptographie ne se limite pas aux grands modèles de langage. L'Office fédéral allemand de la sécurité des systèmes d'information (BSI) décrit l'apprentissage automatique comme une technique éprouvée d'analyse des canaux auxiliaires. Une attaque par canaux auxiliaires tire des enseignements des effets involontaires produits par le calcul, tels que le temps d'exécution, la consommation d'énergie, les émissions électromagnétiques ou le comportement du cache. 

Le BSI indique que son équipe a combiné un réseau neuronal avec un solveur SAT pour retrouver une clé secrète AES à partir de courbes de consommation d'énergie lors du CHES Challenge 2018. Pour l'édition 2020, l'équipe a appliqué des techniques similaires à Clyde-128, une implémentation de chiffrement légère conçue pour résister aux attaques par canaux auxiliaires. Ces exemples ne compromettent pas l'AES en tant que construction mathématique ; ils permettent de récupérer des informations divulguées par une implémentation physique. 

Cette distinction est cruciale pour les équipes de défense. L'IA peut aider un attaquant à traiter des mesures bruitées, à sélectionner des caractéristiques pertinentes, à comparer des hypothèses et à relier la reconnaissance statistique à la récupération exacte de la clé. Elle peut également aider les équipes de défense à détecter les fuites de données lors des tests. Le BSI étudie l'application de ces méthodes aux implémentations asymétriques et post-quantiques, tout en constatant que les meilleurs résultats combinent souvent l'apprentissage automatique et l'expertise. 

La leçon à tirer n'est pas que l'apprentissage automatique remplace l'expertise en cryptanalyse. Elle est que la sécurité des implémentations est déjà un domaine de recherche concret où l'automatisation peut réduire le coût des analyses spécialisées. 

La cryptographie en boîte blanche augmente les coûts, elle n'établit pas de limite de confiance. 

La cryptographie en boîte blanche constitue une étude de cas pertinente car elle met en évidence le problème d'implémentation de manière particulièrement claire. Supposons qu'une application doive vérifier un jeton de licence ou authentifier une requête client. Un code d'authentification de message (MAC) classique repose sur une clé secrète. Si un client non fiable reçoit cette clé, un attaquant contrôlant ce client peut potentiellement générer des MAC valides, indépendamment de la robustesse de l'algorithme cryptographique. 

Les techniques de boîte blanche visent à rendre l'extraction de la clé intégrée plus difficile en la combinant à du code obscurci, des tables de correspondance transformées et d'autres techniques d'implémentation. Elles sont conçues pour les logiciels exécutés dans un environnement que l'utilisateur peut inspecter et manipuler. De ce fait, elles sont utiles pour augmenter le coût des attaques contre les composants de paiement logiciels, les systèmes de licences, la protection du contenu et certains systèmes de protection du modèle embarqués. 

Ces outils ne transforment pas le client en un environnement de confiance. Lors d'une conférence Microsoft Research en 2016, les auteurs de l'article « Differential Computation Analysis » ont décrit un logiciel équivalent à l'analyse différentielle de consommation énergétique. Leurs outils enregistraient les traces d'accès mémoire des logiciels instrumentés et utilisaient des corrélations dépendantes des clés pour extraire des clés à partir d'implémentations « boîte blanche » publiques de cryptographie standardisée. L'attaque ne nécessitait ni l'accès aux tables de correspondance du fournisseur, ni une démarche de rétro-ingénierie classique. 

L'analyse de traces distribuées (DCA) n'est pas un résultat de l'IA. L'IA peut certes accélérer certaines étapes de l'analyse de traces, mais il s'agit d'une possibilité future et non d'une caractéristique démontrée par la source même de la DCA. La conclusion établie est déjà suffisante : l'obfuscation d'un calcul ne supprime pas l'information qu'il produit. 

La cryptographie en boîte blanche peut constituer une solution acceptable lorsque le matériel de confiance est indisponible ou ne peut être utilisé sur l'ensemble des appareils. Elle ne doit pas être considérée comme la seule protection d'un secret ou d'une transaction de grande valeur. L'autorisation côté serveur, les clés matérielles lorsqu'elles sont disponibles, la signature de code, les contrôles d'intégrité en temps réel, la surveillance, les identifiants à durée de vie limitée et une procédure de révocation permettent de gérer différents modes de défaillance. La conception doit prendre en compte la possibilité que le client soit modifié ou extrait ultérieurement. 

Ce qui offre encore une position plus forte 

Aucun algorithme ne peut offrir de garantie permanente. Une meilleure performance s'obtient en combinant plusieurs propriétés : 

- Constructions soumises à un examen public à pleine capacité. Une norme finalisée et largement analysée, assortie d'une marge de sécurité significative, constitue un meilleur point de départ qu'une conception propriétaire ou une expérimentation à nombre de tirs réduit. (NIST) ML-KEM et ML-DSA Les normes bénéficient d'une analyse publique, mais la normalisation ne rend pas les révisions futures inutiles. 

- Hypothèses et marges prudentes. Un système ne devrait pas reposer sur le fait que la meilleure attaque connue soit à peine plus coûteuse que le niveau de sécurité requis. Les constructions candidates nécessitent une analyse continue, même après avoir passé avec succès une première évaluation. 

- Implémentations renforcées. Comportement à temps constant, safe L'aléatoire, les tests par canaux auxiliaires, la résistance aux pannes, le stockage sécurisé des clés et la composition correcte du protocole protègent l'écart entre une primitive et le dispositif qui l'exécute. Recommandations de la BSI sur la résistance aux canaux latéraux Il s'agit d'un problème d'ingénierie et d'évaluation, et non d'une propriété qui découle automatiquement du nom d'un algorithme. 

- Ne considérez pas les clés publiques comme une preuve d'identité de l'application. Une clé publique ou un certificat extrait d'une application peut être copié dans un client similaire. Sa présence peut tromper un contrôle d'identité faible, mais ne peut à elle seule créer une signature valide. Lorsque l'identité du client est importante, utilisez l'attestation de la plateforme lorsqu'elle est disponible ou une clé privée par installation générée et protégée sur l'appareil, exigez une preuve de possession et prévoyez la possibilité de révocation. 

- Vérification indépendante. Reproduisez une attaque, vérifiez ses paramètres, testez son code et examinez le théorème qu'elle démontre. Les preuves formelles et vérifiables par machine peuvent être utiles, mais les experts doivent néanmoins confirmer que l'énoncé formel correspond bien à la garantie de sécurité pertinente. 

- La possibilité de remplacer les composants. Gérer les dépendances cryptographiques, dissocier les choix d'algorithmes de la logique applicative, versionner les protocoles, assurer une migration ordonnée, renouveler les clés et révoquer les clients compromis : voilà ce qu'est la crypto-agilité en pratique. 

Pour les logiciels installés sur des appareils contrôlés par l'utilisateur, une distinction supplémentaire doit être maintenue. La confidentialité, l'intégrité, la confiance dans l'appareil et l'autorisation constituent des objectifs de sécurité distincts. Les techniques de boîte blanche peuvent contribuer à la réalisation d'un aspect de la conception, mais elles ne permettent pas d'atteindre simultanément tous ces objectifs. 

La résilience signifie être capable de bouger 

La cryptanalyse assistée par l'IA accélère le rythme de la recherche en sécurité. Elle permet d'explorer une cible plus en profondeur et de traiter les traces d'attaques par canaux auxiliaires à plus grande échelle. Une attaque potentielle peut se transformer en code exécutable avant même qu'une équipe humaine n'ait terminé l'étude de la documentation pertinente. De ce fait, la vérification, la reproductibilité et l'expertise deviennent plus importantes que jamais.  

La réponse immédiate n'est pas d'abandonner la cryptographie établie. Il s'agit de simplifier l'inspection et la modification du programme de sécurité sous-jacent. Utilisez des constructions publiques avec des marges de sécurité importantes. Testez les implémentations réelles pour détecter les fuites. Considérez les résultats des modèles comme des hypothèses jusqu'à ce qu'ils soient reproduits indépendamment. Suivez l'utilisation des algorithmes et des clés. Entraînez-vous à la migration avant qu'une situation d'urgence ne survienne. 

La cryptographie n'est pas résiliente parce qu'elle est mystérieuse. Elle l'est lorsque ses hypothèses sont publiques, ses implémentations testées, ses affirmations vérifiables et que ses opérateurs peuvent remplacer un composant lorsque de nouveaux éléments modifient la situation. L'IA continuera d'améliorer les outils des attaquants. Les systèmes de défense ont besoin de systèmes capables d'évoluer et de s'adapter à un rythme comparable. 

Sources et lectures complémentaires 

• « Anthropic : Découvrir les faiblesses cryptographiques avec Claude » : https://www.anthropic.com/research/discovering-cryptographic-weaknesses 

• « CryptanalysisBench : Les titulaires d’un LLM peuvent-ils faire de la cryptanalyse ? » : https://arxiv.org/abs/2607.18538 

• « Matthew Green : Quelques réflexions sur les nouveaux résultats de cryptanalyse d'Anthropic » : https://blog.cryptographyengineering.com/2026/07/29/some-notes-about-anthropics-new-results/ 

• « BSI : Applications de l’intelligence artificielle en cryptographie » : https://www.bsi.bund.de/EN/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Kryptografie/KI-in-der-Kryptografie/ki-in-der-kryptografie.html 

• « BSI : Résistance aux canaux secondaires » : https://www.bsi.bund.de/EN/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Kryptografie/Seitenkanalresistenz/seitenkanalresistenz_node.html 

• « NIST FIPS 203 : Norme relative au mécanisme d’encapsulation de clés basé sur un réseau de modules » : https://csrc.nist.gov/pubs/fips/203/final 

• « NIST FIPS 204 : Norme de signature numérique basée sur un réseau de modules » : https://csrc.nist.gov/pubs/fips/204/final 

• « HAWK : un schéma de signature inspiré du problème d'isomorphisme de réseau » : https://hawk-sign.info/ 

• « Microsoft Research : Analyse par calcul différentiel » : https://www.microsoft.com/en-us/research/video/differential-computation-analysis-hiding-your-white-box-designs-is-not-enough/ 

• « Radanliev : Adversaires adaptatifs pilotés par l’IA et érosion de la confiance cryptographique dans les systèmes à clé publique » : https://link.springer.com/article/10.1186/s40543-026-00547-y