Zakura hat eine experimentelle Implementierung veröffentlicht, die Zcash-Swap-Adressen separate eingehende Viewing Keys zuweist und dabei die Ausgabeberechtigung des Kontos erhält. Laut dem Release Candidate vom 15. Oktober muss die Schlüsselableitung geprüft werden, bevor Live-Adressen ausgegeben werden.

Eine Refund-Adresse kann mehr als einen Swap offenlegen

Der Umtausch von ZEC über NEAR Intents erfordert eine Adresse für die Rücküberweisung ungenutzter Mittel. In einer technischen Erläuterung erklärt Adam Tucker von Zakura, dass diese geschützte Refund-Adresse bei Registrierung der Einzahlung auf NEARs öffentlicher Blockchain aufgezeichnet wird, auch wenn keine Rückerstattung erfolgt. Swaps in ZEC veröffentlichen zudem die Empfangsadresse.

Diese Adressen können unabhängig voneinander erscheinen, während sie sich einen eingehenden Viewing Key teilen. Die Wiederherstellung dieses Schlüssels könnte daher Zahlungseingänge über den eigentlichen Swap hinaus offenlegen.

Der beschriebene Angriff würde einen ausreichend leistungsfähigen zukünftigen Quantencomputer erfordern, um den Schlüssel aus einer exponierten Adresse zu rekonstruieren. Dieser könnte dann eingehende Zahlungen im Zusammenhang mit diesem Schlüssel identifizieren, einschließlich Beträgen und Memos. Der Vorschlag richtet sich gegen dieses künftige Vertraulichkeitsrisiko und berichtet nicht von einem bereits laufenden Angriff. Und da diese Adressen auf einer öffentlichen Blockchain aufgezeichnet sind, blieben heute offenlegte Daten für eine derartige Analyse verfügbar, sobald ein leistungsfähiger Rechner verfügbar ist – das Langfrist-Exposure-Muster, das in der Branche häufig als harvest now, decrypt later beschrieben.

Separate Viewing Keys würden das Ausgabenkonto intakt halten

Zcash unterscheidet zwischen Viewing-Berechtigung und Ausgabeberechtigung. Viewing Keys sollen Inhabern ermöglichen, Lesezugriff auf ihre eingehenden Zahlungen zu teilen – etwa für Buchhaltung oder Audits –, ohne die Kontrolle über die Mittel aufzugeben. Der Wallet-Schlüsselableitungsstandard, beschrieben in ZIP 32, unterstützt die Ableitung von Schlüsseln und Adressen aus einem einzigen Seed, sodass Wallets mehrere Adressen verwalten können, ohne für jede ein separates Backup zu benötigen.

Das bloße Erzeugen einer weiteren Adresse erzeugt nicht zwangsläufig einen unabhängigen eingehenden Viewing Key. Zakuras vorgeschlagene Änderung greift hinter der Adresse an: Sie leitet für jede Swap-Rückerstattung oder jeden eingehenden Swap einen separaten Viewing Key ab, wie in der Dokumentation der Implementierung beschrieben.

Die Implementierung erhält die Ausgabeberechtigung des Kontos. Ein Nutzer könnte über diese separaten Swap-Schlüssel empfangene Mittel aus demselben Konto ausgeben, ohne den operativen Aufwand einer Aufteilung des Guthabens auf viele Konten.

Im aktuellen Shared-Key-Modell kann die Wiederherstellung eines Schlüssels eingehende Zahlungen über mehrere Adressen hinweg offenlegen. Mit separaten Swap-Schlüsseln würde die Wiederherstellung des Viewing Keys eines Swaps nur die mit diesem Schlüssel verknüpften Zahlungseingänge offenlegen, ohne automatisch unabhängige eingehende Zahlungen preiszugeben. Ein Viewing Key autorisiert selbst keine Ausgaben. Der beabsichtigte Schutz ist enger gefasst: die Zahlungshistorie begrenzen, die ein einziger kompromittierter Schlüssel offenlegen kann.

Wiederherstellung muss Zahlungen finden, ohne Eigentum offenzulegen

