Hash de l'identité / identités anonymes

Clients
1

Bonjour,

Je fais suite à une discussion sur un réseau asocial, avec entre autres @vincentux. Je lance l’idée pour laisser une trace.

Problème

Aujourd’hui, les identités sont enregistrées en clair dans Duniter. Une conséquence est que de nombreux états-civils se retrouvent enregistrés à jamais dans la BC, même si la personne a révoqué son compte, ce qui est une atteinte certaine à la vie privée.

#Lesgens pourraient utiliser des pseudos. Mais une partie des utilisateurs, en particulier celleux qui ne sont pas à l’aise avec Internet, donc les plus vulnérables, mettent leur état civil en clair.

Proposition

Les clients pourraient, au lieu d’envoyer l’identité en clair, envoyer uniquement un hash.

Conséquences :

  • une personne extérieure ne pourra pas faire le lien entre l’identité Duniter (hash) et un pseudo/etat civil. elle pourra faire le lien identité/compte seulement si elle a l’identité exacte.
  • une identité attaquante peut être retrouvée de proche en proche, en indiquant les hashs d’identité et les clefs publiques correspondantes. La TdC fonctionne toujours.
  • Pour effectuer une certification, un.e membre devra avoir la clef publique ET l’identité exacte.

Est-ce faisable ?

C’est là que mes compétences s’arrêtent. Je lis que (source ):

DUBP does not rely on any particular identity format, which remains implementation free. Identity simply has to be a string of length between 2 and 100 characters avoiding usage of line ending characters.

Un algo de hash produit-il des hash inférieurs à 100 caractères ? Si oui, alors les clients peuvent adapter cette proposition sans modification de Duniter.

Sinon, cette proposition implique une évolution de DUBP.

Problèmes

  • Dans la mesure où Duniter ne gère pas la casse, une usurpation d’identité est possible en utilisant le même hash avec une casse différente. Ceci se résout en ayant un standard d’identité à casse minuscule ou majuscule.

  • une telle identité-hash n’est pas réellement anonyme, elle est pseudonyme : si on sait ce qu’on cherche, on le trouve. Mais on ne peut pas tomber sur un état civil par hasard dans la BC si on ne le cherche pas.

Est-ce que j’oublie des choses ?

A vous de me dire.

2

Oui, SHA512 en base 58 fait 44 caractères, comme les clés publiques.

Pour limiter le problème de l’usurpation, il faut que les clients permettent de vérifier l’identité, avec un champ où on peut taper le pseudo pour le hasher.

1 Like
3

Ca me fait penser à cette idée que j’avais suggéré il y a quelques temps : Preuves d'identifications décentralisées

4

Pourquoi faire ? Pourquoi le hash de l’identité ne suffirait pas ?
De plus, cela n’aurait de sens que s’il était possible d’inscrire en blockchain une preuve que je connais l’identité réelle que je certifie, or si je la dévoile alors la feature perd son sens. La seule solution serait de zéro konwledge mais c’est beaucoup trop lourd pour un usage qui ne me semble pas justifié, pourquoi devrait-on avoir la preuve qu’un certificateur connaît l’identité réelle derrière le hash ?

Il y a bien plus simple, et plus souhaitable: contresigner les certifications, ce qui va être de toute façon nécessaire pour limiter le nombre de certifications max reçus, lire a ce sujet l’échange avec @Lucas et @cgeek : https://forum.duniter.org/t/attaque-sybil/7191/7?u=elois

Non ça se résout en modifiant le protocole DUBP et en imposant une casse particulière dans le document Identité.

Qui stocke l’identité réelle et ou ?
Perso je suis attaché au fait que l’utilisateur lambda n’est rien à stocker, je trouve que cela simplifie grandement l’usage. Ça pourrait être un service tiers tel qu’un pod Cesium+.

En effet, Duniter s’en fout que le username soit un hash, pour lui ça ne change rien, on pourrait même se passer de username et se baser uniquement sur la clé publique :slight_smile:

Non tu confonds avec SHA256. En effet 44 caractères en base58 permettent de représenter “seulement” 32 octets (soit 256 bits) et non pas 64 (soit 512 bits).

5

@Elois, ma proposition vise essentiellement les clients, et n’a comme objectif que d’éviter que des états-civils soient écrits en clair dans la BC.

