La solution pour des identicones sécurisées: le random id

Bonne idée.

Mais les frais d’ouverture de comptes ne serviront qu’à ce random id ?

Ça risque de compliquer l’utilisation de compte jetables, nécessaires par exemple pour l’anonymisation. Peut-être qu’on pourrait ne pas demander de random id pour certains comptes, mais ça complexifierait les extrinsics…

Ça sert aussi à lutter contre le spam de comptes. Car chaque nouveau compte à un coût en terme de stockage onchain lié à la seule existence du compte.

Créer un nouveau compte pour chaque transfert c’est coûteux en traitement pour la blockchain, car la notion de compte gère beaucoup de choses dont on a par besoin pour un compte jetable à usage unique, comme le nonce par exemple.

Le mieux c’est de créer 2 extrinsics dédiés pour les transfert vers et depuis un compte jetable, ce sera beaucoup plus efficient.
Ce serait un compte spécial dégradé qui ne pourrait que “transfer all” et une seule fois avec 2 destinataires en paramètres.

1 Like

Et pourquoi ne pas faire une identicon basé sur le checksum de la pubkey ?
J’ai fait ça dernièrement pour g1compagnon, avec la couleur de fond basée aussi sur la pubkey :

image

Je trouve ce genre d’identicon beaucoup plus identifiable que ce genre d’identicons :

source : https://github.com/ethereum/blockies

1 Like

Peux-tu expliciter ? En plus du minimum d’existence du compte (mettons 1G1) , il faudrait payer des frais si on verse de la monnaie sur un compte pas encore existant en BDD?

Qu’en serait-il pour un compte qui aurait été vidé (donc supprimé de la BDD), puis recrédité ? Devra-t-il subir de nouveau des frais lors du versement ?

Relis le début de mon post @ManUtopiK , j’explique pourquoi li ne faut surtout par faire ça pour des raisons de sécurité.
Il est très facile de générer des milliards de pubkey très rapidement pour obtenir l’identicone qu’on veut, or il ne faut pas que l’utilisateur puisse choisir quelle identicone il aura.
L’identicone doit être dérivé d’informations qui ne peuvent pas être chosies ni manipulées par l’utilisateur, la seule solution que je vois c’est d’utiliser une source aléatoire robuste et vérifiable.

De plus, dans la Ğ1v2 il n’y aura plus de pubkey ni de checksum, mais des adresses au format ss58, un format qui intègre nativement un checksum dans l’adresse.

Oui c’est exactement ça. Voici un exemple avec un dépôt d’existence de 2 Ğ1 et le frais de création de compte de 3 Ğ1. Soit Alice un compte avec 10 Ğ1 et Bob un compte qui n’existe pas (donc avec 0 Ğ1 et pas d’identité).
Alice doit alors verser au moins 5Ğ1 sur le compte de Bob. Si elle en verse moins, l’intégralité des Ğ1 versées seront transférées à la trésorerie au bloc d’après.
Si Alice verse par exemple 8 Ğ1 sur l’adresse de Bob, le compte de Bob aura 5Ğ1, et 3 Ğ1 iront à la trésorerie.

Oui il devra les payer de nouveau.

1 Like

Je vois l’intérêt coté sécurité et anti-spam.
En revanche je vois aussi le surplus de complexité pour l’utilisateur.
Ça ne veut pas dire que je suis contre, mais qu’il me semble important de réfléchir à comment rendre ça simple d’usage, plus particulièrement pour les nouvelleaux avant de le mettre en place.

  • Je débarque dans la ML, je trouve intéressant et je ne connais encore personne, je veux créer un compte porte feuille pour vendre des choses, comment je fais ? Avec ce que j’ai compris, j’ai besoin d’un don ou d’une vente pour ouvrir mon compte, mais je ne connais pas encore l’adresse ss58 correspondante, du coup ça me donne l’impression d’un serpent qui se mort la queue.
  • Je veux créer un compte anonyme, je dois lui envoyer de la monnaie depuis un compte existant, qui lui même aura reçu pour sa création de la monnaie depuis un compte existant… Ok, ça n’empèche pas de mixer à certain moment, mais ça me semble complexifier l’anonymat. Ceci dit, pour ce sénario @elois à déjà proposé une solution technique :