Separate Schlüssel schaffen ein Auffindbarkeitsproblem bei der Wiederherstellung einer Wallet. Die Neuerzeugung von Schlüsseln aus einem Seed verrät der Wallet nicht, welche davon Zahlungen erhalten haben. Der Versuch, jeden Swap-Schlüssel gegen die gesamte Transaktionshistorie zu prüfen, würde den Wiederherstellungsaufwand mit jedem weiteren Swap erhöhen.

Ausgehende Swaps bieten einen Ort für einen Wiederherstellungsdatensatz. Die vorgeschlagene Implementierung platziert ein verschlüsseltes Memo in einer Note der Funding-Transaktion des Nutzers. Dieses Memo speichert den Index, der zur Ableitung des Refund-Schlüssels verwendet wurde. Bei der Wiederherstellung kann die Wallet den Index abrufen und den entsprechenden Schlüssel sowie Adresse rekonstruieren.

Eingehende Swaps erfordern einen anderen Ansatz, da die Zcash-Wallet keine Funding-Transaktion erstellt hat, in der ein solches Memo hinterlegt werden könnte. Das Design prüft stattdessen deterministisch abgeleitete Adressen der Reihe nach und nutzt Aufzeichnungen über bezahlte oder bereits gegenüber dem Swap-Anbieter offengelegte Adressen, um festzulegen, wie weit die Suche fortgesetzt werden muss.

Um Zahlungen zu finden, verwendet das Receiver-Discovery-System öffentliche Filter, die die Wallet lokal prüft. Bei einer möglichen Übereinstimmung folgt eine Private-Information-Retrieval-Anfrage (PIR), die die relevante Transaktion identifiziert, ohne eine lesbare Abfrage mit Nennung der Adresse an den Server zu senden.

Die Wallet kann die Zahlung anschließend mit dem entsprechenden Viewing Key entschlüsseln. So muss jeder wiederhergestellte Schlüssel nicht separat die gesamte Chain durchsuchen.

Private Abfragen verhindern zudem, dass eine lesbare Reihe von Suchanfragen offenlegt, dass mehrere Adressen zusammengehören. Andernfalls könnte ein Server Anfragen für Adresse A, dann B, dann C erhalten und sie einer Wallet zuordnen, was einen Teil der Trennung durch die neuen Schlüssel untergraben würde.

Prüfung und Wallet-Unterstützung sind unvollendet

Der experimentelle Code belegt nicht, dass Wallets die Funktion für gewöhnliche Nutzer aktiviert haben. Die kryptografische Prüfung steht noch aus, und die Implementierung schreibt vor, dass Hardware-Signer eine Firmware-Qualifizierung benötigen, bevor Einmalschlüssel für Hardware-Konten aktiviert werden.

Zakuras Engineering-Beitrag erwartet die Integration in kompatible Software-Wallets, darunter Vizor, in den kommenden Wochen. Dies ist eine Entwicklungseinschätzung, kein bestätigtes Veröffentlichungsdatum.

Diese Arbeit ist unabhängig von den für Januar geplanten Schutzmaßnahmen für Zcash-Zahlungen, die die Zahlungsautorisierung betreffen. Der Swap-Vorschlag betrifft die Privatsphäre der geschützten eingehenden Zahlungshistorie.

Die neue Schlüsselableitung kann zudem bereits öffentlich aufgezeichnete Adressen nicht entfernen. Die Isolierung künftiger Swap-Schlüssel würde frühere Offenlegungen, die mit einem bestehenden gemeinsamen Viewing Key verknüpft sind, nicht rückgängig machen.

Die verbleibende Arbeit ist konkret: die Schlüsselableitung prüfen, Zahlungs-Auffindung und Wiederherstellung integrieren und unterstützte Signer qualifizieren. Diese Schritte müssen abgeschlossen sein, bevor sich Nutzer in einer veröffentlichten Wallet auf die vorgeschlagene Trennung verlassen können.

Dieser Artikel dient ausschließlich Informationszwecken. Die vorgeschlagene Funktion ist experimentell und erfordert weitere Prüfung vor dem Live-Einsatz.
Dieser Artikel erschien ursprünglich auf Coindoo.