Étude de la sécurité du ĞMixage

J’ai réécrit le programme de simulation et d’analyse de la sécurité d’un réseau ĞMixer, en passant du Python au Rust ça tourne littéralement 100 à 1000 fois plus vite. (le dépôt du programme utilisable en une commande)

Je peux donc simuler et « rétro-mixer » (si quelqu’un trouve un mot pour ça…) en 4 minutes, en faisant fondre les 4 cœurs de mon i5, environ 11000 transactions avec les paramètres suivants :

  • un unique montant de tx
  • expiration d’une tx non traitée après 288 blocs (1 jour)
  • expiration d’un mixage non terminé après 1008 blocs (3.5 jours)
  • 3 couches d’oignon
  • 4032 blocs (2 semaines)
  • 200 clients
  • 20 nœuds
  • « smart clients » activé
  • txmin = 5 (nombre minimal de txs en attente dans un nœud pour déclencher le mixage)
  • 0.0035 txs/bloc/client (= 1 tx/jour/client en moyenne)

Le mode « smart clients » fait que les clients préfèrent envoyer une transaction aux nœuds n’ayant pas dépassé txmin, afin de maximiser les chances pour chaque transaction d’être traitée, et d’égaliser la charge entre les nœuds. Le désactiver divise par 100 la durée nécessaire au forensics.

Voici des graphiques. L’axe y est la probabilité qu’une tx entrante (client -> nœud) soit la tx associée à une certaine tx sortante (nœud -> client). Chaque point représente une session de mixage terminée. Plus la moyenne est basse, moins on a de chances de casser l’anonymat. Plus l’écart type est bas, moins il est facile de discriminer les différentes txs.
image
image

Plus de tests seraient nécessaires pour trouver des paramètres optimaux, et savoir comment gérer des cas particuliers tels qu’un changement de DU, ou s’il est dangereux de mixer des montants différents, voire d’appliquer une taxe.

S’il s’avère que je ne peux pas lancer assez de tests moi-même pour conclure, je proposerai de faire du crowd computing (avec un système tout beau tout simple où il suffira de lancer une seule commande et il fera tout tout seul).

1 J'aime

Pense tu que l’anonymisation des montants permettrait d’améliorer la sécurité des services de mixage ?

Mon programme trace le graphe orienté de toutes les txs entre les nœuds. Il le remonte à partir d’une tx de sortie donnée, pour trouver toutes les txs d’entrée possibles, en sélectionnant celles qui ont le même montant.

Cacher le montant des txo permettrait de mixer le montant qu’on veut, sans altérer la sécurité. Cependant la sécurité serait égale à celle d’un réseau à un montant unique. (il me semble)

L’inconvénient, c’est que si la clé privée d’un nœud est publiée, alors on peut associer à partir de la blockchain ses txs entrées et sorties (qui ont le même montant). Il faudrait alors que les nœuds changent de clé privée périodiquement, pour réduire les dégâts en cas de vol d’ids.

1 J'aime

Voilà ! Avec les paramètres décrits ci-dessus, mais en changeant de montant au milieu (bloc 2016) :
image
image

:crab: Graphiques réalisés avec plotters.

:male_detective: On observe un anonymat très satisfaisant dès 2-3 jours (1 jour = 288 blocs).

:currency_exchange: Le changement de montant provoque comme prévu un arrêt total du mixage pendant quelques dizaines de blocs puis ça repart avec une baisse de l’anonymat qui se résorbe rapidement.

:timer_clock: Les transactions sont généralement traitées en moins de 3h. C’est plus lent sans les clients intelligents.

:arrow_down: Essayez-le chez vous ! (instructions dans le readme)

1 J'aime

Il ne marche pas sur Debian 10, pour cause :

./gmixer_analyzer: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29’ not found (required by ./gmixer_analyzer)

Debian10 utilise une libc6 antérieure Version : 2.28-10

Oui, je me suis rendu compte de ça pour un autre programme. :cry:

C’est parce que je compile sous ArchLinux, avec les dernières versions des biblis système. Je recompile ça sous Debian 10 et je republie le binaire.

Edit: @matograine J’ai ajouté le lien sur le GitLab. Mon serveur Debian est beaucoup, beaucoup lent que mon laptop Arch, c’est dommage.