[Idée] Clé déléguée au calcul de blocs

Exactement.

Oui, mais le calcul des blocs est plus critique que le statut de membre. Après je pencherais pour un nombre de certifications plus petit vu qu’il y a moins de personnes qui calculent. 2 ou 3 me semble suffisant. Un membre lambda n’ayant pas forcement les connaissances pour déterminer si un nœud calculant est sécurisé ou pas, il ne me semble pas bon de leur laisser cette possibilité. Après cette 2ème couche de confiance pourrait être plus facile d’accès que le statut de membre. Pas forcement besoin de connaître la personne en vrai, simplement discuter avec lui pour savoir sur quoi il l’héberge, s’il a fait les configurations de base pour se protéger, etc. Les calculateurs pourront sûrement aider de nouvelles personnes et partager leur connaissance pour avoir un réseau plus sûr. Enfin si une personne n’a pas encore moyen d’avoir une plateforme assez sécurisée, il peut toujours faire un nœud miroir qui ne compromet pas son identité, la sécurité du réseau mais qui augmente la redondance des données ainsi que la bande passante du réseau.

Le plus gros problème aujourd’hui, c’est que les membres ne sont même pas au courant que leur clé est en train de calculer si jamais elle est compromise.

La clé déléguée permettrait de régler ce problème (les clés calculantes sont inscrites en blockchain)…

J’y repense, le problème n’est pas là. Si l’utilisateur n’a pas émi de clé déléguée pour calculer, mais qu’il se trouve que son client l’avertit qu’une clé déléguée est présente sur le réseau et calcule à sa place, il va bien se retrouver dans la situation que j’ai décris :

Est-ce qu’un utilisateur aura vraiment envie de révoquer sa clé déléguée ? Pour se protéger, il doit révoquer son identité et sa clé déléguée. Si cet évènement arrive, la clé déléguée permet de révoquer son identité. L’utilisateur pourrait se dire “tant que l’attaquant de me révoque pas, je m’en fiche…”

Comme proposé plus haut, on ne pourrait calculer qu’avec une clé déléguée, et plus avec sa clé privée.
A ce moment là au moins 2 possibilités :

  • Le membre déclare sa clé déléguée et peut directement miner avec
  • Le membre déclare sa clé déléguée, puis d’autres membre doivent la certifier pour qu’elle puisse être utilisée pour calculer des blocs.

Le calcul de bloc devrait être en option et désactivé par défaut (ce qui sera le cas si la clé déléguée de calcul devient obligatoire).

Après on pourrait réfléchir pour trouver un moyen de détecter l’utilisation de la clé sur une machine qui n’est pas la notre, et ceux sans dégrader la vie privée de la personne.

1 Like

Si l’on considère le cas d’un attaquant avec un minimum de moyens capable de déclarer une clé déléguée à l’insu de son propriétaire (on suppose là que la clé a pu être dérobée), alors obtenir 3-4 certfications de calcul ne me semble pas être une protection suffisante, même sans complices (vu qu’il peut voler des clés).

Par contre on peut rendre la procédure moins immédiate en instaurant des règles diverses comme :

  • une clé déléguée doit attendre 5 jours/blocs avant d’être utilisable
  • une clé déléguée sortie de la fenêtre courante devient inactive subit un handicap

Autre piste

On joue sur la difficulté personnalisée pour mitiger le contrôle par l’attaquant.

J’ai déjà parlé des clés déléguées VRF dans un autre sujet, permettant de faire du tirage au sort. Ce que j’ai en tête, de façon non définitive et non formalisée : on peut imager 3 tranches égales de calculateurs, avec comme aujourd’hui 1 tranche de calculateurs exclus. Les 2 tranches restantes n’auraient pas de difficulté excluante, mais on pourrait avoir une pente pour la deuxième tranche et enfin le niveau minimum commun en dernière tranche :

À ces niveaux « de tranche » on ajoute donc un handicap personnalisé (fonction de notre niveau effectif de blocs constaté, par rapport à la médiane/tercile des autres calculateurs), et aussi un bonus aléatoire. Ce bonus ne devrait pas être trop fort en rapport à la difficulté commune, mais permettrait de favoriser aléatoirement des nœuds, ce qui évite un contrôle déterministe par un attaquant.

Bon, je ne dis pas que c’est la panacée, mais forts d’une fonction de tirage aléatoire vous pourriez avoir d’autres idées :slight_smile:

1 Like

Peux-tu rappeler ce qu’est la “fenêtre courante” ?

L’idée d’un bonus aléatoire est une très très bonne idée. Il faudrait que je m’intéresse au fonctionnement des VRF. Tu as un document qui décris leur utilisation pour une blockchain ?

La fenêtre courante est un concept utilisé dans le protocole Duniter : c’est l’ensemble des N blocs précédents HEAD permettant de définir le nombre estimé de calculateurs en cours. N = taille de la fenêtre courante, et cette taille est donnée par le champ issuersFrame de chaque bloc. Cette taille évolue au fil des différents émetteurs que l’on peut constater dans cette fenêtre.

