Une équipe de chercheurs de l’université de Californie à San Diego (UC San Diego) et de l’INRIA Nancy vient de publier un résultat qui secoue un pan entier de la cryptographie à clé publique. Le 20 septembre 2026, Laura Shea, Miro Haller, Adam Suhl, Nadia Heninger et Emmanuel Thomé ont mis en ligne sur l’archive IACR ePrint un article intitulé Forging 1024-bit RSA signatures in nearly SNFS time. Leur démonstration : forger des signatures RSA valides sans jamais factoriser la clé et sans voler le secret privé. Il a fallu 1 380 années-cœur de calcul, cinq mois de travail et environ 4,3 milliards de requêtes envoyées à un oracle de signature brute. Le résultat ne casse pas RSA du jour au lendemain, mais il change la façon dont les architectes de sécurité doivent penser leurs interfaces cryptographiques.
Ce n’est pas une attaque théorique de plus rangée dans un tiroir académique. Elle ressuscite un algorithme publié en 2007 par Antoine Joux, David Naccache et Emmanuel Thomé, resté largement ignoré pendant près de vingt ans faute de démonstration pratique. En 2026, la puissance de calcul disponible a changé la donne : ce qui semblait hors de portée est devenu un projet de cinq mois pour une équipe universitaire bien équipée. Pour les entreprises françaises et européennes qui exploitent encore des cartes à puce, des HSM ou des systèmes de signature aveugle reposant sur du RSA brut, la question n’est plus académique.
Ce que révèle l’attaque de forge de signature RSA en 2026
Le papier référencé IACR ePrint 2026/2131 décrit une technique qualifiée d'”oracle-assisted”, proche dans sa complexité du crible spécial du corps de nombres (SNFS), la variante rapide du crible général utilisée pour factoriser des entiers ayant une structure algébrique particulière. Contrairement à une factorisation classique, l’attaque ne cherche pas à retrouver les facteurs premiers p et q du module RSA. Elle exploite un accès temporaire à un oracle de signature RSA brute, c’est-à-dire un service qui accepte de calculer m^d mod N sur une valeur choisie par l’attaquant et qui renvoie le résultat sans appliquer de bourrage (padding) ni de vérification de format.
Concrètement, l’attaquant envoie des millions de valeurs soigneusement choisies à cet oracle, collecte les réponses, puis mène hors ligne un calcul de type collecte de relations, semblable à celui utilisé dans le crible du corps de nombres. Une fois ce calcul terminé, il n’a plus besoin de l’oracle : il peut forger des signatures pour des messages arbitraires. Sur une clé RSA-1024, l’équipe a démontré la faisabilité complète du procédé avec environ 2^32 requêtes à l’oracle, soit 4,3 milliards d’appels, et 1 380 années-cœur de calcul réparties sur cinq mois.
Comment fonctionne un oracle de signature RSA brute
Pour comprendre la portée réelle de la faille, il faut distinguer une signature RSA correctement encodée d’une signature RSA “nue”. Dans une implémentation moderne, un message n’est jamais signé tel quel : il passe par un bourrage normalisé, RSA-PSS ou RSASSA-PKCS1-v1_5, qui ajoute du hasard ou une structure vérifiable avant l’élévation à la puissance privée d. C’est justement cette étape que l’attaque de Shea, Haller, Suhl, Heninger et Thomé contourne, en visant des interfaces qui exposent le calcul mathématique brut sans aucun bourrage.
Ce type d’interface existe encore dans plusieurs contextes bien identifiés. Certains mécanismes PKCS#11 de bas niveau, comme un équivalent de CKM_RSA_X_509, exposent une opération RSA brute plutôt qu’un mécanisme qui applique lui-même le bourrage. Les protocoles de signature aveugle, utilisés dans certains systèmes de monnaie électronique ou de titres anonymes, reposent historiquement sur l’algèbre RSA nue : le demandeur aveugle un message avec un facteur r, le signataire calcule sa réponse sans voir le contenu réel, puis le demandeur retire le facteur de masquage. Enfin, certaines cartes à puce et jetons matériels anciens exposent encore, pour des raisons d’interopérabilité, une primitive RSA non protégée.
Les chiffres clés à retenir de l’expérience UC San Diego / INRIA
Le volume de calcul engagé donne la mesure du défi technique surmonté. Voici les principaux chiffres publiés par l’équipe de recherche.
- Taille de la clé attaquée : RSA-1024 bits
- Nombre de requêtes envoyées à l’oracle : environ 4,3 milliards (2^32)
- Temps de calcul cumulé : 1 380 années-cœur
- Durée du projet : environ cinq mois calendaires
- Chute de sécurité estimée pour RSA-1024 : autour de 65 bits contre 80 bits en théorie de factorisation classique
- Chute de sécurité estimée pour RSA-2048 : environ 90 bits contre 112 bits habituellement admis
- Chute de sécurité estimée pour RSA-4096 : environ 119 bits contre 150 bits théoriques
La baisse de sécurité observée, de 15 à 30 bits selon la taille de clé, ne rend pas RSA-2048 cassable demain matin. Une perte de 30 bits représente un facteur de travail divisé par environ 1,07 milliard, ce qui reste un mur de calcul considérable pour un module RSA-2048 exposé à un oracle brut. Le point important n’est pas que RSA-2048 tombe aujourd’hui, mais que l’hypothèse “un module non factorisé est un module sûr” ne tient plus dès qu’une interface expose le calcul privé brut à un tiers non fiable.
Sécurité RSA par taille de clé : avant et après l’attaque par oracle
Le tableau suivant compare la sécurité théorique habituellement admise pour chaque taille de module RSA avec l’estimation révisée par l’équipe de recherche lorsqu’un oracle de signature brute est accessible à l’attaquant.
| Taille de clé RSA | Sécurité théorique (factorisation) | Sécurité estimée avec oracle brut | Perte estimée |
|---|---|---|---|
| RSA-1024 | ~80 bits | ~65 bits | ~15 bits |
| RSA-2048 | ~112 bits | ~90 bits | ~22 bits |
| RSA-3072 | ~128 bits | Non démontré, extrapolation prudente requise | Estimation en cours |
| RSA-4096 | ~150 bits | ~119 bits | ~30 bits |
Ces chiffres, publiés dans l’article IACR ePrint 2026/2131, s’appliquent uniquement aux déploiements qui exposent un oracle RSA brut à un attaquant. Un serveur TLS 1.3 classique, un certificat X.509 signé en RSA-PSS ou une signature PKCS#1 v1.5 correctement vérifiée ne sont pas concernés par cette dégradation.
Contexte historique : de Bleichenbacher à Joux-Naccache-Thomé
L’histoire de RSA est ponctuée d’attaques qui ne touchent pas la factorisation elle-même mais la façon dont le calcul privé est exposé. En 2006, Daniel Bleichenbacher avait montré qu’une vérification laxiste des signatures PKCS#1 v1.5, qui se contentait de lire un préfixe sans vérifier toute la structure du bourrage, permettait de forger des signatures sur des exposants publics faibles comme e=3. Dix ans plus tôt, en 1998, il avait déjà démontré une attaque par oracle de bourrage contre le chiffrement RSA, popularisée depuis sous le nom d’attaque Bleichenbacher et toujours citée dans les manuels de sécurité TLS.
La différence avec le travail de 2026 tient à la nature du défaut exploité. Bleichenbacher visait des erreurs d’implémentation dans la vérification du bourrage. L’algorithme de Joux, Naccache et Thomé, lui, s’attaque à la structure mathématique de l’opération RSA elle-même lorsqu’elle est exposée sans aucun bourrage. C’est une attaque contre le concept d’oracle brut, pas contre un bug de code. Un correctif logiciel isolé ne suffit pas : il faut retirer l’accès à l’opération brute ou en limiter drastiquement l’usage.
Chronologie des grandes attaques par oracle contre RSA
| Année | Chercheur(s) | Nature de l’attaque | Cible |
|---|---|---|---|
| 1998 | Daniel Bleichenbacher | Oracle de bourrage sur le chiffrement RSA (PKCS#1 v1.5) | Implémentations de déchiffrement RSA |
| 2006 | Daniel Bleichenbacher | Vérification laxiste de signature avec exposant public faible | Signatures RSA PKCS#1 v1.5 mal vérifiées |
| 2007 | Joux, Naccache, Thomé | Algorithme théorique de forge par oracle brut de type SNFS | Interfaces RSA sans bourrage (théorique) |
| 2026 | Shea, Haller, Suhl, Heninger, Thomé | Première démonstration pratique à grande échelle de l’algorithme de 2007 | RSA-1024 avec oracle de signature brute |
Quels systèmes sont réellement exposés en Europe
La bonne nouvelle, et il faut le dire clairement, c’est que l’immense majorité des sites web, des API et des applications d’entreprise ne sont pas directement exposés. TLS 1.3 impose l’usage de schémas de signature comme RSA-PSS pour l’authentification RSA et n’utilise jamais l’opération brute pour signer un certificat ou un message applicatif. TLS 1.2, dans ses déploiements courants, utilise également un encodage PKCS#1 v1.5 correctement structuré, distinct de l’oracle brut visé par l’attaque.
Les systèmes à surveiller de près sont plus spécifiques. On y trouve les modules matériels de sécurité (HSM) et cartes à puce qui exposent, pour des raisons d’interopérabilité historique, un mécanisme RSA brut de type CKM_RSA_X_509 dans leur implémentation PKCS#11. On y trouve aussi les systèmes de signature aveugle utilisés dans certains dispositifs de monnaie électronique, de vote électronique ou de titres de transport anonymes, ainsi que les dispositifs de paiement ou de contrôle d’accès legacy qui n’ont jamais migré vers un bourrage standardisé. Les banques françaises, les opérateurs de cartes bancaires et les fournisseurs de solutions de signature électronique qualifiées eIDAS ont un intérêt direct à vérifier la configuration exacte de leurs HSM avant la fin de l’année.
Comparatif des schémas de signature face au risque d’oracle brut
Tous les schémas de signature ne se valent pas face à ce type de risque. Le tableau ci-dessous compare les principaux mécanismes utilisés aujourd’hui, leur taille de signature standard et leur exposition à une attaque par oracle brut.
| Schéma de signature | Taille de signature (module/courbe usuel) | Bourrage / structure | Exposition au risque d’oracle brut |
|---|---|---|---|
| RSA brut (textbook) | 128 à 512 octets selon la clé | Aucun | Élevée, cible directe de l’attaque 2026 |
| RSASSA-PKCS1-v1_5 | 128 à 512 octets | Encodage fixe avec en-tête ASN.1 | Faible si la vérification est complète |
| RSA-PSS | 128 à 512 octets | Encodage randomisé (salt) | Très faible, non concerné par l’attaque |
| ECDSA P-256 | 64 octets | Structure de courbe elliptique | Non concerné, mécanisme différent |
| Ed25519 | 64 octets | Signature déterministe EdDSA | Non concerné, mécanisme différent |
| ML-DSA-65 (post-quantique) | ~3 309 octets | Fondé sur les réseaux euclidiens | Non concerné, famille algorithmique distincte |
Cette comparaison illustre un point souvent oublié dans le débat sur la migration post-quantique : le choix de l’algorithme ne suffit pas, l’implémentation et l’interface d’exposition comptent tout autant. Une clé RSA-4096 mal exposée via une interface brute peut s’avérer plus fragile en pratique qu’une clé ECDSA P-256 correctement implémentée, même si sa taille théorique suggère le contraire.
Réaction du NIST, de l’ANSSI et de l’ENISA
Le NIST maintient depuis plusieurs années une correspondance de sécurité qui situe RSA-2048 autour de 112 bits, RSA-3072 autour de 128 bits et RSA-15360 autour de 256 bits. Cette grille reste la référence utilisée par les auditeurs, mais l’agence rappelle depuis 2024 que la priorité stratégique va à la migration vers la cryptographie post-quantique plutôt qu’au simple allongement des clés RSA classiques.
En France, l’ANSSI considère de longue date RSA-2048 comme un minimum pour les usages courants et recommande RSA-3072 pour les besoins de protection prolongée. L’agence prépare par ailleurs, pour les certifications et qualifications délivrées à partir de 2027, des exigences intégrant des mécanismes résistants aux ordinateurs quantiques. Rien n’indique à ce stade que l’ANSSI ait revu sa doctrine sur la taille des clés RSA classiques en réaction directe à ce papier de recherche, mais l’agence insiste depuis plusieurs mois sur l’audit des interfaces cryptographiques, pas seulement sur la taille des clés.
L’ENISA, l’agence de l’Union européenne pour la cybersécurité, aligne généralement ses recommandations sur une approche fondée sur le risque, traitant RSA-2048 comme une base établie pour de nombreux usages actuels tout en encourageant des paramètres plus robustes et une préparation à la transition post-quantique. Le message commun des trois agences reste cohérent : ce résultat de recherche ne rend pas RSA-2048 obsolète du jour au lendemain, mais il renforce l’argument selon lequel augmenter la taille d’une clé ne corrige pas un défaut de conception d’interface.
Impact sur le marché de la certification et des HSM en Europe
Pour les fabricants de modules matériels de sécurité et les prestataires de services de confiance qualifiés eIDAS, cette publication tombe à un moment déjà chargé. Les entreprises du secteur sont déjà mobilisées par la préparation de la cryptographie post-quantique, avec des échéances de certification évoluant à partir de 2027. L’ajout d’un audit spécifique des mécanismes RSA bruts dans les configurations PKCS#11 représente un travail supplémentaire, mais généralement circonscrit : il s’agit de vérifier des paramètres de configuration existants plutôt que de remplacer une infrastructure entière.
Les intégrateurs de solutions de signature électronique, de systèmes de vote et de titres de transport dématérialisés en Europe devront documenter, pour leurs clients et leurs auditeurs, que leurs implémentations n’exposent pas d’opération RSA brute à des tiers non fiables. Ce type de vérification s’inscrit dans le mouvement plus large de durcissement réglementaire porté par le règlement européen sur la cyber-résilience (Cyber Resilience Act) et par les obligations de signalement rapide des vulnérabilités cryptographiques qu’il impose désormais aux fabricants de produits numériques.
Mitigations concrètes pour les équipes techniques
Les mesures correctrices recommandées par la communauté cryptographique sont d’ordre architectural plus que cryptographique. Voici les actions prioritaires pour toute équipe utilisant du RSA sur des dispositifs matériels ou des bibliothèques bas niveau.
- Désactiver les mécanismes RSA bruts (type CKM_RSA_X_509) dans les configurations PKCS#11, sauf besoin documenté et justifié
- Migrer les nouvelles signatures vers RSA-PSS plutôt que PKCS#1 v1.5
- Vérifier intégralement l’encodage des signatures PKCS#1 v1.5 existantes, y compris l’identifiant d’algorithme de hachage et les octets de bourrage
- Séparer strictement les rôles de signature et de déchiffrement sur chaque clé
- Auditer et limiter le débit des appels autorisés vers toute interface de signature exposée
- Remplacer les protocoles de signature aveugle artisanaux par des constructions standardisées et éprouvées
- Planifier, quand c’est possible, une migration vers des signatures à courbe elliptique ou post-quantiques pour les nouveaux déploiements
Aucune de ces mesures ne nécessite de casser la compatibilité existante du jour au lendemain. L’enjeu est de cartographier précisément où et comment chaque clé RSA est utilisée, un exercice que beaucoup d’organisations reportent depuis des années faute de temps ou de visibilité sur leur parc cryptographique.
Ce que cela change (et ne change pas) pour la cryptographie post-quantique
Il est tentant de relier ce résultat au débat plus large sur la transition post-quantique, mais les deux sujets restent distincts. L’attaque de 2026 est un calcul classique, exécuté sur du matériel conventionnel, qui ne doit rien à un ordinateur quantique. Elle ne modifie en rien le calendrier des menaces liées à l’algorithme de Shor, qui exigerait une machine quantique tolérante aux fautes d’une envergure qu’aucun système actuel n’atteint.
Le lien indirect tient plutôt à la méthode de travail qu’elle impose : cartographier les usages de RSA, identifier les interfaces à risque et documenter les dépendances cryptographiques. C’est exactement le travail préalable que la migration post-quantique impose déjà aux organisations. Les entreprises qui ont commencé leur inventaire cryptographique dans le cadre de leur préparation post-quantique se retrouvent, de fait, mieux armées pour évaluer leur exposition à cette nouvelle attaque par oracle.
Prédictions : où va la sécurité des signatures RSA d’ici 2030
Sur la base des tendances observées depuis la publication du 20 septembre 2026, plusieurs évolutions semblent probables pour les prochaines années.
- Les fabricants de HSM vont accélérer la dépréciation par défaut des mécanismes RSA bruts dans leurs firmwares, en les désactivant sauf activation explicite et documentée par le client.
- Les référentiels de certification européens, y compris les critères communs et les profils de protection utilisés en France, devraient intégrer d’ici 2027 un test spécifique visant à détecter l’exposition d’opérations RSA sans bourrage.
- Les protocoles de signature aveugle historiques vont progressivement migrer vers des constructions standardisées, poussées par les audits de conformité plutôt que par la seule pression académique.
- D’autres équipes de recherche vont vraisemblablement tenter d’étendre l’attaque à des modules RSA-2048, même si l’écart de coût de calcul reste considérable à court terme.
- La pression réglementaire, portée notamment par le Cyber Resilience Act et son obligation de signalement des failles cryptographiques sous 24 heures, va accélérer la publication de correctifs de configuration chez les éditeurs de bibliothèques PKCS#11 et de cartes à puce.
Pourquoi cette recherche compte malgré son coût de calcul élevé
On pourrait minimiser l’importance de cette découverte en pointant le coût élevé de sa mise en œuvre : 1 380 années-cœur et cinq mois de calcul restent hors de portée d’un attaquant isolé. Mais l’histoire de la cryptographie montre que les coûts de calcul chutent régulièrement, parfois de plusieurs ordres de grandeur en quelques années, à mesure que les algorithmes sont optimisés et que le matériel progresse. L’attaque de Bleichenbacher contre le chiffrement RSA, publiée en 1998, semblait elle aussi limitée à l’époque avant de devenir un classique du pentest quinze ans plus tard, ressuscitée en 2016 sous le nom de DROWN puis déclinée dans de nombreuses variantes jusqu’en 2026, avec des CVE encore publiées cette année sur des bibliothèques Python.
L’autre raison de prendre ce résultat au sérieux tient à sa nature structurelle. Il ne s’agit pas d’un bug ponctuel corrigible par une mise à jour, mais de la démonstration qu’une classe entière d’interfaces, l’oracle RSA brut, porte un défaut de conception fondamental. Ce type de résultat change durablement les recommandations de configuration, bien après que le calcul initial soit devenu anecdotique face aux progrès du matériel.
Foire aux questions sur l’attaque RSA par oracle de 2026
Cette attaque casse-t-elle RSA-2048 dès maintenant ?
Non. La démonstration publique porte sur RSA-1024 avec un accès prolongé à un oracle de signature brute. RSA-2048 reste hors de portée pratique de cette méthode à ce stade, sauf configuration exposant elle aussi une interface non protégée.
Mon site web utilisant HTTPS et TLS 1.3 est-il concerné ?
Dans l’immense majorité des cas, non. TLS 1.3 impose des schémas de signature avec bourrage structuré comme RSA-PSS, qui ne sont pas exposés à ce type d’attaque.
Qu’est-ce qu’un oracle de signature RSA brute concrètement ?
C’est une interface, souvent matérielle (HSM, carte à puce, module PKCS#11), qui accepte de calculer m^d mod N sur une valeur choisie par l’appelant sans appliquer ni vérifier de bourrage cryptographique.
Faut-il changer immédiatement de taille de clé RSA ?
Augmenter la taille de la clé ne corrige pas le défaut. La priorité est de désactiver ou de restreindre l’accès aux mécanismes RSA bruts, puis d’évaluer une migration vers RSA-PSS ou des signatures à courbe elliptique.
Quel est le lien avec la cryptographie post-quantique ?
Aucun lien direct. Cette attaque repose sur du calcul classique, pas sur un ordinateur quantique. Elle partage seulement la même recommandation de fond : cartographier ses dépendances cryptographiques avant d’agir.
Les cartes bancaires et les cartes à puce françaises sont-elles à risque ?
Les dispositifs conformes aux standards actuels de paiement utilisent des mécanismes de signature bourrés et normalisés. Le risque concerne surtout les déploiements anciens ou mal configurés exposant une opération RSA brute pour des raisons d’interopérabilité historique.
Où puis-je consulter le papier de recherche original ?
L’article complet, référencé IACR ePrint 2026/2131, est disponible en libre accès sur le site de l’IACR ePrint Archive.
Quelles bibliothèques cryptographiques sont concernées ?
Le papier ne vise pas une bibliothèque logicielle en particulier, mais toute interface, matérielle ou logicielle, qui expose une opération RSA sans bourrage à un appelant non fiable. Les équipes doivent auditer leurs propres intégrations PKCS#11 plutôt que d’attendre un correctif générique.
