Zakura ha pubblicato un'implementazione sperimentale che assegna agli indirizzi di swap Zcash chiavi di visualizzazione in entrata separate, mantenendo invariata l'autorità di spesa dell'account. Secondo la release candidate del 15 ottobre, la derivazione delle chiavi richiede una revisione prima dell'emissione di indirizzi reali.

Un indirizzo di rimborso può esporre più di uno swap

Effettuare swap in ZEC tramite NEAR Intents richiede un indirizzo per la restituzione dei fondi inutilizzati. In una spiegazione tecnica, Adam Tucker di Zakura spiega che questo indirizzo di rimborso shielded viene registrato sulla blockchain pubblica di NEAR al momento della registrazione del deposito, anche se nessun rimborso viene poi eseguito. Anche gli swap verso ZEC pubblicano l'indirizzo di ricezione.

Questi indirizzi possono apparire non collegati tra loro pur condividendo una stessa chiave di visualizzazione in entrata. Il recupero di tale chiave potrebbe quindi rivelare ricevute che vanno oltre lo swap stesso.

L'attacco descritto richiederebbe un futuro computer quantistico sufficientemente potente per recuperare la chiave da un indirizzo esposto. Potrebbe quindi identificare i pagamenti in entrata associati a quella chiave, compresi importi e memo. La proposta affronta un rischio di riservatezza futuro, piuttosto che segnalare un attacco già in corso. E poiché tali indirizzi sono registrati su una blockchain pubblica, le esposizioni effettuate oggi resterebbero disponibili per questo tipo di analisi quando arriverà una macchina capace — il modello di esposizione a lungo termine spesso descritto nel settore come harvest now, decrypt later.

Chiavi diizzazione separate manterrebbero intatto l'account di spesa

Zcash distingue l'autorità di visualizzazione dall'autorità di spesa. Le chiavi di visualizzazione sono progettate per consentire ai titolari di condividere l'accesso in sola lettura ai propri pagamenti in entrata — per contabilità o audit, ad esempio — senza rinunciare al controllo dei fondi. Il suo standard di derivazione delle chiavi per wallet, descritto in ZIP 32, supporta la derivazione di chiavi e indirizzi da un singolo seed, permettendo ai wallet di gestire più indirizzi senza richiedere un backup separato per ciascuno.

La semplice generazione di un nuovo indirizzo non crea necessariamente una chiave di visualizzazione in entrata indipendente. La modifica proposta da Zakura opera dietro l'indirizzo: deriva una chiave di visualizzazione separata per ogni rimborso di swap o swap in entrata, come descritto nella documentazione dell'implementazione.

L'implementazione preserva l'autorità di spesa dell'account. Un utente potrebbe spendere i fondi ricevuti tramite quelle chiavi di swap separate dallo stesso account, evitando l'onere operativo di suddividere i saldi su molti account.

Con l'attuale modello a chiave condivisa, il recupero di una chiave può esporre i pagamenti in entrata su più indirizzi. Con chiavi di swap separate, il recupero della chiave di visualizzazione di uno swap esporrebbe le ricevute legate a quella chiave senza aprire automaticamente i pagamenti in entrata non correlati. Una chiave di visualizzazione non autorizza di per sé la spesa. La protezione prevista è più limitata: limitare lo storico dei pagamenti che una singola chiave compromessa può rivelare.

Il recupero deve trovare i pagamenti senza rivelare la proprietà

Le chiavi separate creano un problema di individuazione quando un wallet viene ripristinato. Rigenerare le chiavi da un seed non indica al wallet quali abbiano ricevuto pagamenti. Provare ogni chiave di swap sull'intero storico delle transazioni aumenterebbe il lavoro di recupero a ogni swap aggiuntivo.

Gli swap in uscita offrono un punto in cui lasciare un record di recupero. L'implementazione proposta inserisce un memo crittografato in una nota appartenente alla transazione di finanziamento dell'utente. Quel memo registra l'indice utilizzato per derivare la chiave di rimborso. Durante il ripristino, il wallet può recuperare l'indice e ricostruire la chiave e l'indirizzo corrispondenti.

Gli swap in entrata richiedono un approccio diverso, poiché il wallet Zcash non ha creato una transazione di finanziamento in cui lasciare tale memo. Il progetto verifica invece in sequenza gli indirizzi derivati in modo deterministico, utilizzando i record degli indiriz pagati o già divulgati al fornitore di swap per determinare fino a dove proseguire l'individuazione.

Per individuare i pagamenti, il sistema di individuazione del ricevente utilizza filtri pubblici che il wallet verifica localmente. Una possibile corrispondenza genera una richiesta di private information retrieval, o PIR, che identifica la transazione rilevante senza inviare al server una query leggibile che nomini l'indirizzo.

Il wallet può quindi decrittare il pagamento con la corrispondente chiave di visualizzazione. Questo evita di far eseguire a ogni chiave recuperata una ricerca separata sull'intera blockchain.

Le query private impediscono inoltre che una serie leggibile di richieste di ricerca riveli che più indirizzi appartengano allo stesso wallet. In caso contrario, un server potrebbe ricevere richieste per l'indirizzo A, poi B, poi C e associarle a un unico wallet, vanificendo parte della separazione creata dalle nuove chiavi.

Revisione e supporto dei wallet restano incompleti

Il codice sperimentale non dimostra che i wallet abbiano abilitato la funzione per gli utenti ordinari. La revisione crittografica resta pendente, e l'implementazione specifica che i firmatari hardware necessitano di una qualificazione del firmware prima che le chiavi monouso siano abilitate per gli account hardware.

Il post tecnico di Zakura prevede l'integrazione nei software wallet compatibili, incluso Vizor, nelle prossime settimane. Si tratta di una stima di sviluppo, non di una data di rilascio confermata.

Questo lavoro è separato dalle protezioni previste per gennaio per i pagamenti Zcash, che riguardano l'autorizzazione dei pagamenti. La proposta sugli swap riguarda la privacy dello storico dei pagamenti in entrata shielded.

La nuova derivazione non può inoltre rimuovere gli indirizzi già registrati pubblicamente. Isolare le future chiavi di swap non cancellerebbe le divulgazioni precedenti legate a una chiave di visualizzazione condivisa esistente.

Il lavoro di consegna rimanente è specifico: revisionare la derivazione, integrare l'individuazione dei pagamenti e il ripristino, e qualificare i firmatari supportati. Questi passaggi devono essere completati prima che gli utenti possano fare affidamento sulla separazione proposta in un wallet rilasciato.

Questo articolo è fornito a solo scopo informativo. La funzione proposta è sperimentale e richiede ulteriori revisioni prima dell'uso in produzione.

Questo articolo è apparso originariamente su Coindoo.