2 Likes

Mais pourquoi donc ?? Je ne vois aucune raison de ne pas afficher l’adresse correspondante à une clé publique, ceci ne dépend pas de la blockchain.

Du point de vue de l’UX, l’utilisateur aura toujours l’impression de “créer” son compte alors que son application n’a fait que générer une paire de clé, et afficher une adresse avec un solde de zéro.

Svp quand je parle des règles de la blockchain arrêter d’essayer de calquer ça tel quel à l’UX, c’est évidemment idiot de le calquer tel quel, aucune application grand public ne fait ça.

Concrètement pour l’utilisateur ça change une seule et unique chose: le premier dépôt sur un compte doit être d’au moins 5 Ğ1.

Ce qui est déjà le cas dans Duniter v1, et ce qui est forcément le cas dans tous les cas, puisque de la monnaie ne peut être reçue que depuis un compte qui en possède, sauf à créer le DU mais dans ce cas ce n’est pas un simple portefeuille.

Je ne suis pas d’accords, ce serait justement peut être intéressant que “les applications grand public” dans l’écosystème blockchain s’intéressent un peu plus à l’UX qu’implique leur protocole blockchain.

Malgré leurs moyens, je ne sais pas vraiment à qui s’adresse l’UX développé par les équipes de polkadot. Rien de ce que je vois ne semble s’adresser à M. tout le monde. Ils semblent s’adresser à un public d’expert ou de passionné, présents uniquement par intéret mercantile, et donc prêt à passer des heures d’apprentissage extérieur pour comprendre les tenants et aboutissant des interfaces qui leurs sont proposés.

Les réflexions de 1000i100 me semblent donc saines.


En manipulant la lib JS polkadot, j’observe que la gestion d’identicon/avatar semble complètement intégré à la génération et gestion d’adresses.

Pour eux visiblement (polkadot & co) cela ne semble pas poser de problème de sécurité.
Ce que tu proposes ici, semble certe très intéressant, mais implique des choses qui alourdissent encore le protole et l’UX. Cela ne me semble pas KISS.

Est-on sûr que celà soit prioritaire pour la migration ?
Je compends que changer de format d’identicon en cours de route ne serait pas sympa pour les utilisateurs et lourd à pousser sur tous les clients wallets.
Mais ne pourrait-on pas juste ne pas poposer d’identicon au début le temps de bien analyser pourquoi polkadot et toutes les cryptos ne semblent pas voir de problème à utiliser des identidon basés sur leurs addresse+checksum, et évaluer d’abords avec un peu de recul ce que donne les autres règles anti-spam induites par la migration, avant d’en rajouter ?

Personellement je suis pour rester coller un max à ce que propose les libs substrate dans un premier temps.

Question ouverte hein, je ne sais pas.

1 Like

Un problème tout de même : la quantité d’identicones que peut posséder une personne dépend directement de sa richesse.

Donc plus on est riche, plus on a de chances de tromper les gens trop peu rigoureux avec un identicone ressemblant à un autre. Mais j’imagine que ça ne devrait pas gêner si l’UX n’incite pas à les utiliser pour reconnaître à coup sûr un compte dans un annuaire, mais plutôt pour le retrouver dans son carnet d’adresse personnel.

Les riches pourraient aussi profiter plus de cette fonctionnalité, mais bon à quoi ça servirait d’avoir 10000 identicones, une dizaine par personne devrait largement suffire, ce qui devrait être abordable par tous.

Cette proposition me convient, à condition d’avoir des comptes à usage unique peu chers.

Je ne pense pas, mais si on prévoit de faire ça plus tard il faut que les devs de clients s’accordent pour ne pas inventer d’identicones de leur côté avant que ce soit implémenté globalement…

