AktualnościKryptoZcash zamierza chronić historię płatności przed atakami kwantowymi

Zcash zamierza chronić historię płatności przed atakami kwantowymi

Autor: Coindoo·

Najważniejsze informacje

  • •Zakura opublikowała 15 października release candidate eksperymentalnego narzędzia, które wyznacza unikalny klucz podglądu przychodzących płatności dla każdego zwrotu swapowego lub przychodzącego swapu Zcash.
  • •Adresy używane do swapów ZEC przez NEAR Intents są zapisywane w publicznym blockchainie NEAR, co tworzy wieloletnią ekspozycję typu „harvest now, decrypt later”, jeśli przyszły komputer kwantowy odzyska współdzielony klucz podglądu.
  • •Projekt zachowuje uprawnienia do wydawania środków, pozwalając użytkownikom wydawać środki otrzymane pod oddzielnymi kluczami swapowymi z tego samego konta, bez dzielenia sald.
  • •Przywracanie portfela wykorzystuje zaszyfrowane notatki w transakcjach finansujących dla swapów wychodzących oraz skanowanie deterministycznych adresów połączone z prywatnym pobieraniem informacji dla swapów przychodzących.
  • •Implementacja pozostaje eksperymentalna: przed użyciem produkcyjnym wymagane są recenzja kryptograficzna, integracja portfeli, w tym przewidywane wsparcie Vizor, oraz kwalifikacja firmware signerów sprzętowych.
Zcash zamierza chronić historię płatności przed atakami kwantowymi

Zakura opublikowała eksperymentalną implementację, która przyznaje adresom swapowym Zcash oddzielne klucze podglądu przychodzących płatności, zachowując jednocześnie uprawnienia konta do wydawania środków. Zgodnie z release candidate z 15 października pochodzenie kluczy wymaga recenzji, zanim zostaną wyemitowane adresy produkcyjne.

Adres zwrotny może ujawnić więcej niż jeden swap

Zamiana ZEC przez NEAR Intents wymaga adresu do zwrotu niewykorzystanych środków. Zgodnie z wyjaśnieniem inżynierskim Adama Tuckera z Zakury ten shielded adres zwrotny jest zapisywany w publicznym blockchainie NEAR w momencie rejestracji depozytu, nawet jeśli zwrot nie następuje. Swapy do ZEC publikują również adres odbiorczy.

Te adresy mogą wyglądać na niezwiązane, a mimo to współdzielić jeden klucz podglądu przychodzących płatności. Odzyskanie tego klucza mogłoby zatem ujawnić wpływy wykraczające poza sam swap.

Opisany atak wymłby dostatecznie wydajnego, przyszłego komputera kwantowego, aby odzyskać klucz z ujawnionego adresu. Mógłby on następnie zidentyfikować płatności przychodzące powiązane z tym kluczem, w tym kwoty i notatki. Propozycja dotyczy przyszłego ryzyka dla poufności, a nie zgłasza ataku już trwającego. A ponieważ te adresy są zapisane w publicznym blockchainie, ujawnienia dokonane dziś pozostaną dostępne dla tego rodzaju analizy, gdy tylko pojawi się odpowiednia maszyna — to wieloletni wzorzec ekspozycji opisywany w branży jako harvest now, decrypt later.

Oddzielne klucze podglądu zachowałyby konto wydawania środków

Zcash rozróżnia uprawnienia podglądu od uprawnień do wydawania środków. Klucze podglądu są zaprojektowane tak, aby posiadacze mogli udostępniać dostęp tylko do odczytu do swoich płatności przychodzących — na przykład dla celów księgowych lub audytów — bez oddawania kontroli nad środkami. Standard pochodzenia kluczy portfela, opisany w ZIP 32, obsługuje wyznaczanie kluczy i adresów z pojedynczego seeda, co pozwala portfelom zarządzać wieloma adresami bez wymagania osobnej kopii zapasowej dla każdego z nich.

Samo wygenerowanie kolejnego adresu niekoniecznie tworzy niezależny klucz podglądu przychodzących płatności. Proponowana zmiana Zakury działa za adresem: wyznacza oddzielny klucz podglądu dla każdego zwrotu swapowego lub przychodzącego swapu, zgodnie z dokumentacją implementacji.

Implementacja zachowuje uprawnienia konta do wydawania środków. Użytkownik mógłby wydawać środki otrzymane za pośrednictwem tych oddzielnych kluczy swapowych z tego samego konta, unikając operacyjnego obciążenia związanego z dzieleniem sald na wiele kont.

