Zakura a publié une implémentation expérimentale qui attribue aux adresses de swap Zcash des clés de visualisation entrantes distinctes tout en préservant l'autorité de dépense du compte. Selon sa release candidate du 15 octobre, la dérivation des clés doit faire l'objet d'une revue avant l'émission d'adresses réelles.

Une adresse de remboursement peut exposer plusieurs swaps

Échanger des ZEC via NEAR Intents nécessite une adresse pour le retour des fonds non utilisés. Dans une explication technique, Adam Tucker de Zakura indique que cette adresse de remboursement blindée est enregistrée sur la blockchain publique de NEAR dès l'enregistrement du dépôt, même si aucun remboursement n'a lieu. Les swaps vers ZEC publient également l'adresse de réception.

Ces adresses peuvent sembler sans lien tout en partageant une même clé de visualisation entrante. La récupération de cette clé pourrait donc révéler des paiements reçus au-delà du swap lui-même.

L'attaque décrite nécessiterait un ordinateur quantique futur suffisamment puissant pour récupérer la clé à partir d'une adresse exposée. Il pourrait alors identifier les paiements entrants associés à cette clé, y compris les montants et les mémos. La proposition répond à ce risque de confidentialité futur plutôt qu'à une attaque déjà en cours. Et comme ces adresses sont enregistrées sur une blockchain publique, les divulgations effectuées aujourd'hui resteraient accessibles à ce type d'analyse dès l'arrivée d'une machine capable — le modèle d'exposition à long terme souvent décrit dans le secteur comme récolter maintenant, déchiffrer plus tard.

Des clés de visualisation distinctes préserveraient le compte de dépense

Zcash distingue l'autorité de visualisation de l'autorité de dépense. Les clés de visualisation sont conçues pour permettre aux détenteurs de partager un accès en lecture seule à leurs paiements entrants — pour la comptabilité ou les audits, par exemple — sans renoncer au contrôle des fonds. Sa norme de dérivation de clés de portefeuille, décrite dans ZIP 32, prend en charge la dérivation de clés et d'adresses à partir d'une seule graine, permettant aux portefeuilles de gérer plusieurs adresses sans exiger une sauvegarde distincte pour chacune.

La simple génération d'une adresse ne crée pas nécessairement une clé de visualisation entrante indépendante. La modification proposée par Zakura opère en arrière-plan de l'adresse : elle dérive une clé de visualisation distincte pour chaque remboursement de swap ou swap entrant, comme décrit dans la documentation de l'implémentation.

L'implémentation préserve l'autorité de dépense du compte. Un utilisateur pourrait dépenser les fonds reçus via ces clés de swap distinctes depuis le même compte, évitant ainsi la charge opérationnelle de répartir les soldes sur de nombreux comptes.

Dans le modèle actuel à clé partagée, la récupération d'une seule clé peut exposer les paiements entrants sur plusieurs adresses. Avec des clés de swap distinctes, la récupération de la clé de visualisation d'un swap n'exposerait que les paiements liés à cette clé, sans ouvrir automatiquement les paiements entrants sans rapport. Une clé de visualisation n'autorise pas en soi la dépense. La protection visée est plus étroite : limiter l'historique de paiement qu'une clé compromise peut révéler.

La récupération doit trouver les paiements sans révéler la propriété

Les clés distinctes posent un problème de découverte lors de la restauration d'un portefeuille. La régénération des clés à partir d'une graine n'indique pas au portefeuille lesquelles ont reçu des paiements. Tester chaque clé de swap sur l'intégralité de l'historique des transactions augmenterait le travail de récupération à chaque swap supplémentaire.

Les sorties de swap offrent un emplacement pour laisser une trace de récupération. L'implémentation proposée place un mémo chiffré dans une note appartenant à la transaction de financement de l'utilisateur. Ce mémo enregistre l'indice utilisé pour dériver la clé de remboursement. Lors de la restauration, le portefeuille peut récupérer l'indice et reconstruire la clé et l'adresse correspondantes.

Les swaps entrants nécessitent une autre approche, car le portefeuille Zcash n'a pas créé de transaction de financement dans laquelle laisser ce mémo. La conception vérifie plutôt les adresses dérivées de manière déterministe en séquence, en s'appuyant sur les registres des adresses déjà payées ou déjà divulguées au fournisseur de swap pour déterminer jusqu'où la découverte doit se poursuivre.

Pour localiser les paiements, le système de découverte par le destinataire utilise des filtres publics que le portefeuille vérifie localement. Une correspondance possible déclenche une requête de récupération privée d'informations (PIR), qui identifie la transaction concernée sans envoyer au serveur une requête lisible mentionnant l'adresse.

Le portefeuille peut ensuite déchiffrer le paiement avec sa clé de visualisation correspondante. Cela évite de faire effectuer à chaque clé récupérée une recherche distincte sur l'ensemble de la chaîne.

Les requêtes privées empêchent également qu'une série lisible de requêtes de recherche ne révèle que plusieurs adresses appartiennent au même portefeuille. Sinon, un serveur pourrait recevoir des requêtes pour l'adresse A, puis B, puis C et les associer à un seul portefeuille, compromettant une partie de la séparation créée par les nouvelles clés.

La revue et le support des portefeuilles restent inachevés

Le code expérimental ne démontre pas que les portefeuilles ont activé la fonctionnalité pour les utilisateurs ordinaires. La revue cryptographique reste en attente, et l'implémentation précise que les signers matériels doivent être qualifiés au niveau du firmware avant que les clés à usage unique ne soient activées pour les comptes matériels.

La publication technique de Zakura anticipe l'intégration dans des portefeuilles logiciels compatibles, dont Vizor, dans les semaines à venir. Il s'agit d'une estimation de développement, et non d'une date de sortie confirmée.

Ce travail est distinct des protections prévues pour janvier concernant les paiements Zcash, qui portent sur l'autorisation des paiements. La proposition de swap concerne la confidentialité de l'historique des paiements entrants blindés.

La nouvelle dérivation ne peut pas non plus supprimer les adresses déjà enregistrées publiquement. L'isolement des futures clés de swap n'effacerait pas les divulgations antérieures liées à une clé de visualisation partagée existante.

Le travail de livraison restant est précis : examiner la dérivation, intégrer la découverte des paiements et la restauration, et qualifier les signers pris en charge. Ces étapes doivent être achevées avant que les utilisateurs puissent compter sur la séparation proposée dans un portefeuille publié.

Cet article est fourni à titre informatif uniquement. La fonctionnalité proposée est expérimentale et nécessite des revues supplémentaires avant toute utilisation en production.

Cet article est initialement paru sur Coindoo.