IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Des chercheurs publient une nouvelle méthode pour casser les signatures RSA de 1024 bits,
Sa particularité réside dans le contournement de l'approche classique consistant à factoriser un entier géant

Le , par Patrick Ruiz

112PARTAGES

11  0 
Une équipe de chercheurs de l'Université de Californie à San Diego (UCSD) et de l'Inria Nancy/Université de Lorraine a publié au cours du mois qui tire à son terme une avancée majeure en cryptographie. Pour la première fois, ils ont démontré une méthode permettant de falsifier des signatures RSA de 1024 bits sans avoir à factoriser la clé publique (c'est-à-dire sans chercher les deux nombres premiers d'origine). Cette découverte, baptisée eNFS, fait l'effet d'une surprise dans le milieu de la cybersécurité, car elle fait s'effondrer le coût de calcul théorique requis pour briser cette taille de clé historique.

eNFS : Comment ca marche ?

Le principe fondamental de RSA repose sur l'hypothèse que casser une clé ou falsifier une signature revient à résoudre le problème mathématique de la factorisation d'un entier géant. Cette nouvelle méthode prouve le contraire.

Inspirée de travaux théoriques de Joux, Naccache et Thomé datant de 2007, la méthode eNFS appartient à la famille du Crible généralisé sur les corps de nombres (GNFS / SNFS). Elle permet de ramener le temps nécessaire pour falsifier une signature à une complexité proche du Crible spécial (SNFS), d'ordinaire réservé à des nombres ayant une structure mathématique très rare et faible.

Au lieu de chercher à diviser la clé, l'algorithme convertit un accès temporaire à un "oracle" de signature ou de déchiffrement brut (non masqué ou utilisant des signatures aveugles, appelées blind signatures) en une capacité permanente à contrefaire n'importe quelle signature de manière déconnectée. L'attaque ne récupère jamais les facteurs premiers ni la clé privée elle-même.

L'attaque nécessite qu'un attaquant ait un accès temporaire (via une API ou un service réseau) à un service de signature ou de déchiffrement RSA brut ou textuel, c'est-à-dire qui n'utilise pas de masquage de sécurité ou de padding déterministe modern.

