Ceci est un éditorial d’opinion de Shinobi, un éducateur autodidacte dans l’espace Bitcoin et hôte de podcast Bitcoin orienté technologie.
Je suggère, avant de lire ceci, que vous lisiez l’article précédent que j’ai écrit expliquant ce qu’est Nostr et comment cela fonctionne à un niveau élevé. Vous devriez alors avoir une bonne idée de la conception de base du système à ce stade, alors examinons maintenant les problèmes susceptibles de survenir au fur et à mesure de son adoption. La plate-forme devenant populaire pour la communauté Bitcoin, ces problèmes doivent être pris en compte.
Comme je l’ai expliqué dans l’article précédent, les paires de clés utilisateur public/privé font partie intégrante du fonctionnement de Nostr en tant que protocole. Il n’y a aucun nom d’utilisateur, ni aucun type d’identifiant contrôlé par un serveur relais, à associer à des utilisateurs individuels. Ce sont simplement les clés de ces utilisateurs qui sont entièrement sous leur contrôle.
Cela fonctionne comme une liaison étroite entre l’utilisateur réel et la façon dont il est identifié par les autres, ce qui empêche tout serveur relais de dissocier ces deux choses, c’est-à-dire de donner l’identifiant de quelqu’un à un autre utilisateur. Cela résout l’un des plus grands problèmes fondamentaux des plateformes utilisées pour la communication entre les personnes : le manque de contrôle sur l’identité des utilisateurs. Mais cela introduit aussi tous les problèmes de gestion de clés auxquels se heurte quelqu’un possédant une clé privée. Les clés peuvent être perdues et les clés peuvent être compromises et si un tel événement devait se produire, les utilisateurs n’ont personne à qui s’adresser pour obtenir de l’aide, tout comme avec Bitcoin. Il n’y a pas de support client pour récupérer quoi que ce soit. Tu le perds, c’est tout.
Cela va inévitablement nécessiter un schéma permettant aux utilisateurs de passer d’une paire de clés à une autre d’une manière vérifiable et détectable pour les autres utilisateurs avec lesquels ils interagissent via le protocole. L’ensemble du protocole est basé sur la preuve qu’un événement provient d’un utilisateur spécifique (clé d’identité), de sorte que toutes ces garanties disparaissent une fois que les clés de quelqu’un sont compromises.
Comment vas-tu prendre ça en charge? Allez juste voir leur compte Twitter ? Eh bien, ce n’est pas un système très décentralisé, en fin de compte, si vous avez besoin d’utiliser une plate-forme centralisée où ils ne contrôlent pas leur identité pour vérifier leur identité Nostr.
D’autres utilisateurs attestent-ils de la légitimité d’une nouvelle clé ? Cela ne résout pas les situations telles que les compromis de clé de masse ou le fait de ne pas connaître suffisamment bien quelqu’un proche pour faire confiance à leur attestation.
Nostr a besoin d’un schéma cryptographique réel liant la rotation d’une clé à une autre. Il y a une proposition du développeur fiatjaf pour un schéma de base qui pourrait potentiellement résoudre ce problème. L’idée de base serait de prendre un long ensemble d’adresses dérivées d’une seule graine principale et de créer un ensemble de clés « ajustées » similaires à la façon dont les arbres Taproot sont engagés dans une clé Bitcoin. Taproot prend la racine de l’arbre Merkle de l’arbre Taproot et « l’ajoute » à la clé publique pour créer une nouvelle clé publique. Cela peut être reproduit en ajoutant cette racine d’arborescence Merkle à la clé privée afin d’obtenir la clé privée correspondante pour la nouvelle clé publique. L’idée de Fiatjaf est d’enchaîner les engagements en remontant de la fin au début afin que chaque clé modifiée contienne en fait une preuve que la prochaine clé modifiée a été utilisée pour la créer.
Alors, imaginez commencer par la touche Z, la dernière de la chaîne. Vous modifieriez cela avec quelque chose, puis reviendriez en arrière et créeriez une version modifiée de la clé Y en utilisant la clé Z modifiée (Z’ + Y = Y’). À partir de là, vous prendriez Y’ et l’utiliseriez ensuite pour modifier X (Y’ + X = X’). Vous feriez cela jusqu’à la clé A, pour obtenir A’, et à partir de là, commenceriez à utiliser cette clé. Lorsqu’il est compromis, l’utilisateur peut diffuser un événement contenant la clé non modifiée A et la clé modifiée B’. Cela contiendrait toutes les données nécessaires pour montrer que B’ a été utilisé pour générer A’, et les utilisateurs pourraient immédiatement arrêter de suivre A’ et suivre B’ à la place. Ils sauraient définitivement que B’ est la clé suivante de cet utilisateur et qu’ils devraient la suivre à la place.
Cette proposition a encore quelques problèmes cependant. Tout d’abord, vous devez générer toutes les clés que vous utiliseriez à l’avance et il n’y a aucun moyen de faire pivoter vers un tout nouveau jeu de clés. Cela pourrait être résolu en s’engageant sur une clé principale dans ce schéma qui pourrait légaliser de telles rotations, ou simplement en générant un très grand ensemble de clés dès le début. L’une ou l’autre voie serait une voie valable à suivre, mais nécessiterait en fin de compte de conserver une clé racine ou un matériel de clé en toute sécurité et d’exposer uniquement les raccourcis clavier individuels aux clients Nostr.
Ce schéma, cependant, ne fait rien pour protéger les utilisateurs ou offrir un mécanisme de récupération d’identité dans le cas où le matériel de clé racine est perdu ou est lui-même compromis. Maintenant, cela ne veut pas dire qu’il n’y a aucun avantage au schéma de fiatjaf, il y en a absolument, mais il est important de souligner qu’aucune solution ne résout tous les problèmes.
Pour pontifier un peu sur les solutions potentielles ici, imaginez au lieu d’une chaîne de clés modifiées comme il le propose, qu’une clé est modifiée avec une clé froide principale qui doit également être utilisée pour signer l’événement tournant d’une clé à l’autre. Vous avez la clé A’, qui est dérivée en ajoutant A et M (la clé principale), et l’événement de rotation serait A, M et B’ (généré en ajoutant B et M) avec une signature de M. M pourrait être un clé de seuil multisig – deux sur trois, trois sur cinq, etc. Cela pourrait potentiellement ajouter de la redondance contre la perte et fournir un mécanisme sécurisé pour la rotation des clés. Cela ouvre également la porte à l’utilisation de services pour aider à la récupération ou à la diffusion de certaines de ces clés à des amis de confiance. Il offre la même flexibilité que le multisig avec Bitcoin lui-même.
NIP26 est également une proposition qui pourrait être très utile pour traiter ce problème. Cela spécifie une extension de protocole aux événements permettant à une signature d’une clé d’autoriser une autre clé à publier des événements en son nom. Le « jeton », ou preuve de signature de délégation, serait alors inclus dans tous les événements postés par la deuxième clé publique au nom de la première. Il peut même être limité dans le temps afin que les jetons de délégation expirent automatiquement et doivent être renouvelés.
En fin de compte, quelle que soit la manière dont il est résolu, ce problème a à résoudre pour Nostr à long terme. Un protocole entièrement basé sur des paires de clés publiques/privées utilisées comme identités ne peut pas gagner du terrain et être adopté si l’intégrité de ces identités ne peut pas être protégée et maintenue pour les utilisateurs. Cela se résumera finalement à devoir utiliser constamment des plates-formes hors bande et centralisées pour vérifier de nouvelles clés et coordonner les personnes suivant votre nouvelle identité lorsque quelque chose est perdu ou compromis, et à ce stade, ces autres plates-formes deviennent un moyen de semer la confusion. et pratiquer la censure.
Les problèmes de gestion des clés et de sécurité sont de gros problèmes avec un très grand espace de conception plein de compromis et de points faibles, mais ce sont des problèmes qui devront être résolus dans le contexte de Nostr pour que cela fonctionne. Dans mon prochain article, je résumerai certains problèmes que je vois surgir en ce qui concerne l’architecture du serveur relais et les problèmes de mise à l’échelle auxquels les développeurs de Nostr devront faire face étant donné les structures de données de base sur lesquelles Nostr est construit.
Pour tous ceux qui lisent et se demandent pourquoi je n’ai pas mentionné les identifiants décentralisés (DID): Oui, c’est une solution potentielle à ces problèmes qui, à mon avis, est assez complète. Cependant, les développeurs de Nostr semblent très hésitants à intégrer les DID dans le protocole ou les clients car cela créerait des dépendances externes en dehors du protocole Nostr. Si vous n’êtes pas familier avec le fonctionnement technique des DID et que vous êtes intéressé, cet article de Level 39 est un résumé très bien écrit de leur fonctionnement.
Ceci est un article invité de Shinobi. Les opinions exprimées sont entièrement les leurs et ne reflètent pas nécessairement celles de BTC Inc ou de Bitcoin Magazine.