Grosso modo : la fenêtre courante = nombre de calculateurs s’exprimant sur le réseau * 5.

J’ai découvert ça récemment dans la publication d’Algorand, c’est au cœur de cet algorithme. Les fonctions VRFs sont un mécanisme découvert en 1999, mais devenu praticable qu’assez récemment.

Côté implémentations, ça ne court pas les rues : voir les implémentations connues par l’IETF. Mais j’ai déjà pu en réaliser une de mon côté en C++ (reposant largement sur la libraire libsignal), et en faire un addon NodeJS. Pour Rust je ne sais pas, mais j’ai vu passer aussi une implémentation en Go, alors il y a peut-être un espoir.

Alors, dans les hypothèse, c’est un membre non-informaticien, qui se ferait dérober sa clé. Les membres déjà “calculateurs”, on considère qu’ils ont intégré les minimums requis en terme de sécurité etc.

Du coup, ça me semble être une hypothèse raisonnable de considérer que l’attaquant ne pourrait pas voler massivement les clés des membres calculant.
De toute façon, si cette hypothèse n’est pas considérée comme raisonnable, on est mal barré :slight_smile:

L’inconvénient que je vois ici avec ce système de certifications au sein des certifications, c’est que ça complexifie encore plus le protocole de Duniter. Ca rendrait la maintenance et la montée en compétence très laborieuse ! :slight_smile: C’est déja assez complexe comme ça…

Donc si on trouve une solution technique et non humaine, telle que ton idée de tirage au sort, ça me paraitrait très bien.

2 Likes

En effet l’idée du tirage au sort me semble mieux qu’une certification supplémentaire, avec un temps d’attente initial.

Si tu as un code en C++, il y a moyen de le traduire en Rust :wink: Il doit aussi y avoir un équivalent à libsignal. Je vais regarder ton code et faire quelque recherches, je te tiens au courant :slight_smile:

EDIT : Ow, les VRF c’est du 0-knownledge proof ? C’est bon ça :smiley:

1 Like

Je faisais l’hypothèse d’un membre non-informaticien et non calculateur à qui on dérobe la clé de membre.

Tu as l’air de mieux connaître que moi, j’ai seulement compris l’intérêt fonctionnel :slight_smile: je vais me renseigner.

1 Like

J’ai trouvé ce document qui explique en détail comment ça fonctionne. Tu as déjà une implémentation, mais ça pourrait être utile pour comprendre ce que l’on peut faire avec ou pour d’autres personnes (comme moi) qui voudrait le réimplémenter.

2 Likes

Pour résumer l’état actuel de nos réflexions :

A court terme : Implémenter le système de publication de clé déléguée dédiée au calcul. Ce mécanisme limitera l’impact d’avoir 5% des clés de la toile calculantes, et réduira l’exposition des clés membres sur internet.

A moyen terme : Trouver une solution avancée pour se défendre contre une attaque du type “un attaquant vole N clés et profite d’un poids potentiel plus fort dans le calcul”.

2 Likes

Rien à redire pour le moment :slight_smile:

Oui mais bon, c’est une implémentation non standard j’ai l’impression. En effet les clés utilisées ne sont pas compatibles avec libsodium, j’avais fait un ticket sur le dépôt de libsignal et je me suis aperçu tout seul qu’ils utilisaient un « clamping » qui modifiait la clé privée pour la rendre compatible.

Bref c’est utilisable, mais quelles garanties aies-je que ça fonctionne comme espéré, et sans faille dans leur code ?

Vu que dans ma crate de crypto j’ai accès aux fonctions sur courbe elliptique, je vais voir si c’est possible de l’implémenter directement.

oui c’est la clef principale qui doit pouvoir révoquer la clef déléguée.

La clé principale doit permettre de révoquer la clé déléguée en la changeant. Mais pour insister les membre à ne pas faire n’importe quoi, la clé déléguée permet aussi de révoquer le compte. Ça évite que les membres puisse donner leur clé déléguée à n’importe qui pour qu’il calcule à sa place.

Le bonus aléatoire, super idée, mais pas besoin d’intégrer des fonctions lourdes et du zéro knowledge, nous avons déjà un générateur de nombres aléatoires qui fait toujours consensus : le hash du bloc courant (non prévisible graçe au nonce).

Il suffit de transformer le hash en nombre entier et de calculer le modulo (le reste de la division euclidienne) par la taille de l’échantillon, c’est trè s facile a coder et donnera le même résultat, et tout cas je saurais coder ça sans problème :slight_smile:

Je suis d’accord pour le bonus aléatoire à partir du hash du bloc.

Par contre plus tard je pense qu’il sera bon d’intégrer des VRF et du zero-knownledge pour permettre de nouvelles choses.

Je préfère que Duniter reste léger, le zéro-knowledge c’est gourmand en ressource, et pour l’instant je ne vois pas en quoi sa serait nécessaire. Il vaut mieux que le coeur reste exclusivement dédié aux fonctionnement de la monnaie !

1 Like

Tu peux aller au bout de ton idée afin de comprendre qui obtient quel bonus ?

1 Like