J’en ai marre de ne pas être compris :confused:

Putain bien sûr qu’il faut réfléchir à l’UX, que c’est ultra essentiel, je suis à fond d’accord, mais justement l’UX ne pout pas et ne doit pas se calquer bêtement sur les règles de la blockchain, je dois le dire en chinois ou bien ?

Non les remarque de @1000i100 sont à côté de la plaque, je suis désole mais si on doit perdre du temps avec des bases aussi triviales on ne va pas pouvoir avancer, je crois qu’elle ne va jamais se faire cette migration si vous continuez …

Mais non justement, tu viens de le dire c’est fait pour les geeks ou les riches, qui donc savent ce qu’ils font et vérifient bien les adresses car en cas d’erreur ils perdent beaucoup d’argent.

Si je propose ce random id c’est justement car je pense qu’il est particulièrement adapté pour protéger des utilisateurs lambda non-avertis, M. tout le monde quoi.

M. tout le monde quoi n’a pas conscience de comment ça marche derrière et si on leur donne une image ils ne se fieront qu’à elle, donc elle doit impérativement être difficile à falsifier.

Sauf que non, car tu oublies le délai entre 2 générations de random id, et même avec des centaines de milliers de Ğ1 ça reste infiniment plus limité (quelques essais par heure) que de bruteforcer urne adresse (des milliards d’essais par seconde pour ce même riche qu peut se payer une machine puissante).
Et si un “riche” en génère plein ça va se voir en blockchain, donc on peut prévenir plus particulièrement la communauté, et puis fa oblige ce riche à faire des “dons” très conséquents à la communauté puisse chaque tentative implique un paiement à la trésorerie commune.

4 Likes

Ok, je suis reposé, et je ne trouve toujours pas mes question débile, donc il doit y avoir une incompréhension majeur entre nous @elois
Ce que j’ai compris :
Pour générer un nouveau porte-feuille, il faut passer par un random-id payant (qui sert de seed depuis laquelle sera dérivé la clef publique au format ss58).

  • Vu tes réactions, c’est très probablement que le random-id n’interviens pas à cet endroit, du coup, pourrais-tu clarifier cet aspect ?
  • Notamment si le random-id n’a rien à voir avec la crypto du compte porte-feuille, comment compte et random-id sont ils lié ?
  • l’identicon à pour vocation de vérifier simplement qu’il s’agit du bon compte. Si le random-id n’est pas la seed du compte, alors cette vérification ne marche qu’en requêtant la blockchain (ou proxy) pour vérifier le lien. Ce n’est pas vérifiable offline. On ne peut régénérer l’identicon depuis la ss58 (sauf à requêter pour avoir le random-id associé).

On a donc 2 cas :

  • si je comprends bien, celui que tu proposes : seed(privateKey) + ss58(pubKey) + random-id (associé à la ss58 par un document en blockchain) → conséquence : création de compte offline mais vérification identicon online
  • ce que j’avais compris : seed=random-id(privateKey) +ss58(pubKey) → conéquence : complexifie la création de compte même portefeuille (et encore plus celle d’hardware wallet), complexifie l’anonymat à la création (puisque qu’on peut raisonnablement considérer que l’auteur d’un porte-feuille de cette manière est aussi l’approvisionneur du financement de la création), en revanche, les vérifications par l’identicon peuvent être faites simplement et offline avec le gain de sécurité de ne pas pouvoir bruteforcer pour avoir des identicons proche d’un autre.

Si cette fois j’ai bien compris ce que tu proposes, ma question aux dev de wallet deviens :
Vos scénarios de vérification d’adresses ss58 sont-ils compatibles (côté connectivité et réactivité) avec la génération d’un identicon faisant suite à une requête du random-id correspondant au ss58 à vérifier ?

1 Like

D’après ce que j’ai compris ça n’a rien à voir avec la clé privée :

