Les faiblesses de RingCT
Là où la confidentialité de Monero est imparfaite aujourd’hui — et pourquoi c’est précisément ce que corrige FCMP++
Dans RingCT, les montants et les destinataires sont protégés par la cryptographie. L’expéditeur — seulement par la statistique : « 1 sur 16 ». Presque toutes les attaques connues fonctionnent de la même façon : elles excluent des leurres de l’anneau ou pondèrent les candidats par probabilité. Voici les principales, des plus connues aux plus subtiles.
Le modèle : la taille effective de l’anneau
Un anneau de 16 n’offre 16 possibilités que si toutes sont également plausibles. Chaque bribe d’information extérieure réduit la taille effective de l’anneau. Si un observateur peut rayer 10 leurres, il reste « 1 sur 6 ». S’il peut pondérer les autres — « probablement celui-ci ».
1. La réaction en chaîne (historique)
Avant 2016, les transactions sans leurres (anneau de 1) étaient autorisées. Une telle entrée révèle exactement quelle sortie a été dépensée. Et si cette sortie a servi de leurre dans l’anneau de quelqu’un d’autre, on peut l’y rayer. Cela peut rendre un autre anneau univoque, et ainsi de suite — une réaction en chaîne. Des études de 2017 ont montré qu’une grande partie des premières entrées avaient été désanonymisées de cette façon.
État : fermé par l’interdiction des anneaux sans leurres et le passage à RingCT (les sorties RingCT ne se mélangent qu’avec des sorties RingCT). Mais les anciennes sorties gardent la mémoire de leur histoire.
2. L’âge des entrées
Si la distribution de l’âge des leurres ne correspond pas à la manière dont les gens dépensent réellement, l’entrée réelle se distingue. L’heuristique classique « la plus récente est la vraie » fonctionnait très bien sur les premières transactions. Détails dans sélection des leurres.
État : atténué par la loi gamma, mais impossible à corriger complètement tant que des leurres sont choisis.
3. L’attaque EAE (Eve–Alice–Eve)
Eve (par exemple une plateforme d’échange) envoie de l’argent à Alice, et Alice renvoie plus tard de l’argent à Eve (la même plateforme, éventuellement via quelques transactions intermédiaires). Eve connaît sa sortie au début de la chaîne et sa sortie à la fin. Si elle voit « sa » sortie dans les anneaux des transactions intermédiaires et que la chronologie est plausible, elle peut relier l’envoi et la réception avec une forte probabilité.
État : l’une des attaques les plus concrètes pour les services centralisés. Atténuée par le churning (s’envoyer des fonds à soi-même avec des pauses), mais corrigée de façon fiable seulement par FCMP++.
4. L’inondation (black marble)
Un attaquant produit en masse des transactions avec ses propres sorties. En vertu des règles de sélection des leurres, celles-ci commencent à apparaître dans les anneaux des autres utilisateurs. L’attaquant sait qu’elles sont « vides » et les raye. Plus sa part des sorties sur une période est grande, plus l’anneau effectif de tous les autres est petit. De tels épisodes de spam ont été observés en 2021 et 2024 ; les estimations ont montré une baisse notable de la taille effective des anneaux pendant ces périodes.
État : limitée par le coût (frais) et la taille de bloc dynamique. Éliminée par FCMP++ : quand l’« anneau » est toute la blockchain, la part de l’attaquant est négligeable.
5. La fusion d’entrées
Si une transaction dépense 5 entrées, cela fait 5 anneaux, et l’on sait que les membres réels des cinq appartiennent à une même personne. Si un observateur voit que ces anneaux contiennent des sorties issues d’une même transaction passée, c’est un signal fort que ce sont les vraies entrées (une sélection aléatoire de leurres produirait difficilement une telle coïncidence).
État : inhérent aux anneaux. FCMP++ l’affaiblit fortement (chaque entrée est « une parmi toutes »), mais le nombre d’entrées reste visible.
6. Les métadonnées des transactions
- Nombre d’entrées et de sorties : 1→2 est courant, 15→1 se remarque (consolidation).
- Frais : des frais non standard trahissent un portefeuille non standard.
- Moment : les transactions faites juste après la réception des fonds révèlent l’âge de l’entrée réelle.
- tx_extra : champs non standard, ordre, clés supplémentaires — une « empreinte du portefeuille ».
- Unlock time : les valeurs non standard se remarquaient (supprimé dans les règles plus récentes).
État : FCMP++ n’y touche presque pas — c’est le rôle des portefeuilles : un comportement uniforme, des formats uniformes.
7. La couche réseau
Le nœud qui a relayé une transaction en premier en est probablement l’auteur. Monero utilise Dandelion++ : une transaction passe d’abord discrètement le long d’une chaîne de nœuds aléatoires (la « tige », stem) et n’est diffusée à tous qu’ensuite (la « floraison », fluff). S’y ajoute la prise en charge de Tor/I2P. Si vous utilisez le nœud distant de quelqu’un d’autre, il voit votre IP et le moment de l’envoi.
État : hors chaîne, FCMP++ n’aide pas. Utilisez votre propre nœud ou Tor.
Bilan : ce que FCMP++ corrige
| Faiblesse | RingCT | FCMP++ |
|---|---|---|
| Réaction en chaîne | historique | sans objet |
| Âge des leurres | atténuée | éliminée |
| EAE | fonctionne | éliminée (on-chain) |
| Inondation | fonctionne | pratiquement éliminée |
| Fusion d’entrées | fonctionne | fortement affaiblie |
| Métadonnées (nombre d’entrées/sorties, frais, moment) | visibles | visibles |
| Réseau (IP) | Dandelion++/Tor | inchangé |
Pour la suite : comment fonctionne FCMP++.