Google affirmait avoir produit la preuve mathématique la plus économe jamais publiée pour casser une clé de cryptographie à courbes elliptiques par cryptanalyse quantique. Le 17 avril 2026, l’équipe de recherche Trail of Bits a démonté cette affirmation en quatre heures de calcul, sans toucher à un seul qubit réel. Elle a exploité deux failles logicielles dans le code Rust du prouveur de Google pour forger une preuve à divulgation nulle de connaissance (ZKP) qui affichait de meilleurs chiffres sur les trois métriques clés : 8,3 millions d’opérations contre 17 millions, 1 164 qubits contre 1 175, et surtout zéro porte de Toffoli contre 2,7 millions. Six mois plus tard, l’affaire refait surface dans les cercles spécialisés, relancée en septembre 2026 par une analyse de postquantum.com qui en fait un cas d’école du “problème du vérifieur” dans les systèmes de preuve zero-knowledge. Ce dossier explique ce qui s’est vraiment passé, pourquoi cela dépasse le cas Google, et ce que cela change pour toute entreprise qui s’appuie sur une preuve cryptographique plutôt que sur un audit humain.
Ce que Google avait réellement revendiqué
Le point de départ n’est pas anodin. Google avait publié une preuve à divulgation nulle de connaissance censée démontrer qu’un circuit quantique pouvait exécuter une cryptanalyse par courbes elliptiques (le type d’attaque qui menacerait à terme Bitcoin, Ethereum et une bonne partie du TLS actuel) avec un nombre d’opérations et un nombre de qubits donnés, sans révéler le détail exact du circuit. L’entreprise avançait environ 17 millions d’opérations au total, avec deux configurations phares : une combinant 1 425 qubits et 2,1 millions de portes de Toffoli, l’autre combinant 1 175 qubits et 2,7 millions de portes de Toffoli. Pour générer cette preuve, Google a fait tourner un simulateur de circuit quantique écrit en Rust comme programme invité à l’intérieur d’une zkVM, une machine virtuelle à divulgation nulle de connaissance nommée SP1, développée par Succinct Labs. La preuve elle-même était produite avec le système Groth16, un standard courant dans l’écosystème zk-SNARK depuis 2016.
L’idée derrière une zkVM comme SP1 est simple sur le papier : on écrit un programme normal, on le fait exécuter dans la machine virtuelle, et celle-ci génère automatiquement une preuve cryptographique que ce programme a bien tourné avec telle entrée et produit telle sortie, sans qu’un tiers ait besoin de rejouer le calcul. Pour un résultat aussi sensible que la cryptanalyse quantique d’ECC, cette approche évite à Google de dévoiler l’intégralité de son circuit tout en offrant, en théorie, une garantie mathématique de véracité. C’est précisément cette garantie que Trail of Bits a mise en défaut.
Trail of Bits contre-attaque : une preuve forgée en quatre heures
Dans son billet publié le 17 avril 2026, Trail of Bits résume la démarche sans détour : “Notre résultat ne tient pas à une percée quantique, mais à l’exploitation de plusieurs vulnérabilités subtiles de sécurité mémoire et de logique dans le code du prouveur Rust de Google”, écrit l’équipe (Trail of Bits, source). Concrètement, les chercheurs n’ont pas inventé un algorithme quantique plus rapide. Ils ont construit un circuit qui exécute correctement l’addition de points sur courbe elliptique, l’opération de base requise, puis ont exploité deux bugs du simulateur pour que la zkVM enregistre des chiffres de ressources bien inférieurs à la réalité du calcul effectué.
Le résultat forgé affiche 8,3 millions d’opérations, 1 164 qubits et zéro porte de Toffoli. Sur le papier, cela ressemble à une attaque de cryptanalyse quantique bien plus efficace que celle de Google. En réalité, ce zéro absolu de portes de Toffoli est le signal qui trahit la manipulation : aucun circuit quantique connu capable de réaliser une multiplication scalaire sur courbe elliptique ne peut fonctionner sans porte de Toffoli, puisque cette porte assure les opérations logiques réversibles nécessaires à l’arithmétique modulaire. Un chiffre à zéro n’est donc pas une prouesse, c’est la preuve que le compteur a été contourné plutôt que vaincu.
Faille numéro 1 : le compteur de portes de Toffoli neutralisé
La première vulnérabilité touche la désérialisation des données dans le simulateur. Le code Rust de Google faisait confiance à des données contrôlées par l’attaquant sans validation stricte du type énuméré (enum) reçu. En injectant une valeur hors des bornes attendues, Trail of Bits a pu faire dévier la logique de répartition générée par le compilateur Rust vers un chemin d’exécution qui effectue bien l’opération de porte, mais sans jamais incrémenter le compteur censé comptabiliser les portes de Toffoli utilisées. Le circuit travaille normalement, la comptabilité ment.
Voici, à titre d’illustration simplifiée, le type de schéma logique qui permet ce contournement dans un simulateur de portes quantiques mal validé (ce n’est pas le code source exact de Google, mais une représentation pédagogique du mécanisme décrit par Trail of Bits) :
// Schéma simplifié du contournement décrit par Trail of Bits
match gate_type_from_untrusted_input(raw_enum_value) {
GateType::Toffoli => {
apply_toffoli(&mut state, q0, q1, q2);
toffoli_counter += 1; // chemin normal, comptabilisé
}
GateType::OutOfRangeVariant => {
// valeur hors énumération valide : le dispatch Rust
// exécute quand même une porte réversible équivalente
// SANS jamais toucher toffoli_counter
apply_equivalent_gate(&mut state, q0, q1, q2);
}
}Ce type de bug illustre un problème récurrent en sécurité logicielle : la validation d’entrée insuffisante sur un type énuméré. Ce n’est pas une faiblesse propre à la cryptographie quantique, c’est une classe de vulnérabilité que l’on retrouve dans les parseurs, les désérialiseurs JSON et les moteurs de règles depuis des décennies. Ce qui change ici, c’est le contexte : une preuve mathématique censée être infalsifiable repose in fine sur du code classique, avec ses bugs classiques.
Faille numéro 2 : aliasing de registres et arithmétique optimisée
La seconde vulnérabilité relève de la sécurité mémoire. Le simulateur utilisait des opérations Rust marquées unsafe pour réduire le coût d’exécution, une pratique courante quand la performance prime sur les garde-fous du compilateur. Trail of Bits a exploité une corruption mémoire issue de ces opérations non sécurisées pour manipuler l’état interne du simulateur via une technique d’aliasing de registres, en s’appuyant sur des méthodes de partage de registres proches de celles décrites par Proos et Zalka pour l’arithmétique elliptique quantique. Combinée à une version modifiée de l’algorithme d’Euclide étendu binaire, cette technique a permis de faire chuter le nombre de qubits nécessaires de 1 175 à 1 164, soit une économie de 113 qubits obtenue par optimisation légitime de l’arithmétique, distincte du contournement du compteur de Toffoli.
Le détail compte : Trail of Bits insiste sur le fait que la construction du circuit devait rester honnête sur l’opération réalisée, l’addition de points sur courbe elliptique. Les chercheurs n’ont pas triché sur la fonction calculée, seulement sur la manière dont le système comptabilisait les ressources consommées pour la calculer. C’est cette nuance qui rend l’affaire aussi dérangeante pour la communauté zkVM : le circuit fonctionne, la preuve vérifie, et pourtant le résultat rapporté est faux sur un point clé.
Les chiffres qui changent tout : Google contre Trail of Bits
Pour mesurer l’écart entre la revendication initiale de Google et la preuve forgée par Trail of Bits, le tableau ci-dessous reprend les métriques publiées par les deux parties.
| Métrique | Preuve originale de Google | Preuve forgée de Trail of Bits |
|---|---|---|
| Opérations totales | ≈ 17 000 000 | 8 300 000 |
| Qubits (configuration retenue) | 1 175 | 1 164 |
| Portes de Toffoli | 2 700 000 | 0 |
| Système de preuve | Groth16 sur zkVM SP1 | Groth16 sur zkVM SP1 |
| Temps de génération de la preuve | Non communiqué par Google | ≈ 4 heures |
| Nature de l’amélioration revendiquée | Cryptanalyse quantique ECC | Exploitation de bugs logiciels, aucune percée quantique |
Ce tableau résume à lui seul la démonstration de Trail of Bits : sur les trois métriques que Google mettait en avant, la preuve forgée gagne sur chacune, sans jamais faire tourner un ordinateur quantique. C’est la définition même d’une preuve de concept en sécurité offensive, appliquée cette fois à un domaine inhabituel, la validation de résultats scientifiques.
La réponse de Google et le correctif
Selon Trail of Bits, Google a corrigé le code vulnérable et régénéré ses preuves en l’espace de quelques jours après la divulgation. L’entreprise n’a pas revu à la baisse ses affirmations scientifiques sur la faisabilité de l’attaque de cryptanalyse quantique : Trail of Bits précise que les résultats scientifiques sous-jacents de Google restaient valides, le problème se situait dans la pile logicielle utilisée pour produire l’attestation de ressources, pas dans le circuit quantique lui-même. Aucun identifiant CVE public n’a été attribué à l’incident, qui a été traité comme une divulgation de vulnérabilité propre au projet plutôt que comme une faille listée dans les bases publiques.
Le code source de la preuve de concept, incluant la preuve forgée, les instructions de vérification et le code de génération du circuit, a été publié en accès libre dans le dépôt quantum-zk-proof-poc sur GitHub. C’est un choix éditorial révélateur : plutôt que de garder la faille secrète, Trail of Bits a choisi la transparence totale une fois le correctif en place, un mode opératoire cohérent avec ses publications précédentes sur les audits de zkVM.
Pourquoi l’affaire dépasse largement le cas Google
La leçon centrale, formulée par les chercheurs eux-mêmes, tient en une phrase : une preuve à divulgation nulle de connaissance peut fidèlement prouver l’exécution d’un programme buggé. SP1 a fonctionné exactement comme prévu. Groth16 a fonctionné exactement comme prévu. La chaîne cryptographique tout entière a vérifié, à raison, que le simulateur Rust s’était exécuté conformément à sa spécification. Le problème n’est pas dans les mathématiques de la preuve, il est dans le programme que la preuve certifie avoir exécuté. Ce distinguo change la manière dont il faut lire toute annonce s’appuyant sur une preuve ZK : la preuve garantit l’exécution correcte du code, pas la correction du code lui-même.
Cette affaire n’est pas isolée. En juillet 2026, l’équipe zkSecurity a signalé un bug de solidité critique dans OpenVM, un autre zkVM, permettant à un prouveur malveillant de forger une égalité de pairing en contournant une vérification de sous-corps. La faille est suivie sous l’identifiant CVE-2026-46669 et corrigée dans OpenVM 1.6.0. De son côté, l’outil de recherche zkFuzz a détecté 85 bugs, dont 59 zero-days, sur 39 desquels les développeurs ont confirmé la gravité, en analysant 452 circuits publics de production. Trail of Bits a par ailleurs audité une partie de la zkVM Miden, développée par 0xMiden, écrite dans un langage assembleur maison baptisé MASM. Faute d’outillage existant pour ce langage, l’équipe a construit un décompilateur et un moteur d’analyse statique en s’appuyant sur Claude et Codex, un choix qui a permis de repérer une faille de falsification de signature que Trail of Bits décrit comme potentiellement coûteuse de plusieurs millions de dollars (Trail of Bits, source).
Panorama des incidents récents de sécurité dans les preuves zero-knowledge
Mis bout à bout, ces épisodes dessinent une tendance claire : les zkVM ne sont pas des boîtes noires infaillibles, ce sont des logiciels comme les autres, avec des bugs de logique et de mémoire comme les autres.
| Système | Date | Type de faille | Conséquence |
|---|---|---|---|
| zkVM SP1 (simulateur Google) | 17 avril 2026 | Désérialisation non sécurisée + corruption mémoire | Preuve de ressources falsifiée, corrigée par Google |
| OpenVM | 27 juillet 2026 (CVE-2026-46669) | Vérification de sous-corps manquante | Forgerie d’égalité de pairing possible, corrigé en v1.6.0 |
| 452 circuits publics (étude zkFuzz) | 2026 | Bugs de logique de circuit divers | 85 bugs détectés, 59 zero-days, 39 confirmés par les équipes |
| zkVM Miden (0xMiden) | 2026 | Falsification de signature | Faille jugée à risque de plusieurs millions de dollars par Trail of Bits |
Ce panorama ne dit pas que la cryptographie zero-knowledge est cassée dans son principe. Il dit que son implémentation logicielle suit les mêmes lois que tout code écrit par des humains, avec les mêmes classes de vulnérabilités qu’on traque depuis des années dans les navigateurs ou les serveurs web.
Contexte historique : des preuves mathématiques aux preuves de code exécuté
Les preuves à divulgation nulle de connaissance existent depuis les travaux fondateurs de Goldwasser, Micali et Rackoff au milieu des années 1980. Pendant longtemps, leur usage est resté cantonné à la théorie de la complexité et à quelques protocoles d’authentification. L’essor des zk-SNARK à partir de 2012, puis leur adoption massive par Zcash en 2016 avec Groth16, a transformé ces objets mathématiques en outils d’ingénierie à grande échelle, d’abord pour la confidentialité des transactions, puis pour la scalabilité des blockchains avec les rollups Ethereum. L’arrivée des zkVM comme SP1, RISC Zero ou Jolt à partir de 2023-2024 a marqué un nouveau saut : au lieu d’écrire un circuit arithmétique dédié à chaque calcul, il suffit d’écrire un programme classique et la zkVM se charge de produire la preuve de son exécution correcte.
Ce confort a un coût caché. Un circuit arithmétique écrit à la main est petit, auditable ligne par ligne. Un programme Rust complet qui tourne dans une zkVM, lui, embarque toute la complexité d’un vrai logiciel : gestion mémoire, désérialisation, chemins d’exécution conditionnels. L’affaire Google-Trail of Bits est la première démonstration publique à grande visibilité que cette complexité supplémentaire ouvre une nouvelle surface d’attaque, distincte des faiblesses cryptographiques classiques que la communauté sait déjà chercher.
L’angle européen : audits indépendants et cadre réglementaire
Aucune réaction officielle d’un régulateur français ou européen n’a été recensée à ce jour concernant spécifiquement l’incident Google-Trail of Bits. Mais le contexte réglementaire européen donne un relief particulier à cette affaire. Le Cyber Resilience Act impose déjà des obligations de gestion des vulnérabilités et de signalement pour les composants logiciels critiques, une catégorie qui inclura de facto les bibliothèques de preuve zero-knowledge à mesure qu’elles s’intègrent dans des produits commerciaux, qu’il s’agisse de portefeuilles crypto, de systèmes de vérification d’âge ou d’infrastructures d’identité numérique. L’Agence nationale de la sécurité des systèmes d’information (ANSSI) recommande depuis plusieurs années l’agilité cryptographique et l’audit indépendant du code, deux principes que l’affaire Trail of Bits illustre à la perfection : ce n’est pas l’algorithme cryptographique qui a échoué, c’est l’absence d’audit suffisamment poussé du code qui l’implémente.
Pour les entreprises européennes qui envisagent d’utiliser une zkVM en production, que ce soit pour des rollups Layer 2, des systèmes de vote électronique ou des preuves de conformité, le message pratique est direct : un audit de la couche cryptographique ne suffit pas, il faut aussi auditer le code applicatif qui tourne dans la machine virtuelle, avec la même rigueur que pour n’importe quel logiciel critique.
Impact sur le marché des audits et de la confiance cryptographique
Sur le plan commercial, l’épisode renforce la demande pour les cabinets spécialisés dans l’audit de circuits zero-knowledge, un marché de niche où Trail of Bits, zkSecurity et quelques autres acteurs concentrent l’essentiel de l’expertise disponible. Le rythme de publication de vulnérabilités observé en 2026, avec plusieurs incidents documentés en quelques mois seulement sur OpenVM, Miden et le simulateur de Google, traduit une professionnalisation rapide de cette discipline, portée notamment par l’usage d’outils d’analyse assistée par IA pour compenser le manque d’outillage natif sur des langages maison comme MASM.
Pour les investisseurs et les équipes techniques qui évaluent un protocole s’appuyant sur une zkVM, l’affaire ajoute un critère de diligence supplémentaire : la présence d’un audit indépendant récent, la divulgation publique du dépôt de code source, et l’existence d’un programme de bug bounty actif sur la couche applicative, pas seulement sur les primitives cryptographiques sous-jacentes comme celles décrites sur le blog de Succinct Labs, l’éditeur de SP1.
Ce que retiennent les chercheurs en sécurité
Au-delà du cas précis, Trail of Bits situe son travail dans une démarche plus large d’audit systématique des zkVM émergentes. L’équipe explique avoir “audité une partie de la zkVM de @0xMiden, écrite dans un langage assembleur maison appelé MASM” (Trail of Bits, source), avant de préciser que “MASM n’avait initialement aucun outillage pour les développeurs, nous avons donc utilisé Claude et Codex pour construire un décompilateur et un moteur d’analyse statique” (Trail of Bits, source). Ce recours à l’IA pour combler l’absence d’outils sur des langages spécialisés devient une pratique courante chez les auditeurs de zkVM, où chaque projet invente souvent son propre langage intermédiaire.
Sur le fond scientifique, il faut rappeler ce que l’affaire ne remet pas en cause : la faisabilité théorique d’une cryptanalyse quantique de l’ECC avec des ressources de l’ordre de celles annoncées par Google reste un sujet de recherche actif et sérieux, documenté par ailleurs dans des travaux référencés sur des dépôts comme l’archive Cryptology ePrint. Ce que l’affaire remet en cause, c’est la fiabilité du mécanisme utilisé pour vérifier ce type d’annonce sans révéler le circuit complet.
Cinq évolutions à surveiller d’ici 2027
- Multiplication des audits obligatoires : les entreprises publiant des preuves ZK à fort enjeu commercial ou scientifique devront de plus en plus accompagner leurs annonces d’un audit indépendant publié en parallèle, sous peine de voir leurs chiffres contestés comme ceux de Google.
- Outillage renforcé pour les zkVM : la démarche de Trail of Bits sur Miden, bâtir un décompilateur avec l’aide de Claude et Codex faute d’outils natifs, va se généraliser à mesure que de nouveaux langages intermédiaires spécifiques aux zkVM apparaissent.
- Standardisation des compteurs de ressources : les protocoles ZK vont probablement intégrer des mécanismes de comptage de portes vérifiés au niveau du circuit lui-même plutôt qu’au niveau du programme hôte, pour éviter qu’un bug de logique applicative ne fausse la comptabilité.
- Programmes de bug bounty spécifiques aux zkVM : suivant le rythme observé avec OpenVM et Miden en 2026, davantage de projets vont ouvrir des primes ciblées sur la couche d’exécution des zkVM, distincte des primes classiques sur les primitives cryptographiques.
- Vigilance réglementaire accrue en Europe : avec la montée en puissance du Cyber Resilience Act, les composants zero-knowledge intégrés dans des produits commerciaux vendus en Europe devraient être soumis à des exigences de gestion des vulnérabilités comparables à celles qui s’appliquent déjà aux bibliothèques comme OpenSSL.
Ce que les entreprises doivent changer dans leur usage des zkVM
Pour une équipe technique qui envisage d’adopter une zkVM comme SP1, RISC Zero ou Jolt, l’affaire Trail of Bits offre une checklist implicite. D’abord, vérifier que le code exécuté à l’intérieur de la zkVM a fait l’objet d’un audit de sécurité classique, mémoire et logique, en plus de la validation du protocole de preuve lui-même. Ensuite, éviter autant que possible les blocs de code marqués unsafe dans les chemins critiques du simulateur ou du programme invité, ou a minima les isoler et les auditer séparément. Enfin, valider strictement toute donnée désérialisée provenant d’une source externe, y compris quand cette donnée provient d’un composant interne au système, puisque c’est précisément ce contrôle qui manquait dans le code de Google.
Cette liste n’a rien d’exotique pour un ingénieur en sécurité applicative classique. C’est justement le point que Trail of Bits cherche à faire passer : la sécurité des zkVM ne relève pas seulement de la cryptographie théorique, elle relève d’abord et avant tout du génie logiciel ordinaire, avec ses disciplines éprouvées depuis des décennies.
Foire aux questions
Google a-t-il vraiment cassé la cryptographie à courbes elliptiques ?
Non, pas dans le sens d’une attaque réalisée sur un ordinateur quantique réel. Google a publié une preuve à divulgation nulle de connaissance décrivant les ressources théoriques nécessaires pour une telle attaque. L’affaire Trail of Bits porte sur la fiabilité de cette preuve, pas sur la faisabilité physique de l’attaque elle-même.
Qu’est-ce qu’une zkVM comme SP1 ?
Une zkVM, machine virtuelle à divulgation nulle de connaissance, permet d’exécuter un programme classique et de générer automatiquement une preuve cryptographique que ce programme a tourné correctement, sans avoir à réécrire le calcul sous forme de circuit arithmétique dédié. SP1 est développée par Succinct Labs et utilisée notamment pour des rollups blockchain et des calculs vérifiables comme celui de Google.
Pourquoi zéro porte de Toffoli est-il suspect ?
Parce qu’aucun circuit connu capable de réaliser une multiplication scalaire sur courbe elliptique ne peut fonctionner sans opérations logiques réversibles, assurées par les portes de Toffoli dans ce type de simulateur. Un chiffre à zéro indique que le compteur a été contourné, pas que l’opération a été évitée.
Google a-t-il subi une faille de sécurité classique ?
Oui, sous deux formes : une désérialisation non sécurisée de données contrôlées par l’utilisateur, et une corruption mémoire issue d’opérations Rust marquées unsafe. Ce sont des classes de vulnérabilités courantes en sécurité logicielle, appliquées ici au code d’un simulateur de cryptanalyse quantique.
Un identifiant CVE a-t-il été attribué à cette faille ?
Non, l’incident a été traité comme une divulgation de vulnérabilité propre au projet de Google, sans attribution CVE publique connue, contrairement à d’autres incidents zkVM de la même période comme celui d’OpenVM, suivi sous CVE-2026-46669.
Le code de la preuve forgée est-il public ?
Oui, Trail of Bits a publié l’intégralité du matériel de reproduction, preuve forgée, instructions de vérification et code de génération du circuit, dans le dépôt open source quantum-zk-proof-poc sur GitHub, après que Google a corrigé les vulnérabilités concernées.
Cette affaire concerne-t-elle Bitcoin ou Ethereum directement ?
Indirectement. La cryptanalyse quantique de l’ECC visée par la preuve de Google concerne le même type de courbes elliptiques utilisées par Bitcoin et Ethereum. Mais l’incident Trail of Bits ne porte pas sur une attaque contre ces réseaux : il porte sur la fiabilité des preuves utilisées pour évaluer les ressources théoriques nécessaires à ce type d’attaque future.
Que doivent faire les entreprises qui utilisent une zkVM en production ?
Auditer non seulement le protocole de preuve cryptographique, mais aussi le code applicatif exécuté dans la zkVM, avec les mêmes standards de sécurité logicielle que pour tout composant critique : validation stricte des entrées désérialisées, revue des blocs de code non sécurisés, et programme de divulgation responsable actif sur la couche applicative.