pubkey + blockchain → [VRF] → random_id → identicon

L’identicone se déduit donc de la clé publique et des paramètres de la VRF au moment de la génération du random_id. La clé publique reste générée hors-ligne.

Est-ce qu’un client voulant afficher un identicone doit demander à un indexeur le random_id correspondant à la clé publique, ou peut-il stocker un historique pas trop grand des résultats de VRF pour en déduire tous les random_id antérieurs ?

Si chaque affichage d’identicone nécessite un accès réseau ou un index à jour, ça fait moins envie…

2 Likes

Je n’ai malheureusement pas suivi ce sujet au moment où vous en parliez. Ce que ça m’inspire :

  • c’est une fonctionnalité supplémentaire qui n’a pas d’intérêt évident si elle n’est pas implémentée par les clients grand publics
  • ce n’est pas gênant de le garder dans le code pour l’instant même si on ne s’en sert pas dans les années à venir, mais il faut quand même le documenter

Ce n’est pas en insultant les gens qui ne comprennent pas les fonctionnalités que tu veux ajouter avant la migration que tu vas mieux être compris.

Conclusion : c’est dans le code, on garde, on s’en sert pas, tant pis, on verra plus tard si on l’utilise ou si on le vire.

1 Like

Je n’ai pas relu tout le fil, mais les identicônes me semblent pratiques nécessaires, ne serait-ce que pour réduire le risque en cas de usernames proches.

On pourrait même changer leur génération pour s’assurer que deux usernames proches vont générer deux identicônes très différentes.

Si on n’a pas d’identicônes issues de VRF mais qu’on a les usernames, rien n’empêche d’avoir à la fois une clé publique au format court identique à une autre, générant un identicône similaire, et un username quasiment identique à une lettre i ou un tiret près.

Ou alors implémenter la génération d’identicône dérivée de la clé publique uniquement, mais en s’assurant que deux clés publiques de format court similaire donnent deux identicônes très différentes.

Ou alors supprimer les usernames et ne pas inciter les gens à reconnaître un compte “visuellement” par sa clé publique ou son identicône. (ne pas les afficher)

1 Like

Mouais, toujours pas convaincu, on pourrait en discuter en vrai si tu veux. Je vois l’intérêt théorique, mais pas du tout la pertinence pratique en ce moment. Je rajoute quand même deux questions qui me sont passées par la tête entre temps :

  • est-ce qu’on change le random id quand on change la owner key ? (je propose que non)
  • est-ce qu’on pousse la logique jusqu’à pouvoir faire un virement / une certification vers un random id plutôt que vers une adresse (sauf dans le cas de la création de compte, bien entendu) ?

Mon impression générale est que c’est une challenge inutile d’implémenter des trucs compliqués côté serveur si on n’a pas les ressources pour le documenter, l’implémenter dans les libs, l’implémenter dans les clients, l’expliquer aux utilisateurs… Concrètement, ça ne sert à rien de se faire chier côté Duniter à implémenter le random id, d’émettre l’événement RandomIdAssigned si Ğecko / Cesium ne se sert pas du random id et que l’indexeur n’écoute pas l’événement. Vu les forces actuelles dans le projet, il vaut mieux viser un truc archi minimal mais fonctionnel qu’avoir des ambitions supérieures, mais qu’on ne peut pas réaliser. Je suis favorable à de la R&D quand ça concerne notre cœur de métier (monnaie libre, démocratie, toile de confiance) mais défavorable quand ça concerne des trucs généraux (sécurité, blockchain…). Même avec des bonnes idées, on n’a pas encore les ressources pour les développer et les diffuser assez vite pour qu’elles ne soient pas ré-inventées par Parity ou autre. Donc toute contribution est bienvenue, mais je ne bosserai pas dessus personnellement, et sachez que toute fonctionnalité présente mais non documentée me ralentit car cela nécessite de rétro-ingénierier le code et fouiller le forum à la recherche d’explications.