Le hash de l’identité pourrait suffire. Mais il me semble intéressant, pour respecter la vie privée des utilisateurices, que les clients proposent un mode d’inscription et de certification (par défaut ou non) où l’identité Duniter est le hash de leur pseudo/etat civil. Ceci n’empêcherait personne d’enregistrer son pseudo en clair dans la BC s’iel le souhaite.

Effectivement, côté noeud, on s’en fout si l’utilisateurice entre un hash ou entre une ID qui ensuite sera hashé. Mais coté client et expérience utilisateurice, ce n’est pas la même chose de certifier AchilleTalon ou de certifier HjkgHJKNbj…

Par contre, je vois que cette proposition peut mener à des conflits : il peut y avoir enregistré en même temps en BC :

  • l’identité AchilleTalon
  • l’identité hash(AchilleTalon)

On a pas besoin d’en avoir la preuve. C’est juste que ma grand-mère comprendra mieux ce qui se passe si elle écrit mon nom plutôt que si elle copie-colle un hash.

Je ne vois pas en quoi ça change quoi que ce soit à ce que des états-civils soient enregistrés en blockchain.

Question de la casse :
Si les clients acceptent que seules les hash-ID en minuscules sont valables, alors les hash-ID majuscules seront considérés comme des identités non hashées, tout simplement.

Par ailleurs, des hash écrits en base58 comprennent majuscules et minuscules, dont il ne peut pas y avoir d’usurpation d’identité par changement de la casse.

La personne qui a créé son identité, qui la stocke dans sa tête et la communique à ses connaissances. Ah oui, c’est là le point faible, un truc de plus à se souvenir. OK.

Oui, ben du coup 512bits → 88 caractères, c’est encore bon.

edit :
Issue créée pour faire ce qui me semble le minimum nécessaire sur Cesium.

6

Donc pour faire un cahier des charges concret, il faut que les clients implémentent :

  • lors de la génération du document identité, demander si on veut le mode anonyme. Si oui, hasher le nom entré par l’utilisateur.
  • lors de la certification de l’identité entrée, chercher entrée et hash(entrée). Si les deux existent, demander confirmation. (ou alors demander si on veut le mode anonyme avant, mais c’est moins Michu-friendly)
  • un carnet d’identités local, remplaçant les identités hashées connues par l’identité en clair (non nécessaire si on fait plutôt un carnet d’adresses, à moins qu’on veuille vraiment séparer adresse et identité dans l’interface)
2 Likes
7

@matograine la source de notre quiproquo est cette phrase. Si tu dis “Pour effectuer A, un membre doit avoir B”, et que l’acte A est un acte inscrit en blockchain (ici une certification), alors cela implique nécessairement qu’il doit exister une preuve publique vérifiable de B.

Une formulation conforme aurait été:

Sur l’interface utilisateur, on doit pouvoir trouver une identité par son hash et par son nom réel (avant hashage).

Ce que l’on certifie c’est une identité, donc pour effectuer une certification, il faut le document d’identité cible, point. Ta proposition impacte la manière de générer ce document identité et la manière de la trouver par recherche, elle n’impacte en rien les certifications.
Le fait que tu abordes les certifications m’amenais nécessairement a conclure que ta proposition avait un impact sur celle-ci, ma longue réponse avait pour but de montrer l’inutilité de cet impact.

Il s’agit d’une alternative pour ne pas avoir besoin de la preuve de connaissance de l’état civil réel par le certificateur, preuve que je pensais que tu exigeais vu ta phrase citée au-dessus.

Si tu veux que l’on se comprenne bien, il te faut être vigilent dès que tu dis “Pour faire X, un membre devra Y”. Dès que tu exprimes une obligation, demande-toi toujours: “doit-on en avoir une preuve vérifiable dans le protocole ?”
Si la réponse est non, alors ça ne peut pas être une obligation, et donc la formulation est incorrecte.

En effet, dans ce cas je recommande aux logiciels client d’utiliser la base 58 plutôt que la base 16 :slight_smile:

Je n’ai jamais dit qu’il fallait 512 bits, c’est @tuxmain qui a parlé de SHA512, je pense au contraire que c’est inutile, je recommande plutôt l’utilisation de SHA256 :wink:

8

L’avantage du username, c’est que si un jour DUPB implémente le changement de trousseau cryptographique alors le username pourra servir d’invariant.

1 Like