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 