Qu’entends-tu par “nécessaire” ? On ne peut pas s’en passer ? Où sont les identicônes dans Duniter v1 ? As-tu une idée quantitative du nombre d’erreurs qui auraient pu être évitées par leur présence ?

2 Likes

Je suis de l’avis d’hugo.

Comme je l’ai déjà dit plusieurs fois, déjà sur mobile en terme d’UX ce n’est pas possible de facilement afficher de manière claire et propre sur une page de profile:

  • identicon
  • avatar
  • qrcode miniature

On ne peut pas switcher l’un vers l’autre pour des raisons de sécurité évidentes.
Donc faut faire des choix, et perso dans gecko je veux des avatars au moins pour les membres. Et un bouton qrcode bien sûr.

Ensuite, maintenant il faut bien comprendre que les adresses ss58 pour ce qui concerne les membres, ne sont plus au centre de l’identification d’un compte.
Ce sont officiellement les usernames.
Les adresses sont mouvantes à souhait (jusqu’à nouvel ordre en tout cas).

Donc sur quoi baserais-tu tes identicons si ce n’est pas sur les adresses ?
Je ne dis pas qu’il n’y a pas de solution à ça, je dis que je pense que ça sert à rien.

Je ne dis pas que j’ai l’UX parfaite en tête, très loin de là, ya tout à inventer, mais les identicons, après essaies et longues réflexions, une impasse pour moi, VRF et randomId ou non.


Tout ça confirme la nécessité de verrouiller (empêcher la confirmation d’identité je veux dire) bien plus les noms trop proches d’un autre, par toute sorte de regex.

1 Like

Si on veut pouvoir s’assurer qu’un compte est bien être le même que celui qu’il prétend être, juste en regardant sa fiche sur son téléphone ou son résultat dans une recherche par username, ça me semble nécessaire.

L’identicône ou n’importe quoi d’autre dérivé de la VRF, donc bien moins bruteforçable qu’une clé publique.

Peut-être zéro, mais on n’a encore jamais eu à ma connaissance d’attaquant compétent en informatique, ne serait-ce que pour utiliser un vanitygen.

Concrètement un attaquant peut à moindre coût rendre son compte membre presque identique à un autre :

  • presque le même username (on ne peut pas empêcher ça à moins de supprimer le username)
  • même clé publique format court (on ne peut pas empêcher ça, et afficher la clé publique entière n’aiderait pas dans tous les cas)
  • même avatar (techniquement on peut l’empêcher avec une IA de reconnaissance d’image dans l’indexeur mais ça semble une très mauvaise idée)
  • s’il y en a, presque le même identicône dérivé de la clé publique (là on peut essayer de l’améliorer mais ça risque d’être compliqué)

Solutions (non-exclusives) :

  • faire en sorte que ça ne soit pas un problème, par exemple en revoyant l’UX de recherche et faire très attention à tout compte qui n’est pas déjà dans le carnet d’adresse, mais ça va devenir très restrictif pour les utilisateurs
  • identicône ou autre identifiant VRF
  • se reposer sur la toile de confiance pour identifier les cas d’usurpation d’identité
  • recherche de ressemblances par les clients ou les indexeurs ou autres outils externes et avertissement dans les clients

J’ai l’impression que la solution VRF reste la plus simple et fiable.

1 Like

A la limite pour les simples wallets uniquement, pourquoi pas.

Au lieu de récupérer l’avatar sur le datapod, je récupère l’identicon sur duniter, et l’affiche en lieu et place de l’avatar pour tous les simples portefeuilles.
Interdiction aux wallets de définir un avatar de toute façon pour moi dans gecko pour le moment (enfin je veux dire ce que je veux faire).

Pour g1companion, si il n’y a pas d’avatar, j’utilise les 3 lettres du checksum et une couleur dérivée de la pubkey :

2 Likes

J’ai déplacé ce post de #protocols:g1v2proto à #r-d parce que cette idée est loin d’être mature.

1 Like