Durant cette phase d'accès, l'attaquant effectue un nombre infime de requêtes à cet oracle (seulement 232 requêtes lors de l'expérience). Une fois ces données récoltées, l'accès à l'oracle peut être coupé : l'attaquant dispose de suffisamment d'éléments pour falsifier n'importe quelle signature de cette clé totalement hors-ligne.

Factoriser une clé RSA de 1 024 bits de manière classique demande entre 500 000 et 1 000 000 d'années-cœur CPU. La méthode eNFS a permis de finaliser l'attaque en seulement 1 380 années-cœur CPU pour la phase de précalcul. Une fois ce précalcul fait, générer de nouvelles signatures ne prend plus que 180 années-cœur CPU.

L'un des aspects les plus marquants de cette avancée est qu'elle n'a pas nécessité d'ordinateur quantique ni de supercalculateur étatique, invalidant la croyance que seules des nations ou des intelligences artificielles massives pouvaient menacer le RSA à court terme.

L'un des aspects les plus marquants de cette avancée est qu'elle n'a pas nécessité d'ordinateur quantique ni de supercalculateur étatique, invalidant la croyance que seules des nations ou des IA massives pouvaient menacer le RSA à court terme.

Le calcul a nécessité 1380 années-cœur CPU. La tâche a été accomplie en seulement 5 mois. Elle s’est appuyée sur un classique cluster de calcul universitaire (l'équipe a utilisé un véritable module de sécurité matériel (HSM) commercial comme oracle pour générer les signatures, démontrant qu'un composant censé être ultra-sécurisé pouvait être usurpé).

Les chercheurs mettent l’emphase sur le fait que leur attaque n'a utilisé aucun processeur graphique, ni aucune accélération par intelligence artificielle.

L'impact direct sur la navigation quotidienne des utilisateurs d'Internet reste pour le moment maîtrisé, mais appelle à une vigilance immédiate

Les clés RSA de 1024 bits étaient déjà officiellement déconseillées par les standards du web (comme le NIST) depuis des années au profit du RSA-2048. Cette démonstration signe l'arrêt de mort définitif de la version 1024 bits, qui devient totalement vulnérable aux forgeries de signatures.

Les implémentations modernes et correctement configurées du protocole TLS n'utilisent pas le type d'oracle brut ou de signatures aveugles vulnérables à cette attaque spécifique. Le trafic web général chiffré en RSA-2048 ou 4096 reste pour l'instant hors de portée d'une exécution à bas coût, même si leur marge de sécurité théorique vient de chuter massivement.


Pour le secteur des technologies de l'information, cette annonce agit comme un accélérateur forcé vers de nouveaux paradigmes

Bien qu'il s'agisse ici d'une attaque classique, la perte de confiance envers la robustesse historique du RSA pousse l'industrie à adopter beaucoup plus vite les nouveaux standards du NIST (tels que ML-KEM pour l'échange de clés et ML-DSA pour les signatures électroniques).

Les entreprises utilisant encore des systèmes hérités, des micrologiciels industriels anciens (IoT), ou des systèmes bancaires figés sur des clés RSA 1024 ou des schémas de signatures obsolètes doivent urgemment cartographier et mettre à jour leurs infrastructures sous peine de voir leurs jetons d'authentification falsifiés.

Les experts en cybersécurité doivent désormais évaluer la robustesse des systèmes non pas uniquement sur la capacité théorique à factoriser des entiers, mais sur la manière dont les services de cryptographie (oracles) traitent et exposent les signatures brutes.

Et vous ?

Comment accueillez-vous cette nouvelle ? Quel impact entrevoyez-vous sur la filière des technologies de l’information ?

Voir aussi :

Google présente son modèle de menace pour la cryptographie post-quantique, pour prévenir les attaques futures de "stocker maintenant-déchiffrer plus tard"

Le monde n'est absolument pas prêt pour contrer l'apocalypse des cyberattaques quantiques, seules 23% des organisations ont commencé à travailler sur la cryptographie post-quantique (PQC)

La principale nouveauté de Windows 11 est le chiffrement post-quantique, pour la première fois, de nouveaux algorithmes à sécurité quantique peuvent être utilisés à l'aide des API Windows standard
Vous avez lu gratuitement 3 256 articles depuis plus d'un an.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer à vous proposer des publications.

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de 10_GOTO_10
Membre expérimenté https://www.developpez.com
Le 28/09/2026 à 22:54
Soit je n'ai pas compris cette actualité, soit je ne comprends plus rien à la cryptographie. Mais pour moi, "falsifier n'importe quelle signature" et déchiffrer un message RSA, c'est exactement la même opération : ça consiste à transformer un nombre A en un nombre B avec la clé privée. La seule différence, c'est que dans la cas d'une signature, A est un message en clair et n'importe qui peut transformer B en A avec la clé publique et donc vérifier la signature ; Dans le cas d'un message chiffré, B est le message en clair qui a été auparavant transformé en A avec la clé publique. Mais, message en clair ou pas, l'algorithme il s'en fout. Pour lui A et B ne sont que des nombres. Il transforme A en B point barre. Il suffirait de "signer" un message chiffré pour retrouver le message en clair. Donc, pour résumer, ce que dirait la news, c'est qu'on vient de casser le codage RSA de moins de 1024 bits (moyennant les 232 requêtes au service de signature).
Mais ce n'est pas ce qui est dit. On ne parle que de "falsification de signature". Il y a donc fatalement un truc que je n'ai pas compris. Mais je ne sais pas quoi.
3  0 
Avatar de Anaxode
Candidat au Club https://www.developpez.com
Le 30/09/2026 à 14:02
Le plus troublant pour moi c'est l'année-coeur CPU. Un intel 386 et un Intel I9 Ultra 285K ne produisent pas du tout la même quantité de travail dans un même laps de temps.
Les flops auraient été plus intéressant. Ca représente un vrai truc.
1  0 
Avatar de 10_GOTO_10
Membre expérimenté https://www.developpez.com
Le 01/10/2026 à 0:06
Citation Envoyé par Artemus24 Voir le message
6) l'émetteur chiffrer la signature du message qu'il va envoyer avec sa propre clef privée.
Pour vérifier la signature du message reçu, le récepteur utilise la clef privée de l'émetteur.
La clé publique de l'émetteur, je suppose. Le récepteur ne connait pas la clé privée de l'émetteur.

Citation Envoyé par Artemus24 Voir le message
Pour répondre à 10_GOTO_10, on ne déchiffre pas la signature mais elle doit être validée par la clef publique donnée par l'émetteur au récepteur.
Là, c'est jouer sur les mots. La "validation" consiste à faire une transformation par la clé publique de l'émetteur, donc exactement ce que ferait n'importe qui qui voudrait lui envoyer un message (voir § 4), en d'autres termes un chiffrement. Sauf qu'ici on ne parle pas de la "validation" mais de la "falsification", c'est à dire de la production d'une signature. En d'autres termes, selon moi, un décryptage (déchiffrement sans connaitre la clé).

Citation Envoyé par Artemus24 Voir le message
Le déchiffrement du message reçu se fait à l'aide de la clef privée du récepteur. Ce sont deux procédures différents !
Non, l'opération est la même. Seul l'ordre d'utilisation des clés est différent. En fait, les termes de "chiffrement" et "déchiffrement" sont ambigus : la même opération de A vers B peut ressembler à un chiffrement si A est un message clair ou à un déchiffrement si B est clair. Et c'est cette ambiguïté qui fait croire qu'une signature est une procédure différente d'un envoi de message secret, puisqu'on commence à y appliquer une clé privée "validée" ensuite par une clé publique. Tandis qu'un message on lui applique d'abord une clé publique et il est ensuite "déchiffré" par une clé privée. Mais du point de vue mathématique, on a juste deux fonctions f et g, f qui transforme A en B de façon pratiquement irréversible et g qui transforme B en A. f ou g sont appelées clés privées ou publiques selon qui en a connaissance.
1  0 
Avatar de 10_GOTO_10
Membre expérimenté https://www.developpez.com
Le 02/10/2026 à 15:58
Citation Envoyé par Artemus24 Voir le message
l'attaquant ne peut rien faire car il lui faut la clef privé du destinataire pour déchiffrer le message et accéder à la signature. Donc sans clef privée, il ne peut rien faire.

Où ai-je commis mon erreur de raisonnement ?
L'attaquant n'a pas à déchiffrer le message. On peut supposer que s'il cherche à falsifier une signature, c'est pour envoyer un faux message qu'il a écrit lui-même, et qu'il aurait ensuite chiffré avec la clé publique du récepteur. Je ne vois pas l'intérêt de faire une fausse signature d'un vrai message.
1  0 
Avatar de Artemus24
Expert éminent sénior https://www.developpez.com
Le 01/10/2026 à 17:27
J'ai repris mon message #4 afin de corriger l'erreur du paragraphe 6). Bien vu ! Désolé de mettre trompé.

