Le 6 novembre 2026, Google DeepMind a annoncé un calcul achevé sur RSA-1024 : ses agents ont calculé une racine RSA à l’aide d’un oracle à entrées choisies. Un second travail analyse théoriquement la factorisation de lots de nombres de même taille. Les articles ne rapportent pas la factorisation d’un module individuel et indiquent que ces résultats ne menacent pas les modules RSA de 2 048 bits ou plus.
Le calcul achevé portait sur un modèle d’oracle précis
Un oracle RSA répond à des requêtes de calcul RSA. Dans l’expérience décrite par Google DeepMind, il acceptait des entrées choisies directement par les agents. Ceux-ci ont effectué 4 055 916 065 requêtes avant que la cible soit tirée au sort ; aucune requête à l’oracle n’a ensuite été faite pendant le calcul en ligne. Le modèle suppose un accès direct, même temporaire, à cette fonction de signature ou de déchiffrement. Les systèmes qui calculent le hachage à l’intérieur de l’appareil ne relèvent pas des modèles d’oracle étudiés dans l’article de Google DeepMind sur le calcul RSA-1024.
Le calcul a produit une racine RSA, sans factoriser le module ni extraire la clé privée. Cette distinction compte : le résultat porte sur une opération réalisée avec un oracle et des entrées choisies, pas sur la factorisation d’une clé RSA quelconque.
Le gain de 3,5 fois concerne l’exécution, pas l’algorithme
Pour calculer la première racine sur cette instance de 1 024 bits, DeepMind rapporte 391 années-cœur CPU, contre 1 380 dans le calcul antérieur. Les deux calculs utilisaient le même algorithme, le même module, les mêmes polynômes et les mêmes bornes de base de facteurs. Le rapport de DeepMind attribue l’écart de 3,5 fois à l’implémentation et à l’exécution, pas à une amélioration de l’algorithme. Son total CPU exclut le travail effectué sur GPU. Le chiffre antérieur est rapporté dans le préprint original d’IACR.
Pour interpréter un résultat de cryptanalyse, regardez ce qui a été exécuté et ce qui relève d’une estimation : ici, les deux types de résultats coexistent, mais ne mesurent pas la même chose.
L’article décrit aussi une méthode distincte pour un oracle affine à fenêtre courte. Son coût asymptotique heuristique est exprimé par les exposants 1,5803, contre 1,8171 pour la méthode précédente. Cette analyse n’a pas été exécutée à taille cryptographique : ces exposants ne sont donc pas des durées d’attaque mesurées.
La « fan factory » estime le coût d’attaques par lots
Un autre article étudie une méthode qui partage une partie du pré-calcul entre plusieurs entiers de même taille. Pour des cibles de 1 024 bits, avec un pré-calcul équivalant à une exécution GNFS, l’analyse estime que chaque cible supplémentaire coûterait environ 1/58,5 d’une exécution GNFS, soit environ 30,2 fois moins par cible que MNFS. En comptant le pré-calcul, le coût total estimé devient inférieur à celui de MNFS à partir de trois cibles.
Ces chiffres sont des estimations heuristiques de premier ordre dans l’analyse théorique de la fan factory, pas des temps de calcul observés. L’article ne rapporte pas d’implémentation de cette méthode.
Les agents ont travaillé avec des validations humaines
Le papier sur le calcul RSA décrit deux agents : un superviseur, chargé de coordonner la conception, les budgets et les contrôles, et un exécutant, qui a écrit et testé le code, lancé les calculs et diagnostiqué les échecs. Un chercheur humain a choisi l’objectif et approuvé des étapes clés. Selon les auteurs, il n’a écrit aucun code, lancé aucun travail ni diagnostiqué de panne. Le papier fait état d’environ 20 messages humains et de 336 expériences distribuées.
Les deux articles de Google DeepMind indiquent que leurs résultats ne menacent pas les modules RSA de 2 048 bits ou plus, dans le cadre des méthodes étudiées.
