On ne peut pas avoir ce genre d’attaque sur un protocole qui accède à la données par son contenu (son hash) comme ipfs, une blochain ou un client à ce type de stockage.
oui
De toute façon, ce sont des clefs de chiffrage qui sont utilisées comme « identifiant » partout… Le problème c’est que ces clefs ne sont pas reliées les unes aux autres (ou de façon ambiguë)
Ce champs dans Gchange relie dans le mauvais sens la clef commerciale avec la clef identité numérique…
Il aurait mieux fallu indiquer cette clef dans Cesium+ (que Gchange+ récupère) pour créer une relation équivoque.
G1Compagnion, g1.quest, g1nkgo et autres application clientes sont reliées au même « espace crypto » exprimé dans duniter, dans Cesium+ et dans GChange+ et ajoutent des clefs éparpillées (qui se relient lorsqu’elles ont une interaction chiffrée) … Pour une utilisation plus simple, ce serait bien de faire le ménage la dedans, privilégier l’utilisation de clefs dérivées sur les clients plutôt que d’en créer aléatoirement ou de réutiliser la même partout.
L’avantage de clefs dérivées c’est qu’il suffit de conserver la clef maitre uniquement pour les recréer toutes et retrouver les données qui y ont été inscrites (par le contenu)