La vérification de la signature est la même technique que celle des mots de passe. C'est la technique du hachage qui se fait à l'aide des fonctions SHA-256, SHA-384, SHA-512 ... Lors de la saisie du mot de passe, celui-ci est hacher, puis sera comparé au mot de passe stocké (haché aussi) dans la base de données. A aucun moment, ce mot de passe est en clair.

Citation Envoyé par 10_goto_10
Là, c'est jouer sur les mots.
Dans ce cas, il faut nommer chiffrement pour le message et hachage pour la signature.

Citation Envoyé par 10_goto_10
Non, l'opération est la même.
Mais non ce n'est pas la même opération car celle du message est un chiffrement / déchiffrement et celle de la signature est un hachage puis ensuite par comparaison.

Il y a quelque chose que je ne comprends pas avec cette signature. Si elle est exposée en clair dans le corps du message envoyé au destinataire, l'attaquant connaissant la clef publique du destinataire peut chiffrer le message et par l'une des fonctions de hachage, créer la bonne signature. Il est inutile de faire tout ce qui est exposé dans ce sujet.

Si maintenant, comme je l'ai supposé, la signature fait partie intégrante du corps du message qui sont tous les deux chiffrés en même temps, l'attaquant ne peut rien faire car il lui faut la clef privé du destinataire pour déchiffrer le message et accéder à la signature. Donc sans clef privée, il ne peut rien faire.

Où ai-je commis mon erreur de raisonnement ?
0  0 
Avatar de Artemus24
Expert éminent sénior https://www.developpez.com
Le 30/09/2026 à 14:43
Salut à tous.

Il faut bien faire les distinctions du contexte pour comprendre comment se font les échanges et les chiffrements:

1) l'émetteur possède sa propre clef privée.
Le récepteur possède aussi sa propre privée.
Sauf qu'elles sont différentes et ne sont pas diffusées.