W obecnym modelu współdzielonego klucza odzyskanie jednego klucza może ujawnić płatności przychodzące na wielu adresach. Przy oddzielnych kluczach swapowych odzyskanie klucza podglądu jednego swapu ujawniłoby wpływy powiązane z tym kluczem bez automatycznego otwierania niezwiązanych płatności przychodzących. Klucz podglądu sam w sobie nie uprawnia do wydawania środków. Zamierzona ochrona jest węższa: ograniczyć historię płatności, którą może ujawnić jeden skompromitowany klucz.

##zyskiwanie musi znajdować płatności bez ujawniania własności

Oddzielne klucze tworzą problem odnajdywania przy przywracaniu portfela. Regeneracja kluczy z seeda nie informuje portfela, które z nich otrzymały płatności. Próbowanie każdego klucza swapowego względem całej historii transakcji zwiększałoby pracę odzyskiwania z każdym kolejnym swapem.

Swapy wychodzące zapewniają miejsce na zapisanie rekordu odzyskiwania. Proponowana implementacja umieszcza zaszyfrowaną notatkę w nucie należącej do transakcji finansującej użytkownika. Notatka ta rejestruje indeks użyty do wyznaczenia klucza zwrotnego. Podczas przywracania portfel może odzyskać indeks i odtworzyć odpowiadający mu klucz oraz adres.

Swapy przychodzące wymagają innego podejścia, ponieważ portfel Zcash nie utworzył transakcji finansującej, w której można by zostawić taką notatkę. Projekt zamiast tego sprawdza kolejno adresy wyznaczone deterministycznie, korzystając z rekordów adresów opłaconych lub już ujawnionych dostawcy swapów, aby określić, jak daleko musi trwać odnajdywanie.

Aby zlokalizować płatności, system odnajdywania odbiorców korzysta z publicznych filtrów, które portfel sprawdza lokalnie. Możliwe dopasowanie prowadzi do żądania prywatnego pobierania informacji, czyli PIR, które identyfikuje odpowiednią transakcję bez wysyłania do serwera czytelnego zapytania wymieniającego adres.

Portfel może następnie odszyfrować płatność odpowiadającym jej kluczem podglądu. Pozwala to uniknąć wykonywania przez każdy odzyskany klucz osobnego przeszukiwania całego łańcucha.

Prywatne zapytania zapobiegają także temu, aby czytelna seria żądań wyszukiwania ujawniała, że kilka adresów należy do siebie. W przeciwnym razie serwer mógłby otrzymać żądania dotyczące adresu A, potem B, potem C i powiązać je z jednym portfelem, niwecząc część separacji stworzonej przez nowe klucze.

Recenzja i wsparcie portfeli pozostają niedokończone

Eksperymentalny kod nie oznacza, że portfele włączyły tę funkcję dla zwykłych użytkowników. Recenzja kryptograficzna pozostaje otwarta, a implementacja określa, że签 signerzy sprzętowi wymagają kwalifikacji firmware, zanim klucze jednorazowe zostaną włączone dla kont sprzętowych.

Wpis inżynierski Zakury przewiduje integr z kompatybilnymi portfelami programowymi, w tym Vizor, w nadchodzących tygodniach. To szacunek rozwojowy, a nie potwierdzona data wydania.

Te prace są odrębne od planowanych na styczeń zabezpieczeń płatności Zcash, które dotyczą autoryzacji płatności. Propozycja swapowa dotyczy prywatności shielded historii płatności przychodzących.

Nowe pochodzenie kluczy nie może też usunąć adresów już zapisanych publicznie. Izolowanie przyszłych kluczy swapowych nie zmaże wcześniejszych ujawnień powiązanych z istniejącym współdzielonym kluczem podglądu.

Pozostała praca dostarczeniowa jest konkretna: recenzja pochodzenia kluczy, integracja odnajdywania płatności i przywracania oraz kwalifikacja wspieranych signerów. Te kroki muszą zostać ukończone, zanim użytkownicy będą mogli polegać na proponowanej separacji w wydanym portfelu.

Ten artykuł ma wyłącznie charakter informacyjny. Proponowana funkcja jest eksperymentalna i wymaga dalszej recenzji przed użyciem produkcyjnym.

Ten artykuł pierwotnie ukazał się na Coindoo.