2) l'émetteur possède sa propre clef publique.
Le récepteur possède aussi sa propre publique.
Sauf qu'elles sont différentes aussi et sont diffusées.

3) En résumé, l'émetteur possède la clef publique du récepteur et vice-versa.
Soit pour chacun :
la clef privé qui leur est propre et non diffusée.
la clef publique de leur clef privée.
la clef publique de l'autre intervenant. C'est là que l'échange de la clef publique se fait.

4) L'émetteur chiffre le message avec la clef publique du récepteur.
Le récepteur déchiffre le message de l'émetteur avec sa propre clef privée.
Et vice-versa car le procédé est symétrique.

5) Comme les clefs publiques sont accessibles part tout le monde, n'importe qui peut envoyer un message.
C'est cet inconvénient qui permet de ne pas garantir l'identification du récepteur.
D'où l'introduction de la signature pour l'identification.

6) l'émetteur crée l'empreinte du message qui devient la signature.
Il chiffre message + signature avec sa propre clef privée avant de l'envoyer au destinataire.
Pour vérifier la signature du message reçu, le récepteur utilise la clef privée publique de l'émetteur pour effectuer ce déchiffrement.
Puis effectue à nouveau le hachage du message afin de le comparer à la signature reçu.

7) Autrement dit :
la clef publique du récepteur que possède l'émetteur, sert à chiffrer le message à destination du récepteur.
la clef privée de l'émetteur sert à chiffrer la signature à destination du récepteur.

J'espère que le contexte est suffisamment clair pour bien comprendre comment ce font les chiffrements.

Pour répondre à 10_GOTO_10, on ne déchiffre pas la signature mais elle doit être validée par la clef publique donnée par l'émetteur au récepteur.
Le déchiffrement du message reçu se fait à l'aide de la clef privée du récepteur. Ce sont deux procédures différents !
Toute la difficulté est de produire une signature valide auprès du récepteur.

Le problème : Le pirate veut envoyer un faux message en se faisant passer pour le véritable émetteur.
Mais il peut chiffrer son faux message avec la clef publique du récepteur car celle-ci est diffusée sur le net.
Sauf qu'il n'est pas en mesure de produire une signature valide correspondant à son faux message.
Car comme nous venons de le voir, l'attaquant ne possède pas la clé privée de l'émetteur.
La validation du message envoyée se fait à l'aide la signature.
La signature doit être validée par la clef publique de l'émetteur que possède le récepteur.
Je pense que jusque là, la nature du problème est clair.

En quoi consiste cette falsification ?
Le fameux Oracle est un système qui produit des signatures qui seront validées par le récepteur.
L'attaquant va récupérer ces signatures légitimes.
Il y a plusieurs points qui ne sont pas du tout clair dans cet article.

a) l'attaquant indique avoir un accès temporaire à un service de signature. Est-ce du piratage ?
Si oui, pourquoi ne pas récupérer tout simplement la clef privée de l'émetteur ?

b) on ne comprend pas en quoi consiste les accès à ce service dont l'attaquant va se servir.
Est-ce une API ?

c) Que demande l'attaquant à ce service ?
Si ce service signe tout simplement les messages à destination du récepteur, autant lui fournir le faux message.

d) Comment l'attaquant récupère ces signatures dont il va se servir par la suite ?
Si c'est un serveur de messagerie, il faut écouter la ligne et capturer les messages envoyées.

e) L'attaque se fait sans que l'émetteur ne s'aperçoive de rien.
Si un système est compromis, il faut changer la clef privée.
Et fournir la nouvelle clef publique au récepteur.
Ce qui rend dans ce cas toute cette falsification inutile.

f) en quoi consiste ces calculs hors ligne ? Et pour obtenir quoi ?

g) Il est pourtant dit qu'il n'y a pas de factorisation.
Comment est produit la nouvelle signature à partir du faux message ?

h) L'article sous-entend "signatures RSA de 1024 bits".
Tout laisse croire que tout RSA-1024 est concerné, ce qui est faux.
Mais il est question du RSA brut.

Rien n'est clair dans cet article qui est surtout un effet d'annonce.
La validité d'un message n'est en principe que de l'ordre de quelques heures.
S'il faut au mieux quelques jours pour produire un faux message valide, ce stratagème ne sert à rien.
Et si le RSA-1024 est corrompu, autant passer au RSA-4096.
0  1