btcduke.com · Web viewowa w oparciu o kwoty przekazywane w danej transakcji. Na przykład, jeżeli...

24
RESEARCH BULLETIN MRL-0005 BIULETYN NAUKOWY Transakcje poufne w oparciu o algorytm pierścieniowy Luty 2016r. Shen Noether*, Adam Mackenzie i Monero Core Team Korespondencję prosimy kierować do: [email protected] [email protected] Monero Research Lab Streszczenie Niniejszy artykuł przedstawia metodę umożliwiającą ukrywanie (aninomizację) kwot transakcji w systemie silnie zdecentralizowanej (rozproszonej), anonimowej waluty monero. Podobnie jak w przypadku bitcoina, monero jest kryptowalutą, która jest dystrybuowana dzięki zastosowaniu procesu „wydobywczego” w oparciu o algorytm proof of work. Oryginalny protokół monero został opracowany przy wykorzystaniu technologii CryptoNote, która wykorzystuje system podpisów pierścieniowych oraz klucze jednorazowe (one-time keys) w celu ukrycia odbiorcy oraz źródła transakcji. Jeden najnowszych materiałów opublikowanych przez Gregory’ego Macwella – developera Bitcoin Core, poświęcony jest wdrożeniu techniki układu zobowiązań (commitment scheme) umożliwiającej ukrywani kwot transakcji. Niniejszy artykuł zawiera opis, kolejnego nowego typu podpisu mianowicie Multi-layered Linkable Spontaneous Anonymous Group umożliwiającego ukrycie informacji o kwotach, źródle oraz odbiorcy związanych z daną transakcją przy zachowaniu satysfakcjonującego poziomu wydajności (skuteczności) oraz weryfikowalności, bez udziału elementu zaufanego w procesie generowania coinów. W artykule przedstawione są także wybrane rozszerzenia protokołu takie jak np. Aggregate Schnorr Range Proofs (schematy zagregowanej identyfikacji Schnorra), czy Ring Multisignature. Autor chciałby podkreślić, że pierwsze wersje niniejszego materiału zostały opublikowane na portalu Monero oraz na kanale irc wyszukiwarki bitcoinowej (bitcoin research irc channel). Ohaszowane wersje wstępne blockchaina są dostępne w [14] i potwierdzają, że początek prac nad tym systemem miał miejsce latem 2015 roku, a koniec na początku października 2015r. Dostępna jest także elektroniczna wersja dokumentu (eprint): http://eprint.iacr.org/2015/1098.

Transcript of btcduke.com · Web viewowa w oparciu o kwoty przekazywane w danej transakcji. Na przykład, jeżeli...

RESEARCH BULLETIN MRL-0005

BIULETYN NAUKOWYTransakcje poufne w oparciu o algorytm pierścieniowy Luty 2016r

Shen Noether Adam Mackenzie i Monero Core TeamKorespondencję prosimy kierować dolabgetmoneroorgshennoethergmxcomMonero Research Lab

Streszczenie

Niniejszy artykuł przedstawia metodę umożliwiającą ukrywanie (aninomizację) kwot transakcji w systemie silnie zdecentralizowanej (rozproszonej) anonimowej waluty monero Podobnie jak w przypadku bitcoina monero jest kryptowalutą ktoacutera jest dystrybuowana dzięki zastosowaniu procesu bdquowydobywczegordquo w oparciu o algorytm proof of workOryginalny protokoacuteł monero został opracowany przy wykorzystaniu technologii CryptoNote ktoacutera wykorzystuje system podpisoacutew pierścieniowych oraz klucze jednorazowe (one-time keys) w celu ukrycia odbiorcy oraz źroacutedła transakcji Jeden najnowszych materiałoacutew opublikowanych przez Gregoryrsquoego Macwella ndash developera Bitcoin Core poświęcony jest wdrożeniu techniki układu zobowiązań (commitment scheme) umożliwiającej ukrywani kwot transakcji Niniejszy artykuł zawiera opis kolejnego nowego typu podpisu mianowicie Multi-layered Linkable Spontaneous Anonymous Group umożliwiającego ukrycie informacji o kwotach źroacutedle oraz odbiorcy związanych z daną transakcją przy zachowaniu satysfakcjonującego poziomu wydajności (skuteczności) oraz weryfikowalności bez udziału elementu zaufanego w procesie generowania coinoacutew W artykule przedstawione są także wybrane rozszerzenia protokołu takie jak np Aggregate Schnorr Range Proofs (schematy zagregowanej identyfikacji Schnorra) czy Ring Multisignature Autor chciałby podkreślić że pierwsze wersje niniejszego materiału zostały opublikowane na portalu Monero oraz na kanale irc wyszukiwarki bitcoinowej (bitcoin research irc channel)Ohaszowane wersje wstępne blockchaina są dostępne w [14] i potwierdzają że początek prac nad tym systemem miał miejsce latem 2015 roku a koniec na początku października 2015r Dostępna jest także elektroniczna wersja dokumentu (eprint) httpeprintiacrorg20151098

1 Wstęp11 Spontaniczne podpisy pierścieniowe (Ad Hoc) jako element układu kryptowalut

Pamiętajmy że w systemie bitcoin każda transakcja jest podpisywana przez właściciela przekazywanych coinoacutew oraz że podpisy te pozwalają zweryfikować uprawnienia właściciela do transferu coinoacutew Proces ten jest całkowicie analogiczny do podpisu składanego na czeku w banku

CryptoNote [16] oraz Ring Coin [2] pozwoliły przenieść to rozwiązanie na wyższy poziom zaawansowania dzięki wykorzystaniu ldquoring signaturesrdquo ndash podpisoacutew pierścieniowych ktoacutere pierwotnie zostały zdefiniowane w [15] jako ldquopodpis cyfrowy odnoszący się do grupy osoacuteb potencjalnie uprawnionych do składania podpisoacutew w taki sposoacuteb że osoba dokonująca weryfikacji nie jest w stanie określić ktoacutery z użytkownikoacutew złożył podpisrdquo Głoacutewnym celem jest ukrycie klucza transakcji źroacutedłowej w grupie kluczy publicznych z ktoacuterych każdy zawiera tę samą liczbę coinoacutew oraz w celu zamaskowania źroacutedła transakcjiOryginalny protokoacuteł CryptoNote opisany w [16] uwzględnia drobną modyfikację tego rozwiązania uniemożliwiającą podwoacutejne wydatkowanie środkoacutew Mianowicie w [16] wykorzystywany jest ldquotraceable ring signaturerdquo ndash podpis pierścieniowy możliwy do prześledzenia ktoacutery stanowi nieznaczną modyfikację rozwiązania o ktoacuterym mowa w [6] Ten rodzaj podpisu pierścieniowego ma tę przewagę że nie dopuszcza możliwości złożenia dwoacutech roacuteżnych podpisoacutew pierścieniowych przez właściciela coinoacutew przy wykorzystaniu tego samego klucza publicznego bez odnotowania tego faktu w blockchainie Oczywiście głoacutewnym celem tego rozwiązania jest zapobieganie ldquopodwoacutejnemu wydatkowaniurdquo co w przypadku Bitcoina dotyczy dwukrotnego wydatkowania coina Ring coin [2 3] wykorzystuje nieco bardziej wydajny linkowalny podpis pierścieniowy ktoacutery stanowi nieznaczną modyfikację podpisoacutew Linkable Spontaneous Anonymous Group opisanych w [8]Jedną z zalet wykorzystywania wyżej wymienionych typoacutew podpisoacutew pierścieniowych w stosunku do pozostałych technik anonimizacji takich jak np CoinJoin [10] lub usługi miksowania walut jest to że umożliwiają one miksowanie ldquospontanicznerdquo W przypadku technik CoinJoin lub technik miksujących istnieje podobna możliwość ukrywania źroacutedła (inicjatora) danej transakcji chociaż techniki te w praktyce wymagają minimalnego udziału zcentralizowanego menadżera grupy w postaci zcentralizowanego serwera CoinJoin w ktoacuterym transakcje są łączone (kombinowane) przez zaufaną stronę W sytuacji gdy zostanie naruszone bezpieczeństwo zaufanej strony anonimowość transakcji także ulega złamaniuNiektoacutere coiny takie jak np Dash (oryginalna nazwa Darkcoin) [5] podejmują proacutebę negacji [tego systemu] poprzez wykorzystanie większej liczby zaufanych mikseroacutew (w tym przypadku masternodes) ale ich liczba jest w dalszym ciągu znacznie mniejsza niż użytkownikoacutew coinoacutew Dla odmiany w przypadku zastosowania spontanicznych podpisoacutew pierścieniowych transakcje mogą być tworzone przez właściciela danego klucza publicznego (właściwość spontaniczna lub ldquoad-hocrdquo) bez konieczności korzystania z zaufanego serwera co efekcie gwarantuje wyższy poziom anonimowościJeden z potencjalnych atakoacutew na oryginalną technologię CryptoNote lub protokoacuteł [216] to analiza blockchainowa w oparciu o kwoty przekazywane w danej transakcji Na przykład jeżeli przeciwnik wie że 09 coinoacutew zostało wysłanych w danym czasie to może być w stanie zawęzić możliwości wysyłającego analizując transakcje zawierające 09 coinoacutew Jest to w pewnym sensie negowane poprzez wykorzystanie kluczy jednorazowych stosowanych w [16] ponieważ wysyłający może wprowadzić dowolną liczbę adresoacutew zmiany w transakcji tym samym maskując kwotę ktoacutera została wysłana przy zastosowaniu miksowania typu ldquoknapsackrdquo Nie mniej jednak technika ta posiada pewne niedogodności w postaci zdolności do tworzenia dużych ilości transakcji typu ldquodustrdquo [pył kurz] w blockchainie tzn transakcji składających się z niewielkich kwot ktoacutere wykorzystują proporcjonalnie więcej przestrzeni niż wynikałoby to z ich znaczenia Dodatkowo odbiorca coinoacutew może być zmuszony do ldquousunięciardquo tego całego pyłu podczas wysyłania i umożliwić inteligentnemu przeciwnikowi śledzenie tego ktoacutere klucze wykazują pewne wspoacutelne elementy Dodatkowo łatwo jest określić goacuterną i dolną granicę wysyłanych kwotKolejną niedogodnością związaną z oryginalnym ustawieniem CryptoNote jest to że wymaga on aby dana para (Prsquo A)rsquo obejmująca klucz publiczny P oraz kwotę A była wykorzystywana w podpisie pierścieniowym wraz z innymi kluczami publicznymi związanymi z taką samą kwotą W przypadku mniej popularnych kwot oznacza to że może wystąpić mniejsza liczba potencjalnych par (Prsquo Arsquo) dostępnych w blockchainie wraz z Arsquo = A ktoacutere można umieścićpowiązaćpodpisać danym podpisem pierścieniowym Dlatego w oryginalnym protokole CryptoNote potencjalny zbioacuter anonimowych transakcji jest prawdopodobnie

mniejszy niż można by tego oczekiwać Analiza wyżej opisanych słabych punktoacutew przedstawiona jest w [9]

12 Pierścień CT dla MoneroOczywistym sposobem negowania słabych stron protokołu CryptNote zgodnie z opisem w poprzedzającym ustępie może być zaimplementowanie ukrytych kwot dla dowolnej transakcji W niniejszym dokumencie przedstawiam zmiany wprowadzone do protokołu Monero kryptowaluty opartej na algorytmie proof-of-work stanowiącej rozszerzenie pierwotnego protokołu CryptoNote ktoacutera umożliwia ukrycie (zamaskowanie) kwot przekazywanych w ramach danej transakcji Modyfikacja ta zasadza się na Transakcjach Poufnych [11] ktoacutere są wykorzystywane w łańcuchu bocznym elementoacutew bitcoina z tą roacuteżnicą że umożliwia ona ich wykorzystanie w ramach podpisoacutew pierścieniowych Dlatego też modyfikacja ta otrzymuje oczywistą nazwę Pierścieniowe Transakcje Poufne dla systemu [waluty] MoneroAby zachować właściwość uniemożliwiającą dwukrotne wydatkowanie coinoacutew przedstawiam opis pewnego uogoacutelnienia LSAG w [8] ndash podpis typu Multilayered Linkable Spontaneous Anonymous Group Signature (MLSAG) ktoacutery umożliwia kombinację Transakcji Poufnych opatrzonych podpisami pierścieniowymi w taki sposoacuteb że wykorzystywanie mnogich danych wejściowych i wyjściowych będzie możliwe z zachowaniem anonimowości przy jednoczesnym uniemożliwieniu podwoacutejnego wydatkowania Autor podkreśla że zasadniczo podobny protokoacuteł został zaproponowany przez Connora Frenkenechta około miesiąc po ukazaniu się drugiej wersji oryginału niniejszego dokumentu

13 Silnie zdecentralizowane systemy płatności anonimowych [Strongly Decentralized Anonymous Payment Schemes]Protokoacuteł pierścieniowy CT [Ring CT] umożliwia tworzenie ukrytych kwot źroacutedeł oraz adresatoacutew transakcji i jest nieco zbliżony do systemu Zerocash [4] Jedna z potencjalnych roacuteżnic polega na wykorzystaniu proof of work w celu generowania coinoacutew za pomocą protokołu Ring CT w odroacuteżnieniu od ZeroCash gdzie jak się wydaje wszystkie coiny muszą być wstępnie wygenerowane przez zaufaną grupęNależy podkreślić że jedną z największych innowacji w systemie Bitcoin [13] był zdecentralizowany model dystrybucji umożliwiający dowolnej zainteresowanej osobie udostępnienie swoich mocy obliczeniowych do pracy i uczestnictwo w procesie generowania waluty Niektoacutere korzyści wynikające z tego typu algorytmu proof-of-work obejmują niezaufane motywacje do zabezpieczania sieci oraz jeszcze silniejszej decentralizacji (na przykład do ochrony przed atakami typu poison-pill ndash trujące pigułki)Jedną z oczywistych końcowych korzyści generowania coinoacutew w oparciu o algorytm proof-of-work jest to że pozwala on na uodpornienie Ring CT na działania podejmowanego przez silnego aktora ktoacutery potrafi znaleźć sposoacuteb na znalezienie wszystkich fragmenty klucza głoacutewnego wykorzystywanego do generowania coinoacutew Ponieważ mamy do czynienia z oczywistym poważnym bodźcem (jakim jest zdolność do generowania darmowych środkoacutew finansowych [1]) do pozyskiwania wszelkich fragmentoacutew procesu generacji zaufanego klucza kwestia ta jest dość istotna

14 PodziękowaniaChciałbym podziękować zespołowi Monero za udzieloną pomoc rozmowy dotyczące procesu opracowywania niniejszej publikacji oraz całej społeczności portali Monero oraz Bitcoin za wsparcie i udział w dyskusji Jeżeli chodzi o ujawnianie (poufność) autor otrzymał kilka donacji o łącznej wartości od 2 do 3 bitcoinoacutew ze strony społeczności Monero na dowoacuted ich wdzięczności i w uznaniu wkładu w niniejszą pracę badawczą

2 Podpisy typu Multilayered Linkable Spontaneous Anonymous Group Signatures

Niniejszy rozdział zawiera definicję podpisoacutew typu Multilayered Linkable Spontaneous Anonymous Group (MLSAG) wykorzystywanych przez protokoacuteł Ring CT Należy podkreślić że definiuję je jako podpis ogoacutelny a niekoniecznie jako przykład wykorzystania w Pierścieniowych Transakcjach Poufnych MLSAG jest zasadniczo zbliżony do LSAG-oacutew opisanych w [8] ale zamiast składać podpis na zbiorze n kluczy MLSAG sam w sobie stanowi podpis pierścieniowy na zbiorze wektoroacutew n kluczy

Definicja 21 Wektor kluczy jest po prostu zbiorem kluczy publicznych odpowiadających kluczom prywatnym

[1] Poprzednio autor założył że mogłoby to roacutewnież umożliwić ujawnienie (odsłonięcie) transakcji ale najnowsza publikacją dotycząca ZeroCash wyraźnie stwierdza że to niemożliwe

21 Podpisy LWW a podpisy FS Podpisy pierścieniowe wykorzystywane w Monero oraz oryginalny protokoacuteł CryptoNote są pochodnymi podpisoacutew pierścieniowych możliwych do wyśledzenia z [6] Podpisy pierścieniowe w ramach CryptoNote [16] zawierają ldquoobraz kluczardquo co oznacza że podpisujący może podpisać jeden pierścień w blockchainie używając danego klucza publicznego oraz pary kluczy prywatnych albo ich transakcja zostanie oznaczona jako nieważna W związku z tym wykorzystywane są klucze jednorazowe w protokole CryptoNote ktoacutere następnie podnoszą poziom anonimowościW [3] Adam Back podkreśla że podpisy w ramach Linkable Spontaneous Anonymous Group (LSAG) w [8] mogą być modyfikowane w taki sposoacuteb aby utworzyć bardziej wydajny linkowany podpis pierścieniowy dający ten sam efekt jaki uzyskuje się w przypadku podpisu pierścieniowego z [6] Modyfikacja ta pozwala obniżyć koszty przechowywania w blockchainie zasadniczo o połowęNa początek przytoczę ndash niemal dosłownie ndash modyfikacje opisane w [3]Keygen [Generowanie klucza] Znajdź pewną liczbę kluczy publicznych Pi i = 0 1 hellip n oraz sekretny indeks j spełniający warunek xG = Pj gdzie G stanowi punkt bazowy ed25519 a x to klucz wydatkowany sygnatariuszy Niech I = xHp (Pj) gdzie Hp jest funkcją haszującą zwracającą punkt [2] Niech m stanowi daną wiadomośćPODPIS Niech α si i ne j i ϵ 1 hellip n będą wartościami losowymi w Zq (pole bazowe ed25519)ObliczLj = αGRj = αHp (Pj)cj+1 = h (m Lj Rj)gdzie h jest funkcją haszującą zwracającą wartość w Zq Teraz dokonując kolejnych obliczeń j modulo n należy zdefiniowaćLj+1 = sj+1G + cj+1Pj+1Rj+1 = sj+1Hp (Pj+1) + cj+1 _ Icj+2 = h (m Lj+1 Rj+1)hellip

Lj-1 = sj-1G + cj-1Pj-1Rj-1 = sj-1Hp (Pj-1) + cj-1∙ Icj = h (mLj-1 Rj-1)

[2] W praktyce Hp(P) = Keccak(P) ∙ G gdzie G jest punktem bazowym ed25519 chociaż należy zauważyć że w odniesieniu do układu zobowiązań będę wykorzystywać toPoint(Keccak(P)) haszujący kolejno aż do zwrotu wielokrotności punktu bazowego przez Keccak(P)

po to aby umożliwić definicję c1 hellip cnNiech sj = α - cj ∙ xj mod l (l stanowi porządek krzywej ed25519) stąd α = sj + cjxj mod l w taki sposoacuteb że Lj = _G = sjG + cjxjG = sjG + cjPjRj = _Hp (Pj) = sjHp (Pj) + cjIorazcj+1 = h (m Lj Rj)stąd mając jednostkową wartość ci wartości Pj obraz klucza I oraz wszystkie wartości sj pozostałe ck k 6= i mogą być odkryte przez obserwatora Podpis w związku ma postaćα = (I c1 s1 hellip sn)reprezentując oszczędności w zakresie zajmowanego miejsca w stosunku do [16 44] gdzie podpis pierścieniowy moacutegłby zamiennie wyglądać w następujący sposoacutebα = (I c1 hellip cn s1 hellip sn)Weryfikacja przebiega w następujący sposoacuteb Obserwator oblicza wartości Li Ri oraz ci dla wszystkich i oraz weryfikuje czy cn+1 = c1 Następnie weryfikator sprawdza czy

ci+1 = h (m Li Ri)dla wszystkich i mod nLINK Podpisy z duplikatami obrazoacutew kluczy I są odrzucaneNależy podkreślić że protokoły proofs of unforgeability anonimowości oraz łączenia obowiązują i stanowią jedynie nieznaczne modyfikacje protokołoacutew proof o ktoacuterych mowa w [8] Przedstawię nieco bardziej uogoacutelnioną wersję tych protokołoacutew dla MLSAG

22 Opis MLSAG W odniesieniu do protokołu Ring CT ktoacuterego opis znajduje się w części 4 wymagam uogoacutelnienia podpisoacutew Back LSAG opisanych w poprzednim rozdziale co umożliwia stosowanie wektoroacutew kluczy (Definicja 21) zamiast po prostu kluczyPrzypuśćmy że każda osoba składająca podpis pod (uogoacutelnionym) pierścieniem

zawierającym n członkoacutew (uczestnikoacutew) ma dokładnie m kluczy Celem podpisu pierścieniowego MLSAG jest realizacja następujących celoacutew

udowodnienie że jeden z podpisujących n zna sekretny klucz właściwy dla całego wektora klucza

Zapewnienie że jeżeli podpisujący wykorzystuje jeden z kluczy podpisoacutew m w innym podpisie MLSAG to dwa pierścienie są połączone a drugi taki podpis MLSAG (zlecony przez blockchain Monero) zostanie odrzucony

Algorytm działa w sposoacuteb następujący niech m stanowi wiadomość Niech π jest sekretnym indeksem odpowiadającym sygnatariuszowi uogoacutelnionego pierścienia Dla j = 1 hellip m niech

oraz dla j = 1 hellip m i = 1 hellip π hellipn (gdzie π oznacza ominięcie indeksu π) niech stanowi jeden z losowych skalaroacutew (elementoacutew Zq) Teraz w sposoacuteb analogiczny do części 21 należy zdefiniować

dla skalaroacutew losowych αj oraz j = 1 hellip m A teraz ponownie analogicznie do części 21 należy określić

i powtoacuterzyć czynność zwiększając przyrostowo i modulo n aż do momentu uzyskania następującej postaci

Na koniec dla każdego rozwiązać mod l Podpis jest następnie przekazywany jako zatem kompleksowość wynosi O (m(n + 1)) Proces weryfikacji przebiega poprzez regenerację wszystkich zaczynając od i = 1 podobnie jak to miało miejsce w części 21 (ktoacutera

stanowi przypadek szczegoacutelny w ktoacuterym m = 1) i przeprowadzając sprawdzenie funkcji haszującej cn+1 = c1 Jeżeli wartości te są wykorzystywane w ustawieniu blockchainowym takim jak Monero podpisy składane za pomocą obrazoacutew kluczy Ij ktoacutere już się pojawiły są następnie odrzucane Można to w bardzo łatwy sposoacuteb wykazać stosując metodę zbliżoną do [8] że

Prawdopodobieństwo że sygnatariusz generujący ważny podpis bez znajomości wszystkich prywatnych kluczy ldquomrdquo należących do ich wektora kluczy dla indeksu π może być pominięty

Prawdopodobieństwo że sygnatariusz nie podpisze żadnego klucza z indeksu π może zostać pominięte (Innymi słowy wszystkie obrazy kluczy stanowiące część podpisu muszą pochodzić z indeksu π)

Jeżeli sygnatariusz podpisuje dwa pierścienie wykorzystując co najmniej jeden z tożsamych kluczy publicznych to następuje skojarzenie (połączenie) dwoacutech pierścieni

Szersze omoacutewienie tych elementoacutew znajduje się w dalszej części materiału dotyczącej zabezpieczeń (security proofs)

23 Model zabezpieczeń MLSAGMLSAG spełnia trzy niżej wymienione właściwości niefałszowalność (Unforgeability) linkowalność (Linkability) oraz Dwuznaczność Sygnatariusza (Signer Ambiguity) ktoacutere są bardzo zbliżone do definicji podanej w [8]

Definicja 22 Niefałszowalność (Unforgeability) System podpisoacutew MLSAG jest niemożliwy do sfałszowania jeżeli dla danego algorytmu A wielomianowego czasu probabilistycznego (PPT) z podpisem oracle SO generującego ważne podpisy oraz dla danej listy wektoroacutew kluczy publicznych n wybranej przez A A może generować przy pomijalnym prawdopodobieństwie ważny podpis w sytuacji gdy A nie zna jednego z odpowiednich wektoroacutew kluczy prywatnych

Uwaga 23 W poniższej definicji należy zauważyć że umieściłem funkcję odrzucania duplikujących się obrazoacutew kluczy jako części kryterioacutew weryfikacji dla MLSAG co przyczynia się do zbudowania nieco zmodyfikowanej definicji linkowalności (Linkability) w stosunku do tej ktoacutera została podana w [8]

Definicja 24 Linkowalność (Linkability) Niech L stanowi zbioacuter wszystkich kluczy publicznych w danym ustawieniu (np w danym łańcuchu blokowym - blockchainie) System składania podpisoacutew MLSAG w L jest połączony z obrazami kluczy jeżeli prawdopodobieństwo że

adwersarz A utworzy w PPT dwa podpisy σ σ1 podpisane w odniesieniu do wektoroacutew kluczy

oraz 1 z ktoacuterych każdy będzie zawierać ten sam klucz publiczny yi = yirsquo W L oraz każdy będzie weryfikowany bez oznaczenia jako duplikat jest pomijalne

Definicja 25 Dwuznaczność sygnatariusza (Signer Ambiguity) System składania podpisoacutew MLSAG uważa się za niejednoznacznie identyfikujący sygnatariusza jeżeli mamy dany podpis weryfikujący σ na wektorach kluczy oraz dowolny zbioacuter kluczy prywatnych t z ktoacuterych każdy będzie mieć oddzielny indeks oraz sekretny indeks w takiej sytuacji prawdopodobieństwo odgadnięcia klucza sekretnego wynosi mniej niż

Dowody potwierdzające powyższe definicje przedstawiono w Załączniku

3 Zarys historyczny transakcji poufnych31 Transakcje poufne w ramach system Bitcoin

W [11] Greg Maxwell opisuje transakcje poufne ktoacutere są pewną metodą przekazywania transakcji w systemie Bitcoin przy jednoczesnym maskowaniu kwot Podstawową kwestią jest stosowanie schematu zobowiązań Pedersena metoda ta jest doskonale opisana w cytowanym materiale źroacutedłowym W niniejszym opracowaniu wprowadzam drobną modyfikację do mechaniki Transakcji Poufnych polegającą na wybieraniu zamiast zobowiązań ktoacuterych suma wynosi zero opcji złożenia podpisu pod zobowiązaniem w celu wykazania że klucz prywatny jest mi znany Schemat ten jest opisany szczegoacutełowo w kolejnym rozdziale

32 Modyfikacja pod kątem podpisoacutew pierścieniowych Niech G stanowi punkt bazowy ed25519 Niech [3]

H = toPoint (cn_fast_hasz (G))

Należy podkreślić że nie każda wartość haszująca pozwala obliczyć punkt w ramach grupy punktu bazowego (tzn dla pewnej niewiadomej) (co jest sprzeczne z tym co dzieje się w secp256k1 krzywej wykorzystywanej w systemie Bitcoin) Nie mniej jednak wydaje się że wyboacuter punktu bazowego jako takiego (wcześniej wykorzystywałem H(123456G) sprawdza się co z resztą wydawało mi się bardziej bezpieczne przy czym punkt bazowy jest z pewnością bardziej naturalnym wyborem) Wyboacuter H = ϒG dla pewnej niewiadomej jest konieczny po to aby pełna matematyka zwykłych krzywych eliptycznych zachowała swoją ważność

[3] H = MiniNerogetHForCT() w kontekście kodu w [14]

Przy założeniu logarytmoacutew dyskretnych w ed25519 prawdopodobieństwo że adwersarz odkryje ϒ jest pomijalne Należy zdefiniować C (a x) = xG+aH zobowiązanie wartości a z maską x Należy podkreślić że tak długo jak wartość logGH nie jest znana oraz jeżeli σ ne 0 to logGC (a x) pozostaje wartością nieznaną Z drugiej strony jeżeli a = 0 to logGC (a x) = x a zatem istnieje możliwość złożenia podpisu za pomocą pary kluczy sk-pk (xC (0 x)) W [11] istnieją dane wejściowe I wyjściowe zobowiązań a sieć sprawdza czy

sumdane wejściowe = sumdane wyjściowe

Nie mniej jednak nie jest to wystarczające w przypadku systemu Monero ponieważ dana transakcja zawiera roacuteżne możliwe do realizacji dane wejściowe Pi i = 1 hellip n z ktoacuterych tylko jedna należa do nadawcy (patrz [16 44]) to jeżeli będziemy w stanie sprawdzić powyższe roacutewnanie to musi być możliwe aby sieć widziała ktoacutere Pi należy do nadawcy transakcji Nie jest to zjawisko pożądane ponieważ eliminuje anonimowość zbudowaną dzięki podpisowi pierścieniowemu W związku z tym zastępczo tworzy się zobowiązania dla danych wejściowych oraz wyjściowych zgodnie z poniższym (załoacuteżmy najpierw że istnieje tylko jeden zestaw danych wejściowych)

Cin = xcG + aHCout10485761 = y1G + b1HCout10485762 = y2G + b2H

W taki sposoacuteb że xc = y1+y2+z xc - y1 - y2 = z yi są wartościami maskującymi z gt 0 oraz a = b1+b2W tym przypadku xc stanowi szczegoacutelny prywatny klucz a ldquokwota kluczardquo znana jest tylko nadawcy oraz osobie do ktoacuterej coiny są wysyłane zatem musi być odmienna od normalnego klucza prywatnego W takim przypadku

= xcG + aH - y1G - b1H - y2G - b2H= zG

A zatem powyższe roacutewnanie staje się zobowiązaniem do 0 przy sk = z oraz pk = zG a nie rzeczywistym roacutewnaniem o sumie zerowej Należy podkreślić że z nie jest wyliczalne dla coinoacutew źroacutedłowych xc chyba że znana jest zaroacutewno wartość y1 jak i y2 nie mniej jednak nawet to można w prosty sposoacuteb złagodzić poprzez uwzględnienie dodatkowych adresoacutew zmiany (zwykły przypadek zakłada że drugie zobowiązanie z wartością y2 jako maską są wysyłane jako zmiana)Ponieważ podawanie informacji ktoacutere dane wejściowe należą do nadawcy nie jest pożądane podpis pierścieniowy zawierający wszystkie zobowiązania wejściowe Ci i = 1 hellip s hellip n (gdzie s stanowi sekretny indeks zobowiązania nadawcy) dodaje się odpowiedni klucz publiczny (dzięki czemu zobowiązania oraz klucze publiczne są parowane (Ci Pi) ale tylko takie ktoacutere mogą być wspoacutelnie wydatkowane) oraz odejmuje sumCout

Jest to podpis pierścieniowy ktoacutery może być złożony ponieważ znamy jeden z prywatnych kluczy (a mianowicie z + xrsquo zawierający z jak wyżej oraz xrsquoG = Ps) Tak naprawdę ponieważ wiemy że dla każdego i zaroacutewno klucze prywatne dla Pi jak i klucze prywatne dla Pi + Ciin - sumjCjout możemy złożyć podpis zgodnie z treścią rozdziału 22 Szczegoacuteły tej procedury są opisane w Definicji 41

Zgodnie z [11] ważne jest udowodnienie że kwoty wyjściowe [4] b1 hellip bn wszystkie mieszczą się w szeregu wartości dodatnich np (0 216) Można to osiągnąć zasadniczo w taki sam sposoacuteb jak w [11] kwestia ta jest bardziej szczegoacutełowo opisana w części 5Na koniec warto zauważyć że w powyższej dyskusji nie wspomniałem o właściwości związanej dołączaniem tagoacutew ktoacutera jest wykorzystywana w Monero oraz Cryptonote w celu zapobiegania podwoacutejnemu wydatkowaniu środkoacutew Dołączanie tagoacutew w tym momencie będzie skutkiem łączenia powyższego omoacutewienia z podpisami MLSAG o ktoacuterych mowa w Definicji 41

4 Ring CT dla protokołu Monero 41 Opis protokołuDefinicja 41 (Tagowalny pierścień CT z mnogimi danymi wejściowymi oraz kluczami jednorazowymi)

Niech stanowi zbioacuter adresoacutew oraz kluczy jednorazowychzobowiązań ktoacuterym odpowiadają sekretne klucze xj j = 1 hellip m

Znaleźć zbiory q + 1 i = 1 hellip q + 1 ktoacutere nie są połączone tagami w sensie [ 6 strona 6]

Należy określić zestaw adresoacutew wyjściowych (Qi Ciout) takich że

stanowią zobowiązania o wartości zero Niech

hellip

stanowi uogoacutelniony pierścień w ktoacuterym chcemy złożyć swoacutej podpis Należy zauważyć że ostatnia kolumna to pierścień Ring-CT w rozumieniu rozdziału 4

Obliczyć podpis MLSAG sum na R

[4] Ponieważ zobowiązania wejściowe mogą być potencjalnie odziedziczone z poprzednich transakcji wystarczy rozważyć kwoty wyjściowe

W takim przypadku zgodnie z teorematem A2 nie może być sygnatariuszem żadnych dodatkowych niezlinkowanych podpisoacutew pierścieniowych w danym nadzbiorze P wszystkich takich par P = (PC) po podpisaniu sum

Uwaga 42 Złożoność przestrzeni powyższego protokołu Warto zauważyć że rozmiar podpisu sum na R zgodnie z definicją 41 jest w rzeczywistości mniejszy dla m gt 1 niż bieżący podpis pierścieniowy transakcji opartej na protokole CryptoNote [16] ktoacutera zawiera mnogie dane wejściowe Dzieje się tak dzięki wprowadzeniu zmian w rozmiarze w [8] do każdej kolumny Należy także podkreślić że prawdopodobnie nie jest konieczne umieszczanie obrazu klucza zobowiązania związanego z wyżej wymienionym podpisem Kolejne optymalizacje rozmiaru są możliwe i można je wykonać w podobny sposoacuteb

42 Konwersja widocznych denominacji na zobowiązaniaPonieważ Monero obecnie wykorzystuje blockchainowe widoczne skalary w celu stworzenia reprezentacji kwot ważne jest aby istniała możliwość (i sposoacuteb) konwersji z kwot widocznych na zobowiązania przy jednoczesnym zachowaniu anonimowości Tak naprawdę wcale nie jest to trudne Mając daną parę (P a) gdzie P jest kluczem publicznym a a stanowi kwotę może ona być wykorzystana jako dane wejściowe transakcji jako (P aH) i transakcja ta musi być zweryfikowana przez weryfikatora pod kątem kwoty wejściowej i jej przemnożenia przez punkt maskujący H oraz czy uzyskana wartość rzeczywiście wynosi aH Zatem jako pierwszy krok kwoty wejściowe nie zostaną ukryte ale ukryte zostaną dane wyjściowe transakcji oraz wszelkie niezbędne relacje o ktoacuterych mowa w rozdziale 4 pozostają ważne Należy podkreślić że range proof nie jest konieczny dla tych danych wejściowych

Uwaga 43 Oczywistą zaletą tej metody jest konwersja z kwot widocznych na zobowiązania oraz to że kwota coinoacutew wygenerowanych w procesie wydobycia jest weryfikowalna bez konieczności udziału elementu zaufanego Jest to przewaga protokołu Ring CT nad systemami płatniczymi takimi jak [4] ktoacutere obejmują fazę ustawień strony zaufanej

43 Opłaty transakcyjnePonieważ system Monero jest silnie zdecentralizowany (tzn proof of work) konieczne jest wynagradzanie goacuternikoacutew i dokonywanie opłat za każdą transakcję Pomaga to podnieść bezpieczeństwo sieci i zapobiegać rozdęcia blockchainu Opłaty te muszą być realizowane w postaci niezamaskowanej tzn Jako bH a nie xG + bH oraz w odniesieniu do pewnej standardowej kwoty b w taki sposoacuteb że goacuternik będzie moacutegł zweryfikować że b ∙ H = bH i tym samym że jest dość środkoacutew na opłatę transakcyjną przy jednoczesnym zachowaniu roacutewnań związanych z H w taki sposoacuteb że zostaną zachowane niezbędne relacje o ktoacuterych mowa w Rozdziale 4

44 Ring MultisignatureWarto zauważyć że prosta wersja t z m z n ring-multisignature [mnogich podpisoacutew pierścieniowych] może być zrealizowana w oparciu o podpisy MLSAG Umożliwia to grupie m uczestnikoacutew zbudowanie multisignature takiego że t uczestnikoacutew z liczby z m musi złożyć podpis aby był on uznany za ważny dodatkowo jest on dwuznaczny w odniesieniu do sygnatariusza klucze m są uczestnikami mieszczącymi się w ogoacutelnej liczbie n kluczy

Liczba n uczestnikoacutew w multisignature stanowi wspoacutelny sekret xe oraz klucz publiczny Pe ktoacutere mają wspoacutelne obrazy kluczy multisig

Ij = xeH(PejPj)

z Pj ndash publicznym kluczem uczestnika Każdy uczestnik multisignature dokonuje wyboru dodatkowych kluczy publicznych n -

m w blockchainie oraz tworzy podpis MLSAG za pomocą pierwszego rzędu wszystkich kluczy n a drugi rząd ma dla każdego wpisu (elementu) klucz wspoacutelny Pe

Każdy sygnatariusz multisignature podaje początkowe Ij j = 1 hellip m w celu umożliwienia zaakceptowania klucza po przekazaniu podpisoacutew weryfikujących t w blockchainie z ktoacuterych każdy odpowiada jednemu obrazowi klucza Ij

Rozszerzony zapis ring-multisignature jest w fazie opracowania

5 Zagregowane schematy identyfikacji Schnorra (Aggregate Schnorr Range Proofs)W części [11] poufne transakcja bez podpisu pierścieniowego wykorzystuje pewien typ podpisu pierścieniowego oparty na [1] nazywany podpisem pierścienia boromejskiego (Borromean ring signature) i pomaga zidentyfikować przekłamania w wartości zobowiązań w pewnym przedziale W niniejszym artykule postaram się nakreślić alternatywną metodę zainspirowaną przez [7] ktoacutera pozwala na uzyskanie tych samych oszczędności w zakresie przestrzeni ale za to opatrzona jest nieco mniej skomplikowanym protokołem bezpieczeństwa Motywacja do tego typu działania jest następująca przypuśćmy że dana transakcja ma dane wejściowe zobowiązań roacutewne

Cin = ainG + 10H

oraz zobowiązania wyjściowe

Cout 1 = aout1G + 5H Cout2 = aout2G + 5H

Scenariusz ten zachowuje ważność gdyż istnieje możliwość złożenia podpisu dla Cin ndash Cout1 ndash Cout2 = (ain ndash aout1 ndash aout2)G

Nie mniej jednak warto podkreślić że (bez range proofs) będzie istniała możliwość alternatywnego ustawienia zobowiązań wyjściowych

Cout1 = aout1G- H Cout2 = aout2G + 11H

Ponieważ -1 jest bardzo dużą liczbą stanowiącą modulo porządkujące grupę krzywej tym samym zostały utworzone darmowe pieniądze Zatem konieczne jest wykazanie że Couti są zobowiązaniami w odniesieniu do wartości ktoacutere są pozytywne (dodatnie) i mieszczą się w ograniczonym przedziale [0 2n] dla niektoacuterych wartości n Aby tego dokonać należy rozłożyć każdą wartość wyjściową na elementy binarne

co pozwala obliczyć zobowiązania do bj ∙ 2j w taki sposoacuteb że

Na koniec wykorzystując sekretny klucz bj można obliczyć podpis pierścieniowy na

dla wszystkich j oraz zapewnia dla weryfikatoroacutew (w tym przypadku goacuternikoacutew)Jeżeli chodzi o oszczędności miejsca można albo wykorzystać boromejski podpis pierścieniowy (podobnie jak w [11]) albo połączyć wszystkie proste podpisy pierścieniowe bądź utworzyć pewien typ zagregowanego podpisu pierścieniowego zdefiniowanego w następujący sposoacuteb

501 Generowanie zagregowanego nielinkowanego podpisu pierścieniowego Schnorra (Aggregate Schnorr Non-linkable Ring Signature) (ASNL)

Niech stanowi zbioacuter kluczy j = 1hellip z jako sekretnym kluczem

Dla każdego j niech Irsquo = i + 1 mod 2 ustawić skalar losowy aj i obliczyć

Ustawić gdzie Hs to kryptograficzna funkcja haszująca zwracająca skalar po dokonaniu wyboru losowego obliczyć

Określić i obliczyć

Zwroacutecić dla wszystkich j i s =

502 Weryfikacja zagregowanego nielinkowalnego podpisu pierścieniowego Schnorra (ASNL)Zacznijmy od dla j = 1hellip n oraz s

Dla wszystkich j obliczyć oraz

Jeżeli to otrzymamy 0 dla ważnego podpisuW przeciwnym razie otrzymamy wartość zwrotną -1

Teoremat 51 Zagregowany nielinkowany podpis pierścieniowy Schnorra nie może być sfałszowany przy założeniu logarytmu dyskretnego

Dowoacuted Przedstawiam szkic dowodu w przypadku n = 2 Przypadek ogoacutelny ma zbliżony charakter Przypuśćmy że adwersarz A jest w stanie sfałszować podpis ASNL na

Przy pomijalnym prawdopodobieństwie znając najwyżej jedną z (przypuśćmy że bez straty ogoacutelnego charakteru założenia że A zna ) Dla każdego danego fałszu

rozwiązuję roacutewnanie logarytmu dyskretnego o niepomijalnym prawdopodobieństwie Po zastosowaniu algorytmu weryfikacji niech Zatem prawdziwe musi być roacutewnanie

Przypuśćmy że oraz a a b są znane A wtedy

ponieważ jest określone protokołem weryfikacji musi być zatem prawdą że A zna klucz

prywatny

=Jest to w sprzeczności z założeniem logarytmu dyskretnego dla danej grupy

51 Reprezentacja kwotKwoty w protokole Ring CT można przedstawiać w sposoacuteb zbliżony do tego ktoacutery przedstawiony został w [11] z drobną modyfikacją w celu dopasowania do systemu Monero Coiny CryptoNote organizują nominały coinoacutew w bazie indeksoacutew w taki sposoacuteb aby mogły być ułożone w porządku występowania jako dane wejściowe dla podpisoacutew pierścieniowych Ponieważ wszystkie wartości coinoacutew w CryptoNote są reprezentowane w postaci 64-bitowych niepodpisanych liczb całkowitych możemy wykorzystać range proof na przestrzeni całego rejestru w celu zakodowania kwoty wyjściowej przekazywanej odbiorcy Na szczęście to także umożliwia wzajemne miksowanie danych wyjściowych zatem wymagany jest tylko jeden indeks danych wyjściowych w porządku rejestracji Przedział weryfikacji (range proof) wynosi ok 5 kilobajtoacutew Podpisy pierścieniowe dla danych wejściowych stają się bardziej odporne na analizę ponieważ anonimowość jest bardzo rozszerzonaPodczas gdy obszary weryfikacji (range proofs) są duże wykorzystywanie układu haszującego ktoacutery dodaje przedrostek do transakcji (zaroacutewno indeksoacutew wejściowych jak i wyjściowych) i przechowuje szeroki zakres range proof wraz z podpisami umożliwia oddzielnie uzyskanie ogromnych oszczędności przestrzeni podczas synchronizacji (syncing) do punktu weryfikacji lub działanie jako węzeł SPV Podobnie do elementoacutew bocznych łańcucha (Sidechains Elements) [12] będziemy przechowywać H(H(prefiks)||H(podpisy)) w drzewie Merkla Następnie węzły syncing do zaufanego punktu weryfikacji muszą jedynie pobrać przedrostek i dodać wartość haszującą do podpisoacutew skutecznie redukując szerokość wiązki Ponieważ prefiks transakcji wykorzystuje wariant dla danych wyjściowych ktoacutere wymienia w swoich podpisach pierścieniowych oraz środkach zapisanych do jednego klucza publicznego stanowi on miniaturowe poroacutewnanie do danych podpisoacutew pierścieniowych w danych wyjściowych oraz range proofs

Następnie podpisy pierścieniowe mogą nawet być przycięte z bazy danych przez niektoacutere węzły w celu uzyskania dalszych zyskoacutew przestrzeni przechowując zastępczo jedynie względnie mały zbioacuter UTXO

511 Przekazywanie informacji o kwotach OdbiorcyObecnie mając dowolną kwotę wyjściową b = b020 + b121 + ∙∙∙ bn2n nadawca oblicza nową prywatnąpubliczną parę kluczy oraz związane wymieniane sekrety ECDH ss oraz udostępnia następujące informacje w swojej transakcji

gdzie ai to losowo wybrane liczby dla j = 0 hellipn Dane Klucz publiczny ECDH oraz a + ss mod l gdzie a = a0 + hellip + an

Następnie odbiorca Oblicza udostępniany sekret ss oraz oblicza a na podstawie a + ss mod l Oblicza C = sumCi oblicza C ndash aG = bH oraz oblicza b poroacutewnując uzyskane wartości do

wszystkich bH w danym przedziale [0 2n] (W praktyce będzie to szybkie 500 kilobajtowe wyszukanie w n = 12 podobnie jak w poprzednim rozdziale Gdyby jednak wartość 232 została wybrana jako goacuterna wartość graniczna podobnie jak w [11] wyszukiwanie stałoby się dużym obliczeniowo wysiłkiem)

6 WnioskiProtokoacuteł pierścieniowych transakcji poufnych (Ring Confidential Transactions) to bardzo silnie zdecentralizowana kryptowaluta (tzn nie ma w niej żadnej uprzywilejowanej strony) ktoacutera posiada proste do udowodnienia wartości szacunkowe zabezpieczeń dotyczące ukrywania kwot transferoacutew ich źroacutedeł oraz odbiorcoacutew Dodatkowo generowanie coinoacutew w oparciu o protokoacuteł Ring Confidential Transactions nie wymaga obecności czynnika zaufanego i proces jego weryfikacji jest całkowicie bezpiecznyTych pięć czynnikoacutew jest niezbędnych w przypadku kryptowalut zbliżonych do środkoacutew gotoacutewkowych takich jak MoneroBibliografia1 Masayuki Abe Miyako Ohkubo and Koutarou Suzuki 1-out-of-n signatures from a variety of keys Advances in CryptologyAsiacrypt 2002 pages 415ndash432 20022 Adam Back Bitcoins with homomorphic value (validatable but encrypted)httpsbitcointalkorgindexphptopic=3057910 2013 [Online accessed 1-May-2015]3 Adam Back Podpis pierścieniowy efficiency httpsbitcointalkorgindexphptopic=972541msg10619684msg10619684 2015 [Online accessed 1-May-2015]4 Eli Ben Sasson Alessandro Chiesa Christina Garman Matthew Green Ian Miers Eran Tromer and Madars Virza Zerocash Decentralized anonymous payments from bitcoin In Security and Privacy (SP) 2014 IEEE Symposium on pages 459ndash474 IEEE 20145 Evan Duffield and Kyle Hagan Darkcoin Peertopeer cryptocurrency with anonymous blockchain transactions and an improved proofofwork system 20146 Eiichiro Fujisaki and Koutarou Suzuki Traceable podpis pierścieniowy In Public Key CryptographyndashPKC 2007 pages 181ndash200 Springer 20077 Javier Herranz Aggregate signatures httpwwwiiiacsices~jherranzpapersNijmegen_seminar_aggregatepdf oct 20058 Joseph K Liu Victor K Wei and Duncan S Wong Linkable spontaneous anonymous group signature for ad hoc groups In Information Security and Privacy pages 325ndash335 Springer 20049 Adam Mackenzie Surae Noether and Monero Core Team Improving obfuscation in the cryptonote protocol httpslabgetmoneroorgpubsMRL-0004pdf January 201510 Greg Maxwell Coinjoin Bitcoin privacy for the real world august 2013 Bitcoin Forum httpsbitcointalkorgindexphptopic=2792490 2013 [Online accessed 1-July-2015]11 Greg Maxwell Confidential Transactions httpspeoplexiphorg~gregconfidential_valuestxt 2015 [Online accessed 1-June-2015]12 Greg Maxwell Elements project httpsgithubcomShenNoetherMiniNero 201513 Satoshi Nakamoto Bitcoin A peer-to-peer electronic cash system Consulted 1(2012)28 200814 Shen Noether Mininero httpsgithubcomShenNoetherMiniNero 201515 Ronald L Rivest Adi Shamir and Yael Tauman How to leak a secret In Advances in CryptologyASIACRYPT 2001 pages 552ndash565 Springer 200116 Nicolas van Saberhagen Cryptonote v 2 0 HYPERLINK https cryptonote org whitepaper pdf 2013

Załącznik A Załącznik Security ProofsA1 Brak możliwości sfałszowania MLSAG

Obliczenia przebiegają analogicznie do [8 Teoremat 1] Niech H1 oraz H2 będą losowo wybranymi oracle a SO stanowią podpisy oracle zwracające ważne podpisy MLSAG Załoacuteżmy że istnieje probabilistyczny wielomianowy adwersarz czasowy (PPT) A ktoacutery posiada zdolność sfałszowania MLSAG z listy wektoroacutew kluczy L przy prawdopodobieństwie ktoacuterego nie można pominąć

Gdzie Q1 stanowi wielomianowy parametr bezpieczeństwa k oraz gdzie (m σ) nie stanowi jednego z podpisoacutew zwracanych przez SO Załoacuteżmy że A nie wysyła więcej niż qH + nqS

(gdzie n oznacza liczbę kluczy w L) zapytań dotyczących podpisoacutew oracle H1H2 oraz SO odpowiednio Podpisy oracle H1 oraz H2 uważa się za niezależne i losowe oraz spoacutejne z danymi zapytaniami powtarzającymi się Podpis oracle SO może składać zapytanie H1 oraz H2 Mając wartość A wykaże że istnieje możliwość utworzenia adwersarza M w PPT ktoacutery będzie wykorzystywać A w celu znalezienia logarytmu dyskretnego jednego z kluczy w L

Jeżeli L stanowi zbioacuter kluczy wektoroacutew z ktoacuterych każdy będzie mieć wielkość r (tzn z kluczami publicznymi y1 hellip yr ) to wygenerowany fałszywy podpis

Wygenerowany przez A musi spełniać warunek

Gdzie i są obliczone w ramach mod n oraz są zdefiniowane zgodnie z Rozdziałem 22 Nowy adwersarz M może wykorzystać A w celu sfałszowania podpisoacutew wielomianową liczbę razy i zapisze każdy skrypt Turinga T niezależnie czy sfałszowanie było skuteczne czy nie

Lemma A1 [8 Lemma 1] Niech M wywołuje A w celu uzyskania transkrypcji T Jeżeli T jest skuteczne to M powraca do T do nagłoacutewka H i następnie re-symuluje A w celu uzyskania transkrypcji Trsquo Jeżeli Pr (T okaże się skuteczne) = ϵ to Pr (Trsquo jest skuteczne) = ϵ

Dowoacuted wynika wprost z przywołanego teorematu

Teoremat A2 Prawdopodobieństwo że adwersarz A sfałszuje podpis MLSAG można pominąć przy założeniu logarytmu dyskretnego

Dowoacuted Do przeprowadzenia dowodu będę stosować notację przedstawioną powyżej Podobnie jak w przypadku [8 teoremat 1] ponieważ prawdopodobieństwo odgadnięcia danych wyjściowych z losowego oracle jest znikome w związku z tym dla każdego skutecznego oszustwa A wprowadza transkrypcję uzupełniającą T a zatem mamy mT zapytań w przypadku zapytań do H1 odpowiadających liczbie n zapytań wykorzystywanych w celu weryfikacji podpisu W związku z tym niech Xi1 hellip Xim oznacza zapytania wykorzystywane w procesie weryfikacji fałszu ith oraz niech π oznacza indeks odpowiadający ostatniemu zapytaniu weryfikacyjnego dla danego oszustwa

(Intuicyjnie π odpowiada temu co może stanowić indeks sekretny fałszywego podpisu ponieważ odpowiada on ostatniemu wezwaniu ostatniemu wywołaniu losowego oracle dla danego odpisu)Proacuteba sfałszowania σ podjęta przez A stanowi fałsz (l π) jeżeli i1 = l oraz π jest zgodne z powyższym (zatem fałsz odpowiada zapytaniom l do l + π) Z założenia istnieje para (l π) taka że prawdopodobieństwo związanej transkrypcji T daje skutecznie wygenerowany fałszywy klucz ϵlπ (T) spełnia warunek

1

Teraz przeglądając T do wartości przed zapytaniem l-tym a następnie podejmując proacutebę sfałszowania za pomocą tego samego zbioru kluczy (oraz dopuszczając aby H1 obliczyło nowe rzuty monetami dla wszystkich kolejnych zapytań) z Lemmy A1 wynika że prawdopodobieństwo że Trsquo jest także skuteczne spełnia warunki

_Dlatego prawdopodobieństwo że zaroacutewno T jak i Trsquo odpowiadają weryfikacjom fałszywym σ i σ1 nie może zostać pominięte

Ponieważ nowe rzuty monetami zostały obliczone na podstawie danych wyjściowych losowych oracle H1 oznacza to że przy dużym prawdopodobieństwie istnieje wartość j taka

że oraz W związku z tym możemy rozwiązać klucz prywatny z indeksem π

ktoacutery jest sprzeczny z założeniami logarytmu dyskretnego

A2 Linkowalność MLSAG Teoremat A3 Linkowalność obrazu klucza (Key-Image Linkability) Prawdopodobieństwo że adwersarz a w PPT może utworzyć dwa podpisy weryfikujące (niepołączone w danym

ustawieniu σ σrsquo podpisane w odniesieniu do wektoroacutew kluczy oraz odpowiednio w taki

sposoacuteb że będzie istnieć klucz publiczny i w obu oraz może być pominięte

Dowoacuted Przypuśćmy że w przeciwieństwie do tego co zostało wcześniej powiedziane A utworzył dwa podpisy weryfikujące σ oraz σrsquo o oba są podpisami w odniesieniu do kluczowych wektoroacutew

oraz odpowiednio w taki sposoacuteb że istnieje klucz publiczny y zaroacutewno w jak i

Niech y występuje jako element j należący do a jrsquo jako element należący do rsquo Z teorematu A2 wynika z dużym prawdopodobieństwem że istnieją indeksy π oraz πrsquo dla kluczy publicznych σ oraz σrsquo odpowiednio takie że

oraz

z

oraz

Jeżeli uznamy że x oznacza klucz prywatny y y = xG to po rozwiązaniu powyższego dla Ij

oraz Ij0rsquo mamy następujące roacutewnania oraz podobnie Ijrsquo = xH (y) Tym samym dwa podpisy obejmują Ij = Ijrsquo i w związku z tym ponieważ zduplikowane obrazy kluczy są odrzucone jeden z nich nie może być wykorzystany do weryfikacji

A3 Anonimowość MLSAG W celu udowodnienia anonimowości powyższego protokołu w losowym modelu oracle przyjmijmy że H1 H2 to losowe oracle modelujące dyskretne funkcje haszujące Niech A to adwersarz anonimowości Buduję adwersarza M względem założenia problemu decyzyjnego Diffie Helmana (DDH) zgodnie z poniższym Założenie DDH stwierdza że mając daną krotność (G aG bG ϒG) prawdopodobieństwo ustalenia czy G = abG jest znikome

Teoremat A4 Protokoacuteł pierścieniowy CT jest dwuznaczny w odniesieniu do sygnatariusza przy założeniu problemu decyzyjnego Diffie-HelmanaDowoacuted (zbliżony do dowodu [8 Teoremat 2]) Załoacuteżmy że problem decyzyjny Diffie-Helmana jest trudny w cyklicznej grupie generowanej przez G i załoacuteżmy że istnieje adwersarz A w czasie PPT względem dwuznaczności sygnatariusza Tym samym mając listę L n wektoroacutew

kluczy publicznych o długości m oraz zbioacuter prywatnych kluczy t ważny podpis σ na L podpisany przez użytkownika w odniesieniu do wektora klucza y taki że

odpowiedni wektor klucza prywatnego wynosi spełnia to A może zdeterminować π z prawdopodobieństwem

Dla wybranych wielomianoacutew Q(k) Buduję adwersarza PPT M ktoacutery wykorzystuje krotność danych wejściowych (G aG bG ciG) gdzie I ϵ 0 1 jest losowo wybrany (a nie znany M a priori) c1 = ab oraz c0 jest losowym skalarem a dane wyjściowe i mają prawdopodobieństwo

Dla niektoacuterych wielomianoacutew Q2 (k)Należy rozważyć algorytm SIMNIZKP (zbliżony to tego ktoacutery został zdefiniowany w [6]) ktoacutery jako skalary wejściowe wykorzystuje wektor x klucza prywatnego zbioacuter wektoroacutew kluczy

publicznych indeks π oraz wiadomość m i ktoacutery działa w sposoacuteb następujący1 Wygenerować skalary losowe s1 hellip sm oraz skalar losowy cπ lt- H2 Dla j indeksującego określić

A dla pozostałych j

3 Obliczyć losowe dane wyjściowe na podstawie losowego oracle

4 Dla każdego i roboczego mod m obliczyć

Należy podkreślić że w ostatnim punkcie kiedy i = π - 1 to ci+1 jest już określone w celu utrzymania spoacutejności z losowymi danymi wyjściowymi oracleNależy podkreślić że niezależnie od tego czy jest rzeczywistym kluczem prywatnym odpowiadającym ze względu na to że spoacutejność jest zachowywana przez losowe wartości oracle w kolejnych wezwaniach powyższy podpis jest weryfikowany Jeżeli x jest rzeczywiście wektorem klucza prywatnego y to nie ma roacuteżnicy pomiędzy SIMNIZKP oraz rzeczywistym podpisemNa koniec mając krotność (G aG bG ciG) gdzie a b są losowo wybrany skalarami a c1 = ab c0 elementem losowym i ϵ 0 1 M zachodzi w poniższych krokach i pozwala rozwiązać problem decyzyjny Diffie Helmana za pomocą niepomijalnego prawdopodobieństwa M wychwytuje losowe ϒ lt-H z losowej wartości oracle oraz pobiera parę wektoroacutew klucza prywatnego publicznego (x y) a następnie oblicza s jako a = s + ϒx Teraz M wykonuje

SIMNIZKP za pomocą dowolnie wybranych wektoroacutew kluczy w taki sposoacuteb że w danej wiadomości m oraz Jeżeli prawdziwe jest że i = 1 to c = ab oraz logGaG = logbGcG = a

z uwagi na to że zakłada się iż A jest w stanie znaleźć π z prawdopodobieństwem ktoacuterego nie można pominąć to istnieje niepomijalne prawdopodobieństwo frac12 że A zwroacuteci 1 (i wtedy M zwroacuteci 1) Jeżeli i = 0 to A zwraca 1 wyłącznie z prawdopodobieństwem frac12 a zatem dla niektoacuterych niepomijanych prawdopodobieństw powyżej 1`2 M zwraca tę samą wartość co A i tym samym rozwiązuje problem decyzyjny Diffie-Helmana dla losowo wybranych skalaroacutew bez pomijalnego prawdopodobieństwa powyżej 12 co stanowi sprzeczność

Załącznik B Kod demo Ring CT W repozytorium w [14] zbudowałem prostą demonstrację protokołu poufnych transakcji pierścieniowych (Ring Confidential Transactions) wykorzystujących podpisy MLSAG w części 2 oraz podpisy ASNL w części 5

H_ct = RingCTgetHForCT()print(H H_ct)sr Pr = PaperWalletskpkGen() receivers private publicse pe ss = ecdhecdhgen(Pr) compute shared secret ssdigits = 14 in practice it will be 14print(inputs)Cia L1a s2a sa ska = RingCTgenRangeProof(10000 digits)print(outputs)Cib L1b s2b sb skb = RingCTgenRangeProof(7000 digits)Cic L1c s2c sc skc = RingCTgenRangeProof(3000 digits)print(verifying range proofs of outputs)RingCTverRangeProof(Cib L1b s2b sb)RingCTverRangeProof(Cic L1c s2c sc)x P1 = PaperWalletskpkGen()P2 = PaperWalletpkGen()C2 = PaperWalletpkGen()some random commitment grabbed from the blockchainind = 0Ca = RingCTsumCi(Cia)Cb = RingCTsumCi(Cib)Cc = RingCTsumCi(Cic)sk = [x MiniNerosc_sub_keys(ska MiniNerosc_add_keys(skb skc))]

pk = [[P1 P2] [MiniNerosubKeys(Ca MiniNeroaddKeys(Cb Cc)) MiniNerosubKeys(C2 MiniNeroaddKeys(Cb Cc)) ] ]II cc ssVal = MLSAGMLSAG_Sign(pk sk ind)print(Sig verified MLSAGMLSAG_Ver(pk II cc ssVal) )print(Finding received amount corresponding to Cib)RingCTComputeReceivedAmount(pe sr MiniNeroaddScalars(ss skb) Cib)print(Finding received amount corresponding to Cic)RingCTComputeReceivedAmount(pe sr MiniNeroaddScalars(ss skc) Cic)

Przykład transakcji z danymi wejściowymi 10 000 oraz wyjściowymi 3 000 i 7 000(rsquoHrsquo rsquo61fe7f0f5a607a33427d01dd1fded5ffa03fae2e9df9ebccf2e0a2f5bd77a204rsquo)inputs(rsquob b in binaryrsquo 10000 [0 0 0 0 1 0 0 0 1 1 1 0 0 1])Generating Aggregate Schnorr Non-linkable Podpis pierścieniowy outputs(rsquob b in binaryrsquo 7000 [0 0 0 1 1 0 1 0 1 1 0 1 1 0])Generating Aggregate Schnorr Non-linkable Podpis pierścieniowy (rsquob b in binaryrsquo 3000 [0 0 0 1 1 1 0 1 1 1 0 1 0 0])Generating Aggregate Schnorr Non-linkable Podpis pierścieniowy verifying range proofs of outputsVerifying Aggregate Schnorr Non-linkable Podpis pierścieniowy VerifiedVerifying Aggregate Schnorr Non-linkable Podpis pierścieniowy Verified(rsquoGenerating MLSAG sig of dimensions rsquo 2 rsquox rsquo 2)(rsquoverifying MLSAG sig of dimensions rsquo 2 rsquox rsquo 2)(rsquocrsquo[rsquo80a3cfd06dd2862307cd75c2a1566f20cd743dbb0b9feb22d79dcbecb9023f42rsquorsquoa9b7342ba7bf2f102505ca19dab734fde638916c0a29f5b30e49833ab51393earsquorsquo80a3cfd06dd2862307cd75c2a1566f20cd743dbb0b9feb22d79dcbecb9023f42rsquo])(rsquosig verifiesrsquo True)(rsquoSig verifiedrsquo True)Finding received amount corresponding to Cib(rsquoreceived rsquo 7000c Monero Research Lab Page 20 of 20rsquoa488ec68732fb551841c2c6dcc7ffac895d98ec7e9378275ed20ea12805fc18ersquo)Finding received amount corresponding to Cic(rsquoreceived rsquo3000rsquo1b46626858e130a0f3884c74c9fdeabc4d812c519103ea16a35a3f82a3d0ed6drsquo)

CryptoNote [16] oraz Ring Coin [2] pozwoliły przenieść to rozwiązanie na wyższy poziom zaawansowania dzięki wykorzystaniu ldquoring signaturesrdquo ndash podpisoacutew pierścieniowych ktoacutere pierwotnie zostały zdefiniowane w [15] jako ldquopodpis cyfrowy odnoszący się do grupy osoacuteb potencjalnie uprawnionych do składania podpisoacutew w taki sposoacuteb że osoba dokonująca weryfikacji nie jest w stanie określić ktoacutery z użytkownikoacutew złożył podpisrdquo Głoacutewnym celem jest ukrycie klucza transakcji źroacutedłowej w grupie kluczy publicznych z ktoacuterych każdy zawiera tę samą liczbę coinoacutew oraz w celu zamaskowania źroacutedła transakcjiOryginalny protokoacuteł CryptoNote opisany w [16] uwzględnia drobną modyfikację tego rozwiązania uniemożliwiającą podwoacutejne wydatkowanie środkoacutew Mianowicie w [16] wykorzystywany jest ldquotraceable ring signaturerdquo ndash podpis pierścieniowy możliwy do prześledzenia ktoacutery stanowi nieznaczną modyfikację rozwiązania o ktoacuterym mowa w [6] Ten rodzaj podpisu pierścieniowego ma tę przewagę że nie dopuszcza możliwości złożenia dwoacutech roacuteżnych podpisoacutew pierścieniowych przez właściciela coinoacutew przy wykorzystaniu tego samego klucza publicznego bez odnotowania tego faktu w blockchainie Oczywiście głoacutewnym celem tego rozwiązania jest zapobieganie ldquopodwoacutejnemu wydatkowaniurdquo co w przypadku Bitcoina dotyczy dwukrotnego wydatkowania coina Ring coin [2 3] wykorzystuje nieco bardziej wydajny linkowalny podpis pierścieniowy ktoacutery stanowi nieznaczną modyfikację podpisoacutew Linkable Spontaneous Anonymous Group opisanych w [8]Jedną z zalet wykorzystywania wyżej wymienionych typoacutew podpisoacutew pierścieniowych w stosunku do pozostałych technik anonimizacji takich jak np CoinJoin [10] lub usługi miksowania walut jest to że umożliwiają one miksowanie ldquospontanicznerdquo W przypadku technik CoinJoin lub technik miksujących istnieje podobna możliwość ukrywania źroacutedła (inicjatora) danej transakcji chociaż techniki te w praktyce wymagają minimalnego udziału zcentralizowanego menadżera grupy w postaci zcentralizowanego serwera CoinJoin w ktoacuterym transakcje są łączone (kombinowane) przez zaufaną stronę W sytuacji gdy zostanie naruszone bezpieczeństwo zaufanej strony anonimowość transakcji także ulega złamaniuNiektoacutere coiny takie jak np Dash (oryginalna nazwa Darkcoin) [5] podejmują proacutebę negacji [tego systemu] poprzez wykorzystanie większej liczby zaufanych mikseroacutew (w tym przypadku masternodes) ale ich liczba jest w dalszym ciągu znacznie mniejsza niż użytkownikoacutew coinoacutew Dla odmiany w przypadku zastosowania spontanicznych podpisoacutew pierścieniowych transakcje mogą być tworzone przez właściciela danego klucza publicznego (właściwość spontaniczna lub ldquoad-hocrdquo) bez konieczności korzystania z zaufanego serwera co efekcie gwarantuje wyższy poziom anonimowościJeden z potencjalnych atakoacutew na oryginalną technologię CryptoNote lub protokoacuteł [216] to analiza blockchainowa w oparciu o kwoty przekazywane w danej transakcji Na przykład jeżeli przeciwnik wie że 09 coinoacutew zostało wysłanych w danym czasie to może być w stanie zawęzić możliwości wysyłającego analizując transakcje zawierające 09 coinoacutew Jest to w pewnym sensie negowane poprzez wykorzystanie kluczy jednorazowych stosowanych w [16] ponieważ wysyłający może wprowadzić dowolną liczbę adresoacutew zmiany w transakcji tym samym maskując kwotę ktoacutera została wysłana przy zastosowaniu miksowania typu ldquoknapsackrdquo Nie mniej jednak technika ta posiada pewne niedogodności w postaci zdolności do tworzenia dużych ilości transakcji typu ldquodustrdquo [pył kurz] w blockchainie tzn transakcji składających się z niewielkich kwot ktoacutere wykorzystują proporcjonalnie więcej przestrzeni niż wynikałoby to z ich znaczenia Dodatkowo odbiorca coinoacutew może być zmuszony do ldquousunięciardquo tego całego pyłu podczas wysyłania i umożliwić inteligentnemu przeciwnikowi śledzenie tego ktoacutere klucze wykazują pewne wspoacutelne elementy Dodatkowo łatwo jest określić goacuterną i dolną granicę wysyłanych kwotKolejną niedogodnością związaną z oryginalnym ustawieniem CryptoNote jest to że wymaga on aby dana para (Prsquo A)rsquo obejmująca klucz publiczny P oraz kwotę A była wykorzystywana w podpisie pierścieniowym wraz z innymi kluczami publicznymi związanymi z taką samą kwotą W przypadku mniej popularnych kwot oznacza to że może wystąpić mniejsza liczba potencjalnych par (Prsquo Arsquo) dostępnych w blockchainie wraz z Arsquo = A ktoacutere można umieścićpowiązaćpodpisać danym podpisem pierścieniowym Dlatego w oryginalnym protokole CryptoNote potencjalny zbioacuter anonimowych transakcji jest prawdopodobnie

mniejszy niż można by tego oczekiwać Analiza wyżej opisanych słabych punktoacutew przedstawiona jest w [9]

12 Pierścień CT dla MoneroOczywistym sposobem negowania słabych stron protokołu CryptNote zgodnie z opisem w poprzedzającym ustępie może być zaimplementowanie ukrytych kwot dla dowolnej transakcji W niniejszym dokumencie przedstawiam zmiany wprowadzone do protokołu Monero kryptowaluty opartej na algorytmie proof-of-work stanowiącej rozszerzenie pierwotnego protokołu CryptoNote ktoacutera umożliwia ukrycie (zamaskowanie) kwot przekazywanych w ramach danej transakcji Modyfikacja ta zasadza się na Transakcjach Poufnych [11] ktoacutere są wykorzystywane w łańcuchu bocznym elementoacutew bitcoina z tą roacuteżnicą że umożliwia ona ich wykorzystanie w ramach podpisoacutew pierścieniowych Dlatego też modyfikacja ta otrzymuje oczywistą nazwę Pierścieniowe Transakcje Poufne dla systemu [waluty] MoneroAby zachować właściwość uniemożliwiającą dwukrotne wydatkowanie coinoacutew przedstawiam opis pewnego uogoacutelnienia LSAG w [8] ndash podpis typu Multilayered Linkable Spontaneous Anonymous Group Signature (MLSAG) ktoacutery umożliwia kombinację Transakcji Poufnych opatrzonych podpisami pierścieniowymi w taki sposoacuteb że wykorzystywanie mnogich danych wejściowych i wyjściowych będzie możliwe z zachowaniem anonimowości przy jednoczesnym uniemożliwieniu podwoacutejnego wydatkowania Autor podkreśla że zasadniczo podobny protokoacuteł został zaproponowany przez Connora Frenkenechta około miesiąc po ukazaniu się drugiej wersji oryginału niniejszego dokumentu

13 Silnie zdecentralizowane systemy płatności anonimowych [Strongly Decentralized Anonymous Payment Schemes]Protokoacuteł pierścieniowy CT [Ring CT] umożliwia tworzenie ukrytych kwot źroacutedeł oraz adresatoacutew transakcji i jest nieco zbliżony do systemu Zerocash [4] Jedna z potencjalnych roacuteżnic polega na wykorzystaniu proof of work w celu generowania coinoacutew za pomocą protokołu Ring CT w odroacuteżnieniu od ZeroCash gdzie jak się wydaje wszystkie coiny muszą być wstępnie wygenerowane przez zaufaną grupęNależy podkreślić że jedną z największych innowacji w systemie Bitcoin [13] był zdecentralizowany model dystrybucji umożliwiający dowolnej zainteresowanej osobie udostępnienie swoich mocy obliczeniowych do pracy i uczestnictwo w procesie generowania waluty Niektoacutere korzyści wynikające z tego typu algorytmu proof-of-work obejmują niezaufane motywacje do zabezpieczania sieci oraz jeszcze silniejszej decentralizacji (na przykład do ochrony przed atakami typu poison-pill ndash trujące pigułki)Jedną z oczywistych końcowych korzyści generowania coinoacutew w oparciu o algorytm proof-of-work jest to że pozwala on na uodpornienie Ring CT na działania podejmowanego przez silnego aktora ktoacutery potrafi znaleźć sposoacuteb na znalezienie wszystkich fragmenty klucza głoacutewnego wykorzystywanego do generowania coinoacutew Ponieważ mamy do czynienia z oczywistym poważnym bodźcem (jakim jest zdolność do generowania darmowych środkoacutew finansowych [1]) do pozyskiwania wszelkich fragmentoacutew procesu generacji zaufanego klucza kwestia ta jest dość istotna

14 PodziękowaniaChciałbym podziękować zespołowi Monero za udzieloną pomoc rozmowy dotyczące procesu opracowywania niniejszej publikacji oraz całej społeczności portali Monero oraz Bitcoin za wsparcie i udział w dyskusji Jeżeli chodzi o ujawnianie (poufność) autor otrzymał kilka donacji o łącznej wartości od 2 do 3 bitcoinoacutew ze strony społeczności Monero na dowoacuted ich wdzięczności i w uznaniu wkładu w niniejszą pracę badawczą

2 Podpisy typu Multilayered Linkable Spontaneous Anonymous Group Signatures

Niniejszy rozdział zawiera definicję podpisoacutew typu Multilayered Linkable Spontaneous Anonymous Group (MLSAG) wykorzystywanych przez protokoacuteł Ring CT Należy podkreślić że definiuję je jako podpis ogoacutelny a niekoniecznie jako przykład wykorzystania w Pierścieniowych Transakcjach Poufnych MLSAG jest zasadniczo zbliżony do LSAG-oacutew opisanych w [8] ale zamiast składać podpis na zbiorze n kluczy MLSAG sam w sobie stanowi podpis pierścieniowy na zbiorze wektoroacutew n kluczy

Definicja 21 Wektor kluczy jest po prostu zbiorem kluczy publicznych odpowiadających kluczom prywatnym

[1] Poprzednio autor założył że mogłoby to roacutewnież umożliwić ujawnienie (odsłonięcie) transakcji ale najnowsza publikacją dotycząca ZeroCash wyraźnie stwierdza że to niemożliwe

21 Podpisy LWW a podpisy FS Podpisy pierścieniowe wykorzystywane w Monero oraz oryginalny protokoacuteł CryptoNote są pochodnymi podpisoacutew pierścieniowych możliwych do wyśledzenia z [6] Podpisy pierścieniowe w ramach CryptoNote [16] zawierają ldquoobraz kluczardquo co oznacza że podpisujący może podpisać jeden pierścień w blockchainie używając danego klucza publicznego oraz pary kluczy prywatnych albo ich transakcja zostanie oznaczona jako nieważna W związku z tym wykorzystywane są klucze jednorazowe w protokole CryptoNote ktoacutere następnie podnoszą poziom anonimowościW [3] Adam Back podkreśla że podpisy w ramach Linkable Spontaneous Anonymous Group (LSAG) w [8] mogą być modyfikowane w taki sposoacuteb aby utworzyć bardziej wydajny linkowany podpis pierścieniowy dający ten sam efekt jaki uzyskuje się w przypadku podpisu pierścieniowego z [6] Modyfikacja ta pozwala obniżyć koszty przechowywania w blockchainie zasadniczo o połowęNa początek przytoczę ndash niemal dosłownie ndash modyfikacje opisane w [3]Keygen [Generowanie klucza] Znajdź pewną liczbę kluczy publicznych Pi i = 0 1 hellip n oraz sekretny indeks j spełniający warunek xG = Pj gdzie G stanowi punkt bazowy ed25519 a x to klucz wydatkowany sygnatariuszy Niech I = xHp (Pj) gdzie Hp jest funkcją haszującą zwracającą punkt [2] Niech m stanowi daną wiadomośćPODPIS Niech α si i ne j i ϵ 1 hellip n będą wartościami losowymi w Zq (pole bazowe ed25519)ObliczLj = αGRj = αHp (Pj)cj+1 = h (m Lj Rj)gdzie h jest funkcją haszującą zwracającą wartość w Zq Teraz dokonując kolejnych obliczeń j modulo n należy zdefiniowaćLj+1 = sj+1G + cj+1Pj+1Rj+1 = sj+1Hp (Pj+1) + cj+1 _ Icj+2 = h (m Lj+1 Rj+1)hellip

Lj-1 = sj-1G + cj-1Pj-1Rj-1 = sj-1Hp (Pj-1) + cj-1∙ Icj = h (mLj-1 Rj-1)

[2] W praktyce Hp(P) = Keccak(P) ∙ G gdzie G jest punktem bazowym ed25519 chociaż należy zauważyć że w odniesieniu do układu zobowiązań będę wykorzystywać toPoint(Keccak(P)) haszujący kolejno aż do zwrotu wielokrotności punktu bazowego przez Keccak(P)

po to aby umożliwić definicję c1 hellip cnNiech sj = α - cj ∙ xj mod l (l stanowi porządek krzywej ed25519) stąd α = sj + cjxj mod l w taki sposoacuteb że Lj = _G = sjG + cjxjG = sjG + cjPjRj = _Hp (Pj) = sjHp (Pj) + cjIorazcj+1 = h (m Lj Rj)stąd mając jednostkową wartość ci wartości Pj obraz klucza I oraz wszystkie wartości sj pozostałe ck k 6= i mogą być odkryte przez obserwatora Podpis w związku ma postaćα = (I c1 s1 hellip sn)reprezentując oszczędności w zakresie zajmowanego miejsca w stosunku do [16 44] gdzie podpis pierścieniowy moacutegłby zamiennie wyglądać w następujący sposoacutebα = (I c1 hellip cn s1 hellip sn)Weryfikacja przebiega w następujący sposoacuteb Obserwator oblicza wartości Li Ri oraz ci dla wszystkich i oraz weryfikuje czy cn+1 = c1 Następnie weryfikator sprawdza czy

ci+1 = h (m Li Ri)dla wszystkich i mod nLINK Podpisy z duplikatami obrazoacutew kluczy I są odrzucaneNależy podkreślić że protokoły proofs of unforgeability anonimowości oraz łączenia obowiązują i stanowią jedynie nieznaczne modyfikacje protokołoacutew proof o ktoacuterych mowa w [8] Przedstawię nieco bardziej uogoacutelnioną wersję tych protokołoacutew dla MLSAG

22 Opis MLSAG W odniesieniu do protokołu Ring CT ktoacuterego opis znajduje się w części 4 wymagam uogoacutelnienia podpisoacutew Back LSAG opisanych w poprzednim rozdziale co umożliwia stosowanie wektoroacutew kluczy (Definicja 21) zamiast po prostu kluczyPrzypuśćmy że każda osoba składająca podpis pod (uogoacutelnionym) pierścieniem

zawierającym n członkoacutew (uczestnikoacutew) ma dokładnie m kluczy Celem podpisu pierścieniowego MLSAG jest realizacja następujących celoacutew

udowodnienie że jeden z podpisujących n zna sekretny klucz właściwy dla całego wektora klucza

Zapewnienie że jeżeli podpisujący wykorzystuje jeden z kluczy podpisoacutew m w innym podpisie MLSAG to dwa pierścienie są połączone a drugi taki podpis MLSAG (zlecony przez blockchain Monero) zostanie odrzucony

Algorytm działa w sposoacuteb następujący niech m stanowi wiadomość Niech π jest sekretnym indeksem odpowiadającym sygnatariuszowi uogoacutelnionego pierścienia Dla j = 1 hellip m niech

oraz dla j = 1 hellip m i = 1 hellip π hellipn (gdzie π oznacza ominięcie indeksu π) niech stanowi jeden z losowych skalaroacutew (elementoacutew Zq) Teraz w sposoacuteb analogiczny do części 21 należy zdefiniować

dla skalaroacutew losowych αj oraz j = 1 hellip m A teraz ponownie analogicznie do części 21 należy określić

i powtoacuterzyć czynność zwiększając przyrostowo i modulo n aż do momentu uzyskania następującej postaci

Na koniec dla każdego rozwiązać mod l Podpis jest następnie przekazywany jako zatem kompleksowość wynosi O (m(n + 1)) Proces weryfikacji przebiega poprzez regenerację wszystkich zaczynając od i = 1 podobnie jak to miało miejsce w części 21 (ktoacutera

stanowi przypadek szczegoacutelny w ktoacuterym m = 1) i przeprowadzając sprawdzenie funkcji haszującej cn+1 = c1 Jeżeli wartości te są wykorzystywane w ustawieniu blockchainowym takim jak Monero podpisy składane za pomocą obrazoacutew kluczy Ij ktoacutere już się pojawiły są następnie odrzucane Można to w bardzo łatwy sposoacuteb wykazać stosując metodę zbliżoną do [8] że

Prawdopodobieństwo że sygnatariusz generujący ważny podpis bez znajomości wszystkich prywatnych kluczy ldquomrdquo należących do ich wektora kluczy dla indeksu π może być pominięty

Prawdopodobieństwo że sygnatariusz nie podpisze żadnego klucza z indeksu π może zostać pominięte (Innymi słowy wszystkie obrazy kluczy stanowiące część podpisu muszą pochodzić z indeksu π)

Jeżeli sygnatariusz podpisuje dwa pierścienie wykorzystując co najmniej jeden z tożsamych kluczy publicznych to następuje skojarzenie (połączenie) dwoacutech pierścieni

Szersze omoacutewienie tych elementoacutew znajduje się w dalszej części materiału dotyczącej zabezpieczeń (security proofs)

23 Model zabezpieczeń MLSAGMLSAG spełnia trzy niżej wymienione właściwości niefałszowalność (Unforgeability) linkowalność (Linkability) oraz Dwuznaczność Sygnatariusza (Signer Ambiguity) ktoacutere są bardzo zbliżone do definicji podanej w [8]

Definicja 22 Niefałszowalność (Unforgeability) System podpisoacutew MLSAG jest niemożliwy do sfałszowania jeżeli dla danego algorytmu A wielomianowego czasu probabilistycznego (PPT) z podpisem oracle SO generującego ważne podpisy oraz dla danej listy wektoroacutew kluczy publicznych n wybranej przez A A może generować przy pomijalnym prawdopodobieństwie ważny podpis w sytuacji gdy A nie zna jednego z odpowiednich wektoroacutew kluczy prywatnych

Uwaga 23 W poniższej definicji należy zauważyć że umieściłem funkcję odrzucania duplikujących się obrazoacutew kluczy jako części kryterioacutew weryfikacji dla MLSAG co przyczynia się do zbudowania nieco zmodyfikowanej definicji linkowalności (Linkability) w stosunku do tej ktoacutera została podana w [8]

Definicja 24 Linkowalność (Linkability) Niech L stanowi zbioacuter wszystkich kluczy publicznych w danym ustawieniu (np w danym łańcuchu blokowym - blockchainie) System składania podpisoacutew MLSAG w L jest połączony z obrazami kluczy jeżeli prawdopodobieństwo że

adwersarz A utworzy w PPT dwa podpisy σ σ1 podpisane w odniesieniu do wektoroacutew kluczy

oraz 1 z ktoacuterych każdy będzie zawierać ten sam klucz publiczny yi = yirsquo W L oraz każdy będzie weryfikowany bez oznaczenia jako duplikat jest pomijalne

Definicja 25 Dwuznaczność sygnatariusza (Signer Ambiguity) System składania podpisoacutew MLSAG uważa się za niejednoznacznie identyfikujący sygnatariusza jeżeli mamy dany podpis weryfikujący σ na wektorach kluczy oraz dowolny zbioacuter kluczy prywatnych t z ktoacuterych każdy będzie mieć oddzielny indeks oraz sekretny indeks w takiej sytuacji prawdopodobieństwo odgadnięcia klucza sekretnego wynosi mniej niż

Dowody potwierdzające powyższe definicje przedstawiono w Załączniku

3 Zarys historyczny transakcji poufnych31 Transakcje poufne w ramach system Bitcoin

W [11] Greg Maxwell opisuje transakcje poufne ktoacutere są pewną metodą przekazywania transakcji w systemie Bitcoin przy jednoczesnym maskowaniu kwot Podstawową kwestią jest stosowanie schematu zobowiązań Pedersena metoda ta jest doskonale opisana w cytowanym materiale źroacutedłowym W niniejszym opracowaniu wprowadzam drobną modyfikację do mechaniki Transakcji Poufnych polegającą na wybieraniu zamiast zobowiązań ktoacuterych suma wynosi zero opcji złożenia podpisu pod zobowiązaniem w celu wykazania że klucz prywatny jest mi znany Schemat ten jest opisany szczegoacutełowo w kolejnym rozdziale

32 Modyfikacja pod kątem podpisoacutew pierścieniowych Niech G stanowi punkt bazowy ed25519 Niech [3]

H = toPoint (cn_fast_hasz (G))

Należy podkreślić że nie każda wartość haszująca pozwala obliczyć punkt w ramach grupy punktu bazowego (tzn dla pewnej niewiadomej) (co jest sprzeczne z tym co dzieje się w secp256k1 krzywej wykorzystywanej w systemie Bitcoin) Nie mniej jednak wydaje się że wyboacuter punktu bazowego jako takiego (wcześniej wykorzystywałem H(123456G) sprawdza się co z resztą wydawało mi się bardziej bezpieczne przy czym punkt bazowy jest z pewnością bardziej naturalnym wyborem) Wyboacuter H = ϒG dla pewnej niewiadomej jest konieczny po to aby pełna matematyka zwykłych krzywych eliptycznych zachowała swoją ważność

[3] H = MiniNerogetHForCT() w kontekście kodu w [14]

Przy założeniu logarytmoacutew dyskretnych w ed25519 prawdopodobieństwo że adwersarz odkryje ϒ jest pomijalne Należy zdefiniować C (a x) = xG+aH zobowiązanie wartości a z maską x Należy podkreślić że tak długo jak wartość logGH nie jest znana oraz jeżeli σ ne 0 to logGC (a x) pozostaje wartością nieznaną Z drugiej strony jeżeli a = 0 to logGC (a x) = x a zatem istnieje możliwość złożenia podpisu za pomocą pary kluczy sk-pk (xC (0 x)) W [11] istnieją dane wejściowe I wyjściowe zobowiązań a sieć sprawdza czy

sumdane wejściowe = sumdane wyjściowe

Nie mniej jednak nie jest to wystarczające w przypadku systemu Monero ponieważ dana transakcja zawiera roacuteżne możliwe do realizacji dane wejściowe Pi i = 1 hellip n z ktoacuterych tylko jedna należa do nadawcy (patrz [16 44]) to jeżeli będziemy w stanie sprawdzić powyższe roacutewnanie to musi być możliwe aby sieć widziała ktoacutere Pi należy do nadawcy transakcji Nie jest to zjawisko pożądane ponieważ eliminuje anonimowość zbudowaną dzięki podpisowi pierścieniowemu W związku z tym zastępczo tworzy się zobowiązania dla danych wejściowych oraz wyjściowych zgodnie z poniższym (załoacuteżmy najpierw że istnieje tylko jeden zestaw danych wejściowych)

Cin = xcG + aHCout10485761 = y1G + b1HCout10485762 = y2G + b2H

W taki sposoacuteb że xc = y1+y2+z xc - y1 - y2 = z yi są wartościami maskującymi z gt 0 oraz a = b1+b2W tym przypadku xc stanowi szczegoacutelny prywatny klucz a ldquokwota kluczardquo znana jest tylko nadawcy oraz osobie do ktoacuterej coiny są wysyłane zatem musi być odmienna od normalnego klucza prywatnego W takim przypadku

= xcG + aH - y1G - b1H - y2G - b2H= zG

A zatem powyższe roacutewnanie staje się zobowiązaniem do 0 przy sk = z oraz pk = zG a nie rzeczywistym roacutewnaniem o sumie zerowej Należy podkreślić że z nie jest wyliczalne dla coinoacutew źroacutedłowych xc chyba że znana jest zaroacutewno wartość y1 jak i y2 nie mniej jednak nawet to można w prosty sposoacuteb złagodzić poprzez uwzględnienie dodatkowych adresoacutew zmiany (zwykły przypadek zakłada że drugie zobowiązanie z wartością y2 jako maską są wysyłane jako zmiana)Ponieważ podawanie informacji ktoacutere dane wejściowe należą do nadawcy nie jest pożądane podpis pierścieniowy zawierający wszystkie zobowiązania wejściowe Ci i = 1 hellip s hellip n (gdzie s stanowi sekretny indeks zobowiązania nadawcy) dodaje się odpowiedni klucz publiczny (dzięki czemu zobowiązania oraz klucze publiczne są parowane (Ci Pi) ale tylko takie ktoacutere mogą być wspoacutelnie wydatkowane) oraz odejmuje sumCout

Jest to podpis pierścieniowy ktoacutery może być złożony ponieważ znamy jeden z prywatnych kluczy (a mianowicie z + xrsquo zawierający z jak wyżej oraz xrsquoG = Ps) Tak naprawdę ponieważ wiemy że dla każdego i zaroacutewno klucze prywatne dla Pi jak i klucze prywatne dla Pi + Ciin - sumjCjout możemy złożyć podpis zgodnie z treścią rozdziału 22 Szczegoacuteły tej procedury są opisane w Definicji 41

Zgodnie z [11] ważne jest udowodnienie że kwoty wyjściowe [4] b1 hellip bn wszystkie mieszczą się w szeregu wartości dodatnich np (0 216) Można to osiągnąć zasadniczo w taki sam sposoacuteb jak w [11] kwestia ta jest bardziej szczegoacutełowo opisana w części 5Na koniec warto zauważyć że w powyższej dyskusji nie wspomniałem o właściwości związanej dołączaniem tagoacutew ktoacutera jest wykorzystywana w Monero oraz Cryptonote w celu zapobiegania podwoacutejnemu wydatkowaniu środkoacutew Dołączanie tagoacutew w tym momencie będzie skutkiem łączenia powyższego omoacutewienia z podpisami MLSAG o ktoacuterych mowa w Definicji 41

4 Ring CT dla protokołu Monero 41 Opis protokołuDefinicja 41 (Tagowalny pierścień CT z mnogimi danymi wejściowymi oraz kluczami jednorazowymi)

Niech stanowi zbioacuter adresoacutew oraz kluczy jednorazowychzobowiązań ktoacuterym odpowiadają sekretne klucze xj j = 1 hellip m

Znaleźć zbiory q + 1 i = 1 hellip q + 1 ktoacutere nie są połączone tagami w sensie [ 6 strona 6]

Należy określić zestaw adresoacutew wyjściowych (Qi Ciout) takich że

stanowią zobowiązania o wartości zero Niech

hellip

stanowi uogoacutelniony pierścień w ktoacuterym chcemy złożyć swoacutej podpis Należy zauważyć że ostatnia kolumna to pierścień Ring-CT w rozumieniu rozdziału 4

Obliczyć podpis MLSAG sum na R

[4] Ponieważ zobowiązania wejściowe mogą być potencjalnie odziedziczone z poprzednich transakcji wystarczy rozważyć kwoty wyjściowe

W takim przypadku zgodnie z teorematem A2 nie może być sygnatariuszem żadnych dodatkowych niezlinkowanych podpisoacutew pierścieniowych w danym nadzbiorze P wszystkich takich par P = (PC) po podpisaniu sum

Uwaga 42 Złożoność przestrzeni powyższego protokołu Warto zauważyć że rozmiar podpisu sum na R zgodnie z definicją 41 jest w rzeczywistości mniejszy dla m gt 1 niż bieżący podpis pierścieniowy transakcji opartej na protokole CryptoNote [16] ktoacutera zawiera mnogie dane wejściowe Dzieje się tak dzięki wprowadzeniu zmian w rozmiarze w [8] do każdej kolumny Należy także podkreślić że prawdopodobnie nie jest konieczne umieszczanie obrazu klucza zobowiązania związanego z wyżej wymienionym podpisem Kolejne optymalizacje rozmiaru są możliwe i można je wykonać w podobny sposoacuteb

42 Konwersja widocznych denominacji na zobowiązaniaPonieważ Monero obecnie wykorzystuje blockchainowe widoczne skalary w celu stworzenia reprezentacji kwot ważne jest aby istniała możliwość (i sposoacuteb) konwersji z kwot widocznych na zobowiązania przy jednoczesnym zachowaniu anonimowości Tak naprawdę wcale nie jest to trudne Mając daną parę (P a) gdzie P jest kluczem publicznym a a stanowi kwotę może ona być wykorzystana jako dane wejściowe transakcji jako (P aH) i transakcja ta musi być zweryfikowana przez weryfikatora pod kątem kwoty wejściowej i jej przemnożenia przez punkt maskujący H oraz czy uzyskana wartość rzeczywiście wynosi aH Zatem jako pierwszy krok kwoty wejściowe nie zostaną ukryte ale ukryte zostaną dane wyjściowe transakcji oraz wszelkie niezbędne relacje o ktoacuterych mowa w rozdziale 4 pozostają ważne Należy podkreślić że range proof nie jest konieczny dla tych danych wejściowych

Uwaga 43 Oczywistą zaletą tej metody jest konwersja z kwot widocznych na zobowiązania oraz to że kwota coinoacutew wygenerowanych w procesie wydobycia jest weryfikowalna bez konieczności udziału elementu zaufanego Jest to przewaga protokołu Ring CT nad systemami płatniczymi takimi jak [4] ktoacutere obejmują fazę ustawień strony zaufanej

43 Opłaty transakcyjnePonieważ system Monero jest silnie zdecentralizowany (tzn proof of work) konieczne jest wynagradzanie goacuternikoacutew i dokonywanie opłat za każdą transakcję Pomaga to podnieść bezpieczeństwo sieci i zapobiegać rozdęcia blockchainu Opłaty te muszą być realizowane w postaci niezamaskowanej tzn Jako bH a nie xG + bH oraz w odniesieniu do pewnej standardowej kwoty b w taki sposoacuteb że goacuternik będzie moacutegł zweryfikować że b ∙ H = bH i tym samym że jest dość środkoacutew na opłatę transakcyjną przy jednoczesnym zachowaniu roacutewnań związanych z H w taki sposoacuteb że zostaną zachowane niezbędne relacje o ktoacuterych mowa w Rozdziale 4

44 Ring MultisignatureWarto zauważyć że prosta wersja t z m z n ring-multisignature [mnogich podpisoacutew pierścieniowych] może być zrealizowana w oparciu o podpisy MLSAG Umożliwia to grupie m uczestnikoacutew zbudowanie multisignature takiego że t uczestnikoacutew z liczby z m musi złożyć podpis aby był on uznany za ważny dodatkowo jest on dwuznaczny w odniesieniu do sygnatariusza klucze m są uczestnikami mieszczącymi się w ogoacutelnej liczbie n kluczy

Liczba n uczestnikoacutew w multisignature stanowi wspoacutelny sekret xe oraz klucz publiczny Pe ktoacutere mają wspoacutelne obrazy kluczy multisig

Ij = xeH(PejPj)

z Pj ndash publicznym kluczem uczestnika Każdy uczestnik multisignature dokonuje wyboru dodatkowych kluczy publicznych n -

m w blockchainie oraz tworzy podpis MLSAG za pomocą pierwszego rzędu wszystkich kluczy n a drugi rząd ma dla każdego wpisu (elementu) klucz wspoacutelny Pe

Każdy sygnatariusz multisignature podaje początkowe Ij j = 1 hellip m w celu umożliwienia zaakceptowania klucza po przekazaniu podpisoacutew weryfikujących t w blockchainie z ktoacuterych każdy odpowiada jednemu obrazowi klucza Ij

Rozszerzony zapis ring-multisignature jest w fazie opracowania

5 Zagregowane schematy identyfikacji Schnorra (Aggregate Schnorr Range Proofs)W części [11] poufne transakcja bez podpisu pierścieniowego wykorzystuje pewien typ podpisu pierścieniowego oparty na [1] nazywany podpisem pierścienia boromejskiego (Borromean ring signature) i pomaga zidentyfikować przekłamania w wartości zobowiązań w pewnym przedziale W niniejszym artykule postaram się nakreślić alternatywną metodę zainspirowaną przez [7] ktoacutera pozwala na uzyskanie tych samych oszczędności w zakresie przestrzeni ale za to opatrzona jest nieco mniej skomplikowanym protokołem bezpieczeństwa Motywacja do tego typu działania jest następująca przypuśćmy że dana transakcja ma dane wejściowe zobowiązań roacutewne

Cin = ainG + 10H

oraz zobowiązania wyjściowe

Cout 1 = aout1G + 5H Cout2 = aout2G + 5H

Scenariusz ten zachowuje ważność gdyż istnieje możliwość złożenia podpisu dla Cin ndash Cout1 ndash Cout2 = (ain ndash aout1 ndash aout2)G

Nie mniej jednak warto podkreślić że (bez range proofs) będzie istniała możliwość alternatywnego ustawienia zobowiązań wyjściowych

Cout1 = aout1G- H Cout2 = aout2G + 11H

Ponieważ -1 jest bardzo dużą liczbą stanowiącą modulo porządkujące grupę krzywej tym samym zostały utworzone darmowe pieniądze Zatem konieczne jest wykazanie że Couti są zobowiązaniami w odniesieniu do wartości ktoacutere są pozytywne (dodatnie) i mieszczą się w ograniczonym przedziale [0 2n] dla niektoacuterych wartości n Aby tego dokonać należy rozłożyć każdą wartość wyjściową na elementy binarne

co pozwala obliczyć zobowiązania do bj ∙ 2j w taki sposoacuteb że

Na koniec wykorzystując sekretny klucz bj można obliczyć podpis pierścieniowy na

dla wszystkich j oraz zapewnia dla weryfikatoroacutew (w tym przypadku goacuternikoacutew)Jeżeli chodzi o oszczędności miejsca można albo wykorzystać boromejski podpis pierścieniowy (podobnie jak w [11]) albo połączyć wszystkie proste podpisy pierścieniowe bądź utworzyć pewien typ zagregowanego podpisu pierścieniowego zdefiniowanego w następujący sposoacuteb

501 Generowanie zagregowanego nielinkowanego podpisu pierścieniowego Schnorra (Aggregate Schnorr Non-linkable Ring Signature) (ASNL)

Niech stanowi zbioacuter kluczy j = 1hellip z jako sekretnym kluczem

Dla każdego j niech Irsquo = i + 1 mod 2 ustawić skalar losowy aj i obliczyć

Ustawić gdzie Hs to kryptograficzna funkcja haszująca zwracająca skalar po dokonaniu wyboru losowego obliczyć

Określić i obliczyć

Zwroacutecić dla wszystkich j i s =

502 Weryfikacja zagregowanego nielinkowalnego podpisu pierścieniowego Schnorra (ASNL)Zacznijmy od dla j = 1hellip n oraz s

Dla wszystkich j obliczyć oraz

Jeżeli to otrzymamy 0 dla ważnego podpisuW przeciwnym razie otrzymamy wartość zwrotną -1

Teoremat 51 Zagregowany nielinkowany podpis pierścieniowy Schnorra nie może być sfałszowany przy założeniu logarytmu dyskretnego

Dowoacuted Przedstawiam szkic dowodu w przypadku n = 2 Przypadek ogoacutelny ma zbliżony charakter Przypuśćmy że adwersarz A jest w stanie sfałszować podpis ASNL na

Przy pomijalnym prawdopodobieństwie znając najwyżej jedną z (przypuśćmy że bez straty ogoacutelnego charakteru założenia że A zna ) Dla każdego danego fałszu

rozwiązuję roacutewnanie logarytmu dyskretnego o niepomijalnym prawdopodobieństwie Po zastosowaniu algorytmu weryfikacji niech Zatem prawdziwe musi być roacutewnanie

Przypuśćmy że oraz a a b są znane A wtedy

ponieważ jest określone protokołem weryfikacji musi być zatem prawdą że A zna klucz

prywatny

=Jest to w sprzeczności z założeniem logarytmu dyskretnego dla danej grupy

51 Reprezentacja kwotKwoty w protokole Ring CT można przedstawiać w sposoacuteb zbliżony do tego ktoacutery przedstawiony został w [11] z drobną modyfikacją w celu dopasowania do systemu Monero Coiny CryptoNote organizują nominały coinoacutew w bazie indeksoacutew w taki sposoacuteb aby mogły być ułożone w porządku występowania jako dane wejściowe dla podpisoacutew pierścieniowych Ponieważ wszystkie wartości coinoacutew w CryptoNote są reprezentowane w postaci 64-bitowych niepodpisanych liczb całkowitych możemy wykorzystać range proof na przestrzeni całego rejestru w celu zakodowania kwoty wyjściowej przekazywanej odbiorcy Na szczęście to także umożliwia wzajemne miksowanie danych wyjściowych zatem wymagany jest tylko jeden indeks danych wyjściowych w porządku rejestracji Przedział weryfikacji (range proof) wynosi ok 5 kilobajtoacutew Podpisy pierścieniowe dla danych wejściowych stają się bardziej odporne na analizę ponieważ anonimowość jest bardzo rozszerzonaPodczas gdy obszary weryfikacji (range proofs) są duże wykorzystywanie układu haszującego ktoacutery dodaje przedrostek do transakcji (zaroacutewno indeksoacutew wejściowych jak i wyjściowych) i przechowuje szeroki zakres range proof wraz z podpisami umożliwia oddzielnie uzyskanie ogromnych oszczędności przestrzeni podczas synchronizacji (syncing) do punktu weryfikacji lub działanie jako węzeł SPV Podobnie do elementoacutew bocznych łańcucha (Sidechains Elements) [12] będziemy przechowywać H(H(prefiks)||H(podpisy)) w drzewie Merkla Następnie węzły syncing do zaufanego punktu weryfikacji muszą jedynie pobrać przedrostek i dodać wartość haszującą do podpisoacutew skutecznie redukując szerokość wiązki Ponieważ prefiks transakcji wykorzystuje wariant dla danych wyjściowych ktoacutere wymienia w swoich podpisach pierścieniowych oraz środkach zapisanych do jednego klucza publicznego stanowi on miniaturowe poroacutewnanie do danych podpisoacutew pierścieniowych w danych wyjściowych oraz range proofs

Następnie podpisy pierścieniowe mogą nawet być przycięte z bazy danych przez niektoacutere węzły w celu uzyskania dalszych zyskoacutew przestrzeni przechowując zastępczo jedynie względnie mały zbioacuter UTXO

511 Przekazywanie informacji o kwotach OdbiorcyObecnie mając dowolną kwotę wyjściową b = b020 + b121 + ∙∙∙ bn2n nadawca oblicza nową prywatnąpubliczną parę kluczy oraz związane wymieniane sekrety ECDH ss oraz udostępnia następujące informacje w swojej transakcji

gdzie ai to losowo wybrane liczby dla j = 0 hellipn Dane Klucz publiczny ECDH oraz a + ss mod l gdzie a = a0 + hellip + an

Następnie odbiorca Oblicza udostępniany sekret ss oraz oblicza a na podstawie a + ss mod l Oblicza C = sumCi oblicza C ndash aG = bH oraz oblicza b poroacutewnując uzyskane wartości do

wszystkich bH w danym przedziale [0 2n] (W praktyce będzie to szybkie 500 kilobajtowe wyszukanie w n = 12 podobnie jak w poprzednim rozdziale Gdyby jednak wartość 232 została wybrana jako goacuterna wartość graniczna podobnie jak w [11] wyszukiwanie stałoby się dużym obliczeniowo wysiłkiem)

6 WnioskiProtokoacuteł pierścieniowych transakcji poufnych (Ring Confidential Transactions) to bardzo silnie zdecentralizowana kryptowaluta (tzn nie ma w niej żadnej uprzywilejowanej strony) ktoacutera posiada proste do udowodnienia wartości szacunkowe zabezpieczeń dotyczące ukrywania kwot transferoacutew ich źroacutedeł oraz odbiorcoacutew Dodatkowo generowanie coinoacutew w oparciu o protokoacuteł Ring Confidential Transactions nie wymaga obecności czynnika zaufanego i proces jego weryfikacji jest całkowicie bezpiecznyTych pięć czynnikoacutew jest niezbędnych w przypadku kryptowalut zbliżonych do środkoacutew gotoacutewkowych takich jak MoneroBibliografia1 Masayuki Abe Miyako Ohkubo and Koutarou Suzuki 1-out-of-n signatures from a variety of keys Advances in CryptologyAsiacrypt 2002 pages 415ndash432 20022 Adam Back Bitcoins with homomorphic value (validatable but encrypted)httpsbitcointalkorgindexphptopic=3057910 2013 [Online accessed 1-May-2015]3 Adam Back Podpis pierścieniowy efficiency httpsbitcointalkorgindexphptopic=972541msg10619684msg10619684 2015 [Online accessed 1-May-2015]4 Eli Ben Sasson Alessandro Chiesa Christina Garman Matthew Green Ian Miers Eran Tromer and Madars Virza Zerocash Decentralized anonymous payments from bitcoin In Security and Privacy (SP) 2014 IEEE Symposium on pages 459ndash474 IEEE 20145 Evan Duffield and Kyle Hagan Darkcoin Peertopeer cryptocurrency with anonymous blockchain transactions and an improved proofofwork system 20146 Eiichiro Fujisaki and Koutarou Suzuki Traceable podpis pierścieniowy In Public Key CryptographyndashPKC 2007 pages 181ndash200 Springer 20077 Javier Herranz Aggregate signatures httpwwwiiiacsices~jherranzpapersNijmegen_seminar_aggregatepdf oct 20058 Joseph K Liu Victor K Wei and Duncan S Wong Linkable spontaneous anonymous group signature for ad hoc groups In Information Security and Privacy pages 325ndash335 Springer 20049 Adam Mackenzie Surae Noether and Monero Core Team Improving obfuscation in the cryptonote protocol httpslabgetmoneroorgpubsMRL-0004pdf January 201510 Greg Maxwell Coinjoin Bitcoin privacy for the real world august 2013 Bitcoin Forum httpsbitcointalkorgindexphptopic=2792490 2013 [Online accessed 1-July-2015]11 Greg Maxwell Confidential Transactions httpspeoplexiphorg~gregconfidential_valuestxt 2015 [Online accessed 1-June-2015]12 Greg Maxwell Elements project httpsgithubcomShenNoetherMiniNero 201513 Satoshi Nakamoto Bitcoin A peer-to-peer electronic cash system Consulted 1(2012)28 200814 Shen Noether Mininero httpsgithubcomShenNoetherMiniNero 201515 Ronald L Rivest Adi Shamir and Yael Tauman How to leak a secret In Advances in CryptologyASIACRYPT 2001 pages 552ndash565 Springer 200116 Nicolas van Saberhagen Cryptonote v 2 0 HYPERLINK https cryptonote org whitepaper pdf 2013

Załącznik A Załącznik Security ProofsA1 Brak możliwości sfałszowania MLSAG

Obliczenia przebiegają analogicznie do [8 Teoremat 1] Niech H1 oraz H2 będą losowo wybranymi oracle a SO stanowią podpisy oracle zwracające ważne podpisy MLSAG Załoacuteżmy że istnieje probabilistyczny wielomianowy adwersarz czasowy (PPT) A ktoacutery posiada zdolność sfałszowania MLSAG z listy wektoroacutew kluczy L przy prawdopodobieństwie ktoacuterego nie można pominąć

Gdzie Q1 stanowi wielomianowy parametr bezpieczeństwa k oraz gdzie (m σ) nie stanowi jednego z podpisoacutew zwracanych przez SO Załoacuteżmy że A nie wysyła więcej niż qH + nqS

(gdzie n oznacza liczbę kluczy w L) zapytań dotyczących podpisoacutew oracle H1H2 oraz SO odpowiednio Podpisy oracle H1 oraz H2 uważa się za niezależne i losowe oraz spoacutejne z danymi zapytaniami powtarzającymi się Podpis oracle SO może składać zapytanie H1 oraz H2 Mając wartość A wykaże że istnieje możliwość utworzenia adwersarza M w PPT ktoacutery będzie wykorzystywać A w celu znalezienia logarytmu dyskretnego jednego z kluczy w L

Jeżeli L stanowi zbioacuter kluczy wektoroacutew z ktoacuterych każdy będzie mieć wielkość r (tzn z kluczami publicznymi y1 hellip yr ) to wygenerowany fałszywy podpis

Wygenerowany przez A musi spełniać warunek

Gdzie i są obliczone w ramach mod n oraz są zdefiniowane zgodnie z Rozdziałem 22 Nowy adwersarz M może wykorzystać A w celu sfałszowania podpisoacutew wielomianową liczbę razy i zapisze każdy skrypt Turinga T niezależnie czy sfałszowanie było skuteczne czy nie

Lemma A1 [8 Lemma 1] Niech M wywołuje A w celu uzyskania transkrypcji T Jeżeli T jest skuteczne to M powraca do T do nagłoacutewka H i następnie re-symuluje A w celu uzyskania transkrypcji Trsquo Jeżeli Pr (T okaże się skuteczne) = ϵ to Pr (Trsquo jest skuteczne) = ϵ

Dowoacuted wynika wprost z przywołanego teorematu

Teoremat A2 Prawdopodobieństwo że adwersarz A sfałszuje podpis MLSAG można pominąć przy założeniu logarytmu dyskretnego

Dowoacuted Do przeprowadzenia dowodu będę stosować notację przedstawioną powyżej Podobnie jak w przypadku [8 teoremat 1] ponieważ prawdopodobieństwo odgadnięcia danych wyjściowych z losowego oracle jest znikome w związku z tym dla każdego skutecznego oszustwa A wprowadza transkrypcję uzupełniającą T a zatem mamy mT zapytań w przypadku zapytań do H1 odpowiadających liczbie n zapytań wykorzystywanych w celu weryfikacji podpisu W związku z tym niech Xi1 hellip Xim oznacza zapytania wykorzystywane w procesie weryfikacji fałszu ith oraz niech π oznacza indeks odpowiadający ostatniemu zapytaniu weryfikacyjnego dla danego oszustwa

(Intuicyjnie π odpowiada temu co może stanowić indeks sekretny fałszywego podpisu ponieważ odpowiada on ostatniemu wezwaniu ostatniemu wywołaniu losowego oracle dla danego odpisu)Proacuteba sfałszowania σ podjęta przez A stanowi fałsz (l π) jeżeli i1 = l oraz π jest zgodne z powyższym (zatem fałsz odpowiada zapytaniom l do l + π) Z założenia istnieje para (l π) taka że prawdopodobieństwo związanej transkrypcji T daje skutecznie wygenerowany fałszywy klucz ϵlπ (T) spełnia warunek

1

Teraz przeglądając T do wartości przed zapytaniem l-tym a następnie podejmując proacutebę sfałszowania za pomocą tego samego zbioru kluczy (oraz dopuszczając aby H1 obliczyło nowe rzuty monetami dla wszystkich kolejnych zapytań) z Lemmy A1 wynika że prawdopodobieństwo że Trsquo jest także skuteczne spełnia warunki

_Dlatego prawdopodobieństwo że zaroacutewno T jak i Trsquo odpowiadają weryfikacjom fałszywym σ i σ1 nie może zostać pominięte

Ponieważ nowe rzuty monetami zostały obliczone na podstawie danych wyjściowych losowych oracle H1 oznacza to że przy dużym prawdopodobieństwie istnieje wartość j taka

że oraz W związku z tym możemy rozwiązać klucz prywatny z indeksem π

ktoacutery jest sprzeczny z założeniami logarytmu dyskretnego

A2 Linkowalność MLSAG Teoremat A3 Linkowalność obrazu klucza (Key-Image Linkability) Prawdopodobieństwo że adwersarz a w PPT może utworzyć dwa podpisy weryfikujące (niepołączone w danym

ustawieniu σ σrsquo podpisane w odniesieniu do wektoroacutew kluczy oraz odpowiednio w taki

sposoacuteb że będzie istnieć klucz publiczny i w obu oraz może być pominięte

Dowoacuted Przypuśćmy że w przeciwieństwie do tego co zostało wcześniej powiedziane A utworzył dwa podpisy weryfikujące σ oraz σrsquo o oba są podpisami w odniesieniu do kluczowych wektoroacutew

oraz odpowiednio w taki sposoacuteb że istnieje klucz publiczny y zaroacutewno w jak i

Niech y występuje jako element j należący do a jrsquo jako element należący do rsquo Z teorematu A2 wynika z dużym prawdopodobieństwem że istnieją indeksy π oraz πrsquo dla kluczy publicznych σ oraz σrsquo odpowiednio takie że

oraz

z

oraz

Jeżeli uznamy że x oznacza klucz prywatny y y = xG to po rozwiązaniu powyższego dla Ij

oraz Ij0rsquo mamy następujące roacutewnania oraz podobnie Ijrsquo = xH (y) Tym samym dwa podpisy obejmują Ij = Ijrsquo i w związku z tym ponieważ zduplikowane obrazy kluczy są odrzucone jeden z nich nie może być wykorzystany do weryfikacji

A3 Anonimowość MLSAG W celu udowodnienia anonimowości powyższego protokołu w losowym modelu oracle przyjmijmy że H1 H2 to losowe oracle modelujące dyskretne funkcje haszujące Niech A to adwersarz anonimowości Buduję adwersarza M względem założenia problemu decyzyjnego Diffie Helmana (DDH) zgodnie z poniższym Założenie DDH stwierdza że mając daną krotność (G aG bG ϒG) prawdopodobieństwo ustalenia czy G = abG jest znikome

Teoremat A4 Protokoacuteł pierścieniowy CT jest dwuznaczny w odniesieniu do sygnatariusza przy założeniu problemu decyzyjnego Diffie-HelmanaDowoacuted (zbliżony do dowodu [8 Teoremat 2]) Załoacuteżmy że problem decyzyjny Diffie-Helmana jest trudny w cyklicznej grupie generowanej przez G i załoacuteżmy że istnieje adwersarz A w czasie PPT względem dwuznaczności sygnatariusza Tym samym mając listę L n wektoroacutew

kluczy publicznych o długości m oraz zbioacuter prywatnych kluczy t ważny podpis σ na L podpisany przez użytkownika w odniesieniu do wektora klucza y taki że

odpowiedni wektor klucza prywatnego wynosi spełnia to A może zdeterminować π z prawdopodobieństwem

Dla wybranych wielomianoacutew Q(k) Buduję adwersarza PPT M ktoacutery wykorzystuje krotność danych wejściowych (G aG bG ciG) gdzie I ϵ 0 1 jest losowo wybrany (a nie znany M a priori) c1 = ab oraz c0 jest losowym skalarem a dane wyjściowe i mają prawdopodobieństwo

Dla niektoacuterych wielomianoacutew Q2 (k)Należy rozważyć algorytm SIMNIZKP (zbliżony to tego ktoacutery został zdefiniowany w [6]) ktoacutery jako skalary wejściowe wykorzystuje wektor x klucza prywatnego zbioacuter wektoroacutew kluczy

publicznych indeks π oraz wiadomość m i ktoacutery działa w sposoacuteb następujący1 Wygenerować skalary losowe s1 hellip sm oraz skalar losowy cπ lt- H2 Dla j indeksującego określić

A dla pozostałych j

3 Obliczyć losowe dane wyjściowe na podstawie losowego oracle

4 Dla każdego i roboczego mod m obliczyć

Należy podkreślić że w ostatnim punkcie kiedy i = π - 1 to ci+1 jest już określone w celu utrzymania spoacutejności z losowymi danymi wyjściowymi oracleNależy podkreślić że niezależnie od tego czy jest rzeczywistym kluczem prywatnym odpowiadającym ze względu na to że spoacutejność jest zachowywana przez losowe wartości oracle w kolejnych wezwaniach powyższy podpis jest weryfikowany Jeżeli x jest rzeczywiście wektorem klucza prywatnego y to nie ma roacuteżnicy pomiędzy SIMNIZKP oraz rzeczywistym podpisemNa koniec mając krotność (G aG bG ciG) gdzie a b są losowo wybrany skalarami a c1 = ab c0 elementem losowym i ϵ 0 1 M zachodzi w poniższych krokach i pozwala rozwiązać problem decyzyjny Diffie Helmana za pomocą niepomijalnego prawdopodobieństwa M wychwytuje losowe ϒ lt-H z losowej wartości oracle oraz pobiera parę wektoroacutew klucza prywatnego publicznego (x y) a następnie oblicza s jako a = s + ϒx Teraz M wykonuje

SIMNIZKP za pomocą dowolnie wybranych wektoroacutew kluczy w taki sposoacuteb że w danej wiadomości m oraz Jeżeli prawdziwe jest że i = 1 to c = ab oraz logGaG = logbGcG = a

z uwagi na to że zakłada się iż A jest w stanie znaleźć π z prawdopodobieństwem ktoacuterego nie można pominąć to istnieje niepomijalne prawdopodobieństwo frac12 że A zwroacuteci 1 (i wtedy M zwroacuteci 1) Jeżeli i = 0 to A zwraca 1 wyłącznie z prawdopodobieństwem frac12 a zatem dla niektoacuterych niepomijanych prawdopodobieństw powyżej 1`2 M zwraca tę samą wartość co A i tym samym rozwiązuje problem decyzyjny Diffie-Helmana dla losowo wybranych skalaroacutew bez pomijalnego prawdopodobieństwa powyżej 12 co stanowi sprzeczność

Załącznik B Kod demo Ring CT W repozytorium w [14] zbudowałem prostą demonstrację protokołu poufnych transakcji pierścieniowych (Ring Confidential Transactions) wykorzystujących podpisy MLSAG w części 2 oraz podpisy ASNL w części 5

H_ct = RingCTgetHForCT()print(H H_ct)sr Pr = PaperWalletskpkGen() receivers private publicse pe ss = ecdhecdhgen(Pr) compute shared secret ssdigits = 14 in practice it will be 14print(inputs)Cia L1a s2a sa ska = RingCTgenRangeProof(10000 digits)print(outputs)Cib L1b s2b sb skb = RingCTgenRangeProof(7000 digits)Cic L1c s2c sc skc = RingCTgenRangeProof(3000 digits)print(verifying range proofs of outputs)RingCTverRangeProof(Cib L1b s2b sb)RingCTverRangeProof(Cic L1c s2c sc)x P1 = PaperWalletskpkGen()P2 = PaperWalletpkGen()C2 = PaperWalletpkGen()some random commitment grabbed from the blockchainind = 0Ca = RingCTsumCi(Cia)Cb = RingCTsumCi(Cib)Cc = RingCTsumCi(Cic)sk = [x MiniNerosc_sub_keys(ska MiniNerosc_add_keys(skb skc))]

pk = [[P1 P2] [MiniNerosubKeys(Ca MiniNeroaddKeys(Cb Cc)) MiniNerosubKeys(C2 MiniNeroaddKeys(Cb Cc)) ] ]II cc ssVal = MLSAGMLSAG_Sign(pk sk ind)print(Sig verified MLSAGMLSAG_Ver(pk II cc ssVal) )print(Finding received amount corresponding to Cib)RingCTComputeReceivedAmount(pe sr MiniNeroaddScalars(ss skb) Cib)print(Finding received amount corresponding to Cic)RingCTComputeReceivedAmount(pe sr MiniNeroaddScalars(ss skc) Cic)

Przykład transakcji z danymi wejściowymi 10 000 oraz wyjściowymi 3 000 i 7 000(rsquoHrsquo rsquo61fe7f0f5a607a33427d01dd1fded5ffa03fae2e9df9ebccf2e0a2f5bd77a204rsquo)inputs(rsquob b in binaryrsquo 10000 [0 0 0 0 1 0 0 0 1 1 1 0 0 1])Generating Aggregate Schnorr Non-linkable Podpis pierścieniowy outputs(rsquob b in binaryrsquo 7000 [0 0 0 1 1 0 1 0 1 1 0 1 1 0])Generating Aggregate Schnorr Non-linkable Podpis pierścieniowy (rsquob b in binaryrsquo 3000 [0 0 0 1 1 1 0 1 1 1 0 1 0 0])Generating Aggregate Schnorr Non-linkable Podpis pierścieniowy verifying range proofs of outputsVerifying Aggregate Schnorr Non-linkable Podpis pierścieniowy VerifiedVerifying Aggregate Schnorr Non-linkable Podpis pierścieniowy Verified(rsquoGenerating MLSAG sig of dimensions rsquo 2 rsquox rsquo 2)(rsquoverifying MLSAG sig of dimensions rsquo 2 rsquox rsquo 2)(rsquocrsquo[rsquo80a3cfd06dd2862307cd75c2a1566f20cd743dbb0b9feb22d79dcbecb9023f42rsquorsquoa9b7342ba7bf2f102505ca19dab734fde638916c0a29f5b30e49833ab51393earsquorsquo80a3cfd06dd2862307cd75c2a1566f20cd743dbb0b9feb22d79dcbecb9023f42rsquo])(rsquosig verifiesrsquo True)(rsquoSig verifiedrsquo True)Finding received amount corresponding to Cib(rsquoreceived rsquo 7000c Monero Research Lab Page 20 of 20rsquoa488ec68732fb551841c2c6dcc7ffac895d98ec7e9378275ed20ea12805fc18ersquo)Finding received amount corresponding to Cic(rsquoreceived rsquo3000rsquo1b46626858e130a0f3884c74c9fdeabc4d812c519103ea16a35a3f82a3d0ed6drsquo)

mniejszy niż można by tego oczekiwać Analiza wyżej opisanych słabych punktoacutew przedstawiona jest w [9]

12 Pierścień CT dla MoneroOczywistym sposobem negowania słabych stron protokołu CryptNote zgodnie z opisem w poprzedzającym ustępie może być zaimplementowanie ukrytych kwot dla dowolnej transakcji W niniejszym dokumencie przedstawiam zmiany wprowadzone do protokołu Monero kryptowaluty opartej na algorytmie proof-of-work stanowiącej rozszerzenie pierwotnego protokołu CryptoNote ktoacutera umożliwia ukrycie (zamaskowanie) kwot przekazywanych w ramach danej transakcji Modyfikacja ta zasadza się na Transakcjach Poufnych [11] ktoacutere są wykorzystywane w łańcuchu bocznym elementoacutew bitcoina z tą roacuteżnicą że umożliwia ona ich wykorzystanie w ramach podpisoacutew pierścieniowych Dlatego też modyfikacja ta otrzymuje oczywistą nazwę Pierścieniowe Transakcje Poufne dla systemu [waluty] MoneroAby zachować właściwość uniemożliwiającą dwukrotne wydatkowanie coinoacutew przedstawiam opis pewnego uogoacutelnienia LSAG w [8] ndash podpis typu Multilayered Linkable Spontaneous Anonymous Group Signature (MLSAG) ktoacutery umożliwia kombinację Transakcji Poufnych opatrzonych podpisami pierścieniowymi w taki sposoacuteb że wykorzystywanie mnogich danych wejściowych i wyjściowych będzie możliwe z zachowaniem anonimowości przy jednoczesnym uniemożliwieniu podwoacutejnego wydatkowania Autor podkreśla że zasadniczo podobny protokoacuteł został zaproponowany przez Connora Frenkenechta około miesiąc po ukazaniu się drugiej wersji oryginału niniejszego dokumentu

13 Silnie zdecentralizowane systemy płatności anonimowych [Strongly Decentralized Anonymous Payment Schemes]Protokoacuteł pierścieniowy CT [Ring CT] umożliwia tworzenie ukrytych kwot źroacutedeł oraz adresatoacutew transakcji i jest nieco zbliżony do systemu Zerocash [4] Jedna z potencjalnych roacuteżnic polega na wykorzystaniu proof of work w celu generowania coinoacutew za pomocą protokołu Ring CT w odroacuteżnieniu od ZeroCash gdzie jak się wydaje wszystkie coiny muszą być wstępnie wygenerowane przez zaufaną grupęNależy podkreślić że jedną z największych innowacji w systemie Bitcoin [13] był zdecentralizowany model dystrybucji umożliwiający dowolnej zainteresowanej osobie udostępnienie swoich mocy obliczeniowych do pracy i uczestnictwo w procesie generowania waluty Niektoacutere korzyści wynikające z tego typu algorytmu proof-of-work obejmują niezaufane motywacje do zabezpieczania sieci oraz jeszcze silniejszej decentralizacji (na przykład do ochrony przed atakami typu poison-pill ndash trujące pigułki)Jedną z oczywistych końcowych korzyści generowania coinoacutew w oparciu o algorytm proof-of-work jest to że pozwala on na uodpornienie Ring CT na działania podejmowanego przez silnego aktora ktoacutery potrafi znaleźć sposoacuteb na znalezienie wszystkich fragmenty klucza głoacutewnego wykorzystywanego do generowania coinoacutew Ponieważ mamy do czynienia z oczywistym poważnym bodźcem (jakim jest zdolność do generowania darmowych środkoacutew finansowych [1]) do pozyskiwania wszelkich fragmentoacutew procesu generacji zaufanego klucza kwestia ta jest dość istotna

14 PodziękowaniaChciałbym podziękować zespołowi Monero za udzieloną pomoc rozmowy dotyczące procesu opracowywania niniejszej publikacji oraz całej społeczności portali Monero oraz Bitcoin za wsparcie i udział w dyskusji Jeżeli chodzi o ujawnianie (poufność) autor otrzymał kilka donacji o łącznej wartości od 2 do 3 bitcoinoacutew ze strony społeczności Monero na dowoacuted ich wdzięczności i w uznaniu wkładu w niniejszą pracę badawczą

2 Podpisy typu Multilayered Linkable Spontaneous Anonymous Group Signatures

Niniejszy rozdział zawiera definicję podpisoacutew typu Multilayered Linkable Spontaneous Anonymous Group (MLSAG) wykorzystywanych przez protokoacuteł Ring CT Należy podkreślić że definiuję je jako podpis ogoacutelny a niekoniecznie jako przykład wykorzystania w Pierścieniowych Transakcjach Poufnych MLSAG jest zasadniczo zbliżony do LSAG-oacutew opisanych w [8] ale zamiast składać podpis na zbiorze n kluczy MLSAG sam w sobie stanowi podpis pierścieniowy na zbiorze wektoroacutew n kluczy

Definicja 21 Wektor kluczy jest po prostu zbiorem kluczy publicznych odpowiadających kluczom prywatnym

[1] Poprzednio autor założył że mogłoby to roacutewnież umożliwić ujawnienie (odsłonięcie) transakcji ale najnowsza publikacją dotycząca ZeroCash wyraźnie stwierdza że to niemożliwe

21 Podpisy LWW a podpisy FS Podpisy pierścieniowe wykorzystywane w Monero oraz oryginalny protokoacuteł CryptoNote są pochodnymi podpisoacutew pierścieniowych możliwych do wyśledzenia z [6] Podpisy pierścieniowe w ramach CryptoNote [16] zawierają ldquoobraz kluczardquo co oznacza że podpisujący może podpisać jeden pierścień w blockchainie używając danego klucza publicznego oraz pary kluczy prywatnych albo ich transakcja zostanie oznaczona jako nieważna W związku z tym wykorzystywane są klucze jednorazowe w protokole CryptoNote ktoacutere następnie podnoszą poziom anonimowościW [3] Adam Back podkreśla że podpisy w ramach Linkable Spontaneous Anonymous Group (LSAG) w [8] mogą być modyfikowane w taki sposoacuteb aby utworzyć bardziej wydajny linkowany podpis pierścieniowy dający ten sam efekt jaki uzyskuje się w przypadku podpisu pierścieniowego z [6] Modyfikacja ta pozwala obniżyć koszty przechowywania w blockchainie zasadniczo o połowęNa początek przytoczę ndash niemal dosłownie ndash modyfikacje opisane w [3]Keygen [Generowanie klucza] Znajdź pewną liczbę kluczy publicznych Pi i = 0 1 hellip n oraz sekretny indeks j spełniający warunek xG = Pj gdzie G stanowi punkt bazowy ed25519 a x to klucz wydatkowany sygnatariuszy Niech I = xHp (Pj) gdzie Hp jest funkcją haszującą zwracającą punkt [2] Niech m stanowi daną wiadomośćPODPIS Niech α si i ne j i ϵ 1 hellip n będą wartościami losowymi w Zq (pole bazowe ed25519)ObliczLj = αGRj = αHp (Pj)cj+1 = h (m Lj Rj)gdzie h jest funkcją haszującą zwracającą wartość w Zq Teraz dokonując kolejnych obliczeń j modulo n należy zdefiniowaćLj+1 = sj+1G + cj+1Pj+1Rj+1 = sj+1Hp (Pj+1) + cj+1 _ Icj+2 = h (m Lj+1 Rj+1)hellip

Lj-1 = sj-1G + cj-1Pj-1Rj-1 = sj-1Hp (Pj-1) + cj-1∙ Icj = h (mLj-1 Rj-1)

[2] W praktyce Hp(P) = Keccak(P) ∙ G gdzie G jest punktem bazowym ed25519 chociaż należy zauważyć że w odniesieniu do układu zobowiązań będę wykorzystywać toPoint(Keccak(P)) haszujący kolejno aż do zwrotu wielokrotności punktu bazowego przez Keccak(P)

po to aby umożliwić definicję c1 hellip cnNiech sj = α - cj ∙ xj mod l (l stanowi porządek krzywej ed25519) stąd α = sj + cjxj mod l w taki sposoacuteb że Lj = _G = sjG + cjxjG = sjG + cjPjRj = _Hp (Pj) = sjHp (Pj) + cjIorazcj+1 = h (m Lj Rj)stąd mając jednostkową wartość ci wartości Pj obraz klucza I oraz wszystkie wartości sj pozostałe ck k 6= i mogą być odkryte przez obserwatora Podpis w związku ma postaćα = (I c1 s1 hellip sn)reprezentując oszczędności w zakresie zajmowanego miejsca w stosunku do [16 44] gdzie podpis pierścieniowy moacutegłby zamiennie wyglądać w następujący sposoacutebα = (I c1 hellip cn s1 hellip sn)Weryfikacja przebiega w następujący sposoacuteb Obserwator oblicza wartości Li Ri oraz ci dla wszystkich i oraz weryfikuje czy cn+1 = c1 Następnie weryfikator sprawdza czy

ci+1 = h (m Li Ri)dla wszystkich i mod nLINK Podpisy z duplikatami obrazoacutew kluczy I są odrzucaneNależy podkreślić że protokoły proofs of unforgeability anonimowości oraz łączenia obowiązują i stanowią jedynie nieznaczne modyfikacje protokołoacutew proof o ktoacuterych mowa w [8] Przedstawię nieco bardziej uogoacutelnioną wersję tych protokołoacutew dla MLSAG

22 Opis MLSAG W odniesieniu do protokołu Ring CT ktoacuterego opis znajduje się w części 4 wymagam uogoacutelnienia podpisoacutew Back LSAG opisanych w poprzednim rozdziale co umożliwia stosowanie wektoroacutew kluczy (Definicja 21) zamiast po prostu kluczyPrzypuśćmy że każda osoba składająca podpis pod (uogoacutelnionym) pierścieniem

zawierającym n członkoacutew (uczestnikoacutew) ma dokładnie m kluczy Celem podpisu pierścieniowego MLSAG jest realizacja następujących celoacutew

udowodnienie że jeden z podpisujących n zna sekretny klucz właściwy dla całego wektora klucza

Zapewnienie że jeżeli podpisujący wykorzystuje jeden z kluczy podpisoacutew m w innym podpisie MLSAG to dwa pierścienie są połączone a drugi taki podpis MLSAG (zlecony przez blockchain Monero) zostanie odrzucony

Algorytm działa w sposoacuteb następujący niech m stanowi wiadomość Niech π jest sekretnym indeksem odpowiadającym sygnatariuszowi uogoacutelnionego pierścienia Dla j = 1 hellip m niech

oraz dla j = 1 hellip m i = 1 hellip π hellipn (gdzie π oznacza ominięcie indeksu π) niech stanowi jeden z losowych skalaroacutew (elementoacutew Zq) Teraz w sposoacuteb analogiczny do części 21 należy zdefiniować

dla skalaroacutew losowych αj oraz j = 1 hellip m A teraz ponownie analogicznie do części 21 należy określić

i powtoacuterzyć czynność zwiększając przyrostowo i modulo n aż do momentu uzyskania następującej postaci

Na koniec dla każdego rozwiązać mod l Podpis jest następnie przekazywany jako zatem kompleksowość wynosi O (m(n + 1)) Proces weryfikacji przebiega poprzez regenerację wszystkich zaczynając od i = 1 podobnie jak to miało miejsce w części 21 (ktoacutera

stanowi przypadek szczegoacutelny w ktoacuterym m = 1) i przeprowadzając sprawdzenie funkcji haszującej cn+1 = c1 Jeżeli wartości te są wykorzystywane w ustawieniu blockchainowym takim jak Monero podpisy składane za pomocą obrazoacutew kluczy Ij ktoacutere już się pojawiły są następnie odrzucane Można to w bardzo łatwy sposoacuteb wykazać stosując metodę zbliżoną do [8] że

Prawdopodobieństwo że sygnatariusz generujący ważny podpis bez znajomości wszystkich prywatnych kluczy ldquomrdquo należących do ich wektora kluczy dla indeksu π może być pominięty

Prawdopodobieństwo że sygnatariusz nie podpisze żadnego klucza z indeksu π może zostać pominięte (Innymi słowy wszystkie obrazy kluczy stanowiące część podpisu muszą pochodzić z indeksu π)

Jeżeli sygnatariusz podpisuje dwa pierścienie wykorzystując co najmniej jeden z tożsamych kluczy publicznych to następuje skojarzenie (połączenie) dwoacutech pierścieni

Szersze omoacutewienie tych elementoacutew znajduje się w dalszej części materiału dotyczącej zabezpieczeń (security proofs)

23 Model zabezpieczeń MLSAGMLSAG spełnia trzy niżej wymienione właściwości niefałszowalność (Unforgeability) linkowalność (Linkability) oraz Dwuznaczność Sygnatariusza (Signer Ambiguity) ktoacutere są bardzo zbliżone do definicji podanej w [8]

Definicja 22 Niefałszowalność (Unforgeability) System podpisoacutew MLSAG jest niemożliwy do sfałszowania jeżeli dla danego algorytmu A wielomianowego czasu probabilistycznego (PPT) z podpisem oracle SO generującego ważne podpisy oraz dla danej listy wektoroacutew kluczy publicznych n wybranej przez A A może generować przy pomijalnym prawdopodobieństwie ważny podpis w sytuacji gdy A nie zna jednego z odpowiednich wektoroacutew kluczy prywatnych

Uwaga 23 W poniższej definicji należy zauważyć że umieściłem funkcję odrzucania duplikujących się obrazoacutew kluczy jako części kryterioacutew weryfikacji dla MLSAG co przyczynia się do zbudowania nieco zmodyfikowanej definicji linkowalności (Linkability) w stosunku do tej ktoacutera została podana w [8]

Definicja 24 Linkowalność (Linkability) Niech L stanowi zbioacuter wszystkich kluczy publicznych w danym ustawieniu (np w danym łańcuchu blokowym - blockchainie) System składania podpisoacutew MLSAG w L jest połączony z obrazami kluczy jeżeli prawdopodobieństwo że

adwersarz A utworzy w PPT dwa podpisy σ σ1 podpisane w odniesieniu do wektoroacutew kluczy

oraz 1 z ktoacuterych każdy będzie zawierać ten sam klucz publiczny yi = yirsquo W L oraz każdy będzie weryfikowany bez oznaczenia jako duplikat jest pomijalne

Definicja 25 Dwuznaczność sygnatariusza (Signer Ambiguity) System składania podpisoacutew MLSAG uważa się za niejednoznacznie identyfikujący sygnatariusza jeżeli mamy dany podpis weryfikujący σ na wektorach kluczy oraz dowolny zbioacuter kluczy prywatnych t z ktoacuterych każdy będzie mieć oddzielny indeks oraz sekretny indeks w takiej sytuacji prawdopodobieństwo odgadnięcia klucza sekretnego wynosi mniej niż

Dowody potwierdzające powyższe definicje przedstawiono w Załączniku

3 Zarys historyczny transakcji poufnych31 Transakcje poufne w ramach system Bitcoin

W [11] Greg Maxwell opisuje transakcje poufne ktoacutere są pewną metodą przekazywania transakcji w systemie Bitcoin przy jednoczesnym maskowaniu kwot Podstawową kwestią jest stosowanie schematu zobowiązań Pedersena metoda ta jest doskonale opisana w cytowanym materiale źroacutedłowym W niniejszym opracowaniu wprowadzam drobną modyfikację do mechaniki Transakcji Poufnych polegającą na wybieraniu zamiast zobowiązań ktoacuterych suma wynosi zero opcji złożenia podpisu pod zobowiązaniem w celu wykazania że klucz prywatny jest mi znany Schemat ten jest opisany szczegoacutełowo w kolejnym rozdziale

32 Modyfikacja pod kątem podpisoacutew pierścieniowych Niech G stanowi punkt bazowy ed25519 Niech [3]

H = toPoint (cn_fast_hasz (G))

Należy podkreślić że nie każda wartość haszująca pozwala obliczyć punkt w ramach grupy punktu bazowego (tzn dla pewnej niewiadomej) (co jest sprzeczne z tym co dzieje się w secp256k1 krzywej wykorzystywanej w systemie Bitcoin) Nie mniej jednak wydaje się że wyboacuter punktu bazowego jako takiego (wcześniej wykorzystywałem H(123456G) sprawdza się co z resztą wydawało mi się bardziej bezpieczne przy czym punkt bazowy jest z pewnością bardziej naturalnym wyborem) Wyboacuter H = ϒG dla pewnej niewiadomej jest konieczny po to aby pełna matematyka zwykłych krzywych eliptycznych zachowała swoją ważność

[3] H = MiniNerogetHForCT() w kontekście kodu w [14]

Przy założeniu logarytmoacutew dyskretnych w ed25519 prawdopodobieństwo że adwersarz odkryje ϒ jest pomijalne Należy zdefiniować C (a x) = xG+aH zobowiązanie wartości a z maską x Należy podkreślić że tak długo jak wartość logGH nie jest znana oraz jeżeli σ ne 0 to logGC (a x) pozostaje wartością nieznaną Z drugiej strony jeżeli a = 0 to logGC (a x) = x a zatem istnieje możliwość złożenia podpisu za pomocą pary kluczy sk-pk (xC (0 x)) W [11] istnieją dane wejściowe I wyjściowe zobowiązań a sieć sprawdza czy

sumdane wejściowe = sumdane wyjściowe

Nie mniej jednak nie jest to wystarczające w przypadku systemu Monero ponieważ dana transakcja zawiera roacuteżne możliwe do realizacji dane wejściowe Pi i = 1 hellip n z ktoacuterych tylko jedna należa do nadawcy (patrz [16 44]) to jeżeli będziemy w stanie sprawdzić powyższe roacutewnanie to musi być możliwe aby sieć widziała ktoacutere Pi należy do nadawcy transakcji Nie jest to zjawisko pożądane ponieważ eliminuje anonimowość zbudowaną dzięki podpisowi pierścieniowemu W związku z tym zastępczo tworzy się zobowiązania dla danych wejściowych oraz wyjściowych zgodnie z poniższym (załoacuteżmy najpierw że istnieje tylko jeden zestaw danych wejściowych)

Cin = xcG + aHCout10485761 = y1G + b1HCout10485762 = y2G + b2H

W taki sposoacuteb że xc = y1+y2+z xc - y1 - y2 = z yi są wartościami maskującymi z gt 0 oraz a = b1+b2W tym przypadku xc stanowi szczegoacutelny prywatny klucz a ldquokwota kluczardquo znana jest tylko nadawcy oraz osobie do ktoacuterej coiny są wysyłane zatem musi być odmienna od normalnego klucza prywatnego W takim przypadku

= xcG + aH - y1G - b1H - y2G - b2H= zG

A zatem powyższe roacutewnanie staje się zobowiązaniem do 0 przy sk = z oraz pk = zG a nie rzeczywistym roacutewnaniem o sumie zerowej Należy podkreślić że z nie jest wyliczalne dla coinoacutew źroacutedłowych xc chyba że znana jest zaroacutewno wartość y1 jak i y2 nie mniej jednak nawet to można w prosty sposoacuteb złagodzić poprzez uwzględnienie dodatkowych adresoacutew zmiany (zwykły przypadek zakłada że drugie zobowiązanie z wartością y2 jako maską są wysyłane jako zmiana)Ponieważ podawanie informacji ktoacutere dane wejściowe należą do nadawcy nie jest pożądane podpis pierścieniowy zawierający wszystkie zobowiązania wejściowe Ci i = 1 hellip s hellip n (gdzie s stanowi sekretny indeks zobowiązania nadawcy) dodaje się odpowiedni klucz publiczny (dzięki czemu zobowiązania oraz klucze publiczne są parowane (Ci Pi) ale tylko takie ktoacutere mogą być wspoacutelnie wydatkowane) oraz odejmuje sumCout

Jest to podpis pierścieniowy ktoacutery może być złożony ponieważ znamy jeden z prywatnych kluczy (a mianowicie z + xrsquo zawierający z jak wyżej oraz xrsquoG = Ps) Tak naprawdę ponieważ wiemy że dla każdego i zaroacutewno klucze prywatne dla Pi jak i klucze prywatne dla Pi + Ciin - sumjCjout możemy złożyć podpis zgodnie z treścią rozdziału 22 Szczegoacuteły tej procedury są opisane w Definicji 41

Zgodnie z [11] ważne jest udowodnienie że kwoty wyjściowe [4] b1 hellip bn wszystkie mieszczą się w szeregu wartości dodatnich np (0 216) Można to osiągnąć zasadniczo w taki sam sposoacuteb jak w [11] kwestia ta jest bardziej szczegoacutełowo opisana w części 5Na koniec warto zauważyć że w powyższej dyskusji nie wspomniałem o właściwości związanej dołączaniem tagoacutew ktoacutera jest wykorzystywana w Monero oraz Cryptonote w celu zapobiegania podwoacutejnemu wydatkowaniu środkoacutew Dołączanie tagoacutew w tym momencie będzie skutkiem łączenia powyższego omoacutewienia z podpisami MLSAG o ktoacuterych mowa w Definicji 41

4 Ring CT dla protokołu Monero 41 Opis protokołuDefinicja 41 (Tagowalny pierścień CT z mnogimi danymi wejściowymi oraz kluczami jednorazowymi)

Niech stanowi zbioacuter adresoacutew oraz kluczy jednorazowychzobowiązań ktoacuterym odpowiadają sekretne klucze xj j = 1 hellip m

Znaleźć zbiory q + 1 i = 1 hellip q + 1 ktoacutere nie są połączone tagami w sensie [ 6 strona 6]

Należy określić zestaw adresoacutew wyjściowych (Qi Ciout) takich że

stanowią zobowiązania o wartości zero Niech

hellip

stanowi uogoacutelniony pierścień w ktoacuterym chcemy złożyć swoacutej podpis Należy zauważyć że ostatnia kolumna to pierścień Ring-CT w rozumieniu rozdziału 4

Obliczyć podpis MLSAG sum na R

[4] Ponieważ zobowiązania wejściowe mogą być potencjalnie odziedziczone z poprzednich transakcji wystarczy rozważyć kwoty wyjściowe

W takim przypadku zgodnie z teorematem A2 nie może być sygnatariuszem żadnych dodatkowych niezlinkowanych podpisoacutew pierścieniowych w danym nadzbiorze P wszystkich takich par P = (PC) po podpisaniu sum

Uwaga 42 Złożoność przestrzeni powyższego protokołu Warto zauważyć że rozmiar podpisu sum na R zgodnie z definicją 41 jest w rzeczywistości mniejszy dla m gt 1 niż bieżący podpis pierścieniowy transakcji opartej na protokole CryptoNote [16] ktoacutera zawiera mnogie dane wejściowe Dzieje się tak dzięki wprowadzeniu zmian w rozmiarze w [8] do każdej kolumny Należy także podkreślić że prawdopodobnie nie jest konieczne umieszczanie obrazu klucza zobowiązania związanego z wyżej wymienionym podpisem Kolejne optymalizacje rozmiaru są możliwe i można je wykonać w podobny sposoacuteb

42 Konwersja widocznych denominacji na zobowiązaniaPonieważ Monero obecnie wykorzystuje blockchainowe widoczne skalary w celu stworzenia reprezentacji kwot ważne jest aby istniała możliwość (i sposoacuteb) konwersji z kwot widocznych na zobowiązania przy jednoczesnym zachowaniu anonimowości Tak naprawdę wcale nie jest to trudne Mając daną parę (P a) gdzie P jest kluczem publicznym a a stanowi kwotę może ona być wykorzystana jako dane wejściowe transakcji jako (P aH) i transakcja ta musi być zweryfikowana przez weryfikatora pod kątem kwoty wejściowej i jej przemnożenia przez punkt maskujący H oraz czy uzyskana wartość rzeczywiście wynosi aH Zatem jako pierwszy krok kwoty wejściowe nie zostaną ukryte ale ukryte zostaną dane wyjściowe transakcji oraz wszelkie niezbędne relacje o ktoacuterych mowa w rozdziale 4 pozostają ważne Należy podkreślić że range proof nie jest konieczny dla tych danych wejściowych

Uwaga 43 Oczywistą zaletą tej metody jest konwersja z kwot widocznych na zobowiązania oraz to że kwota coinoacutew wygenerowanych w procesie wydobycia jest weryfikowalna bez konieczności udziału elementu zaufanego Jest to przewaga protokołu Ring CT nad systemami płatniczymi takimi jak [4] ktoacutere obejmują fazę ustawień strony zaufanej

43 Opłaty transakcyjnePonieważ system Monero jest silnie zdecentralizowany (tzn proof of work) konieczne jest wynagradzanie goacuternikoacutew i dokonywanie opłat za każdą transakcję Pomaga to podnieść bezpieczeństwo sieci i zapobiegać rozdęcia blockchainu Opłaty te muszą być realizowane w postaci niezamaskowanej tzn Jako bH a nie xG + bH oraz w odniesieniu do pewnej standardowej kwoty b w taki sposoacuteb że goacuternik będzie moacutegł zweryfikować że b ∙ H = bH i tym samym że jest dość środkoacutew na opłatę transakcyjną przy jednoczesnym zachowaniu roacutewnań związanych z H w taki sposoacuteb że zostaną zachowane niezbędne relacje o ktoacuterych mowa w Rozdziale 4

44 Ring MultisignatureWarto zauważyć że prosta wersja t z m z n ring-multisignature [mnogich podpisoacutew pierścieniowych] może być zrealizowana w oparciu o podpisy MLSAG Umożliwia to grupie m uczestnikoacutew zbudowanie multisignature takiego że t uczestnikoacutew z liczby z m musi złożyć podpis aby był on uznany za ważny dodatkowo jest on dwuznaczny w odniesieniu do sygnatariusza klucze m są uczestnikami mieszczącymi się w ogoacutelnej liczbie n kluczy

Liczba n uczestnikoacutew w multisignature stanowi wspoacutelny sekret xe oraz klucz publiczny Pe ktoacutere mają wspoacutelne obrazy kluczy multisig

Ij = xeH(PejPj)

z Pj ndash publicznym kluczem uczestnika Każdy uczestnik multisignature dokonuje wyboru dodatkowych kluczy publicznych n -

m w blockchainie oraz tworzy podpis MLSAG za pomocą pierwszego rzędu wszystkich kluczy n a drugi rząd ma dla każdego wpisu (elementu) klucz wspoacutelny Pe

Każdy sygnatariusz multisignature podaje początkowe Ij j = 1 hellip m w celu umożliwienia zaakceptowania klucza po przekazaniu podpisoacutew weryfikujących t w blockchainie z ktoacuterych każdy odpowiada jednemu obrazowi klucza Ij

Rozszerzony zapis ring-multisignature jest w fazie opracowania

5 Zagregowane schematy identyfikacji Schnorra (Aggregate Schnorr Range Proofs)W części [11] poufne transakcja bez podpisu pierścieniowego wykorzystuje pewien typ podpisu pierścieniowego oparty na [1] nazywany podpisem pierścienia boromejskiego (Borromean ring signature) i pomaga zidentyfikować przekłamania w wartości zobowiązań w pewnym przedziale W niniejszym artykule postaram się nakreślić alternatywną metodę zainspirowaną przez [7] ktoacutera pozwala na uzyskanie tych samych oszczędności w zakresie przestrzeni ale za to opatrzona jest nieco mniej skomplikowanym protokołem bezpieczeństwa Motywacja do tego typu działania jest następująca przypuśćmy że dana transakcja ma dane wejściowe zobowiązań roacutewne

Cin = ainG + 10H

oraz zobowiązania wyjściowe

Cout 1 = aout1G + 5H Cout2 = aout2G + 5H

Scenariusz ten zachowuje ważność gdyż istnieje możliwość złożenia podpisu dla Cin ndash Cout1 ndash Cout2 = (ain ndash aout1 ndash aout2)G

Nie mniej jednak warto podkreślić że (bez range proofs) będzie istniała możliwość alternatywnego ustawienia zobowiązań wyjściowych

Cout1 = aout1G- H Cout2 = aout2G + 11H

Ponieważ -1 jest bardzo dużą liczbą stanowiącą modulo porządkujące grupę krzywej tym samym zostały utworzone darmowe pieniądze Zatem konieczne jest wykazanie że Couti są zobowiązaniami w odniesieniu do wartości ktoacutere są pozytywne (dodatnie) i mieszczą się w ograniczonym przedziale [0 2n] dla niektoacuterych wartości n Aby tego dokonać należy rozłożyć każdą wartość wyjściową na elementy binarne

co pozwala obliczyć zobowiązania do bj ∙ 2j w taki sposoacuteb że

Na koniec wykorzystując sekretny klucz bj można obliczyć podpis pierścieniowy na

dla wszystkich j oraz zapewnia dla weryfikatoroacutew (w tym przypadku goacuternikoacutew)Jeżeli chodzi o oszczędności miejsca można albo wykorzystać boromejski podpis pierścieniowy (podobnie jak w [11]) albo połączyć wszystkie proste podpisy pierścieniowe bądź utworzyć pewien typ zagregowanego podpisu pierścieniowego zdefiniowanego w następujący sposoacuteb

501 Generowanie zagregowanego nielinkowanego podpisu pierścieniowego Schnorra (Aggregate Schnorr Non-linkable Ring Signature) (ASNL)

Niech stanowi zbioacuter kluczy j = 1hellip z jako sekretnym kluczem

Dla każdego j niech Irsquo = i + 1 mod 2 ustawić skalar losowy aj i obliczyć

Ustawić gdzie Hs to kryptograficzna funkcja haszująca zwracająca skalar po dokonaniu wyboru losowego obliczyć

Określić i obliczyć

Zwroacutecić dla wszystkich j i s =

502 Weryfikacja zagregowanego nielinkowalnego podpisu pierścieniowego Schnorra (ASNL)Zacznijmy od dla j = 1hellip n oraz s

Dla wszystkich j obliczyć oraz

Jeżeli to otrzymamy 0 dla ważnego podpisuW przeciwnym razie otrzymamy wartość zwrotną -1

Teoremat 51 Zagregowany nielinkowany podpis pierścieniowy Schnorra nie może być sfałszowany przy założeniu logarytmu dyskretnego

Dowoacuted Przedstawiam szkic dowodu w przypadku n = 2 Przypadek ogoacutelny ma zbliżony charakter Przypuśćmy że adwersarz A jest w stanie sfałszować podpis ASNL na

Przy pomijalnym prawdopodobieństwie znając najwyżej jedną z (przypuśćmy że bez straty ogoacutelnego charakteru założenia że A zna ) Dla każdego danego fałszu

rozwiązuję roacutewnanie logarytmu dyskretnego o niepomijalnym prawdopodobieństwie Po zastosowaniu algorytmu weryfikacji niech Zatem prawdziwe musi być roacutewnanie

Przypuśćmy że oraz a a b są znane A wtedy

ponieważ jest określone protokołem weryfikacji musi być zatem prawdą że A zna klucz

prywatny

=Jest to w sprzeczności z założeniem logarytmu dyskretnego dla danej grupy

51 Reprezentacja kwotKwoty w protokole Ring CT można przedstawiać w sposoacuteb zbliżony do tego ktoacutery przedstawiony został w [11] z drobną modyfikacją w celu dopasowania do systemu Monero Coiny CryptoNote organizują nominały coinoacutew w bazie indeksoacutew w taki sposoacuteb aby mogły być ułożone w porządku występowania jako dane wejściowe dla podpisoacutew pierścieniowych Ponieważ wszystkie wartości coinoacutew w CryptoNote są reprezentowane w postaci 64-bitowych niepodpisanych liczb całkowitych możemy wykorzystać range proof na przestrzeni całego rejestru w celu zakodowania kwoty wyjściowej przekazywanej odbiorcy Na szczęście to także umożliwia wzajemne miksowanie danych wyjściowych zatem wymagany jest tylko jeden indeks danych wyjściowych w porządku rejestracji Przedział weryfikacji (range proof) wynosi ok 5 kilobajtoacutew Podpisy pierścieniowe dla danych wejściowych stają się bardziej odporne na analizę ponieważ anonimowość jest bardzo rozszerzonaPodczas gdy obszary weryfikacji (range proofs) są duże wykorzystywanie układu haszującego ktoacutery dodaje przedrostek do transakcji (zaroacutewno indeksoacutew wejściowych jak i wyjściowych) i przechowuje szeroki zakres range proof wraz z podpisami umożliwia oddzielnie uzyskanie ogromnych oszczędności przestrzeni podczas synchronizacji (syncing) do punktu weryfikacji lub działanie jako węzeł SPV Podobnie do elementoacutew bocznych łańcucha (Sidechains Elements) [12] będziemy przechowywać H(H(prefiks)||H(podpisy)) w drzewie Merkla Następnie węzły syncing do zaufanego punktu weryfikacji muszą jedynie pobrać przedrostek i dodać wartość haszującą do podpisoacutew skutecznie redukując szerokość wiązki Ponieważ prefiks transakcji wykorzystuje wariant dla danych wyjściowych ktoacutere wymienia w swoich podpisach pierścieniowych oraz środkach zapisanych do jednego klucza publicznego stanowi on miniaturowe poroacutewnanie do danych podpisoacutew pierścieniowych w danych wyjściowych oraz range proofs

Następnie podpisy pierścieniowe mogą nawet być przycięte z bazy danych przez niektoacutere węzły w celu uzyskania dalszych zyskoacutew przestrzeni przechowując zastępczo jedynie względnie mały zbioacuter UTXO

511 Przekazywanie informacji o kwotach OdbiorcyObecnie mając dowolną kwotę wyjściową b = b020 + b121 + ∙∙∙ bn2n nadawca oblicza nową prywatnąpubliczną parę kluczy oraz związane wymieniane sekrety ECDH ss oraz udostępnia następujące informacje w swojej transakcji

gdzie ai to losowo wybrane liczby dla j = 0 hellipn Dane Klucz publiczny ECDH oraz a + ss mod l gdzie a = a0 + hellip + an

Następnie odbiorca Oblicza udostępniany sekret ss oraz oblicza a na podstawie a + ss mod l Oblicza C = sumCi oblicza C ndash aG = bH oraz oblicza b poroacutewnując uzyskane wartości do

wszystkich bH w danym przedziale [0 2n] (W praktyce będzie to szybkie 500 kilobajtowe wyszukanie w n = 12 podobnie jak w poprzednim rozdziale Gdyby jednak wartość 232 została wybrana jako goacuterna wartość graniczna podobnie jak w [11] wyszukiwanie stałoby się dużym obliczeniowo wysiłkiem)

6 WnioskiProtokoacuteł pierścieniowych transakcji poufnych (Ring Confidential Transactions) to bardzo silnie zdecentralizowana kryptowaluta (tzn nie ma w niej żadnej uprzywilejowanej strony) ktoacutera posiada proste do udowodnienia wartości szacunkowe zabezpieczeń dotyczące ukrywania kwot transferoacutew ich źroacutedeł oraz odbiorcoacutew Dodatkowo generowanie coinoacutew w oparciu o protokoacuteł Ring Confidential Transactions nie wymaga obecności czynnika zaufanego i proces jego weryfikacji jest całkowicie bezpiecznyTych pięć czynnikoacutew jest niezbędnych w przypadku kryptowalut zbliżonych do środkoacutew gotoacutewkowych takich jak MoneroBibliografia1 Masayuki Abe Miyako Ohkubo and Koutarou Suzuki 1-out-of-n signatures from a variety of keys Advances in CryptologyAsiacrypt 2002 pages 415ndash432 20022 Adam Back Bitcoins with homomorphic value (validatable but encrypted)httpsbitcointalkorgindexphptopic=3057910 2013 [Online accessed 1-May-2015]3 Adam Back Podpis pierścieniowy efficiency httpsbitcointalkorgindexphptopic=972541msg10619684msg10619684 2015 [Online accessed 1-May-2015]4 Eli Ben Sasson Alessandro Chiesa Christina Garman Matthew Green Ian Miers Eran Tromer and Madars Virza Zerocash Decentralized anonymous payments from bitcoin In Security and Privacy (SP) 2014 IEEE Symposium on pages 459ndash474 IEEE 20145 Evan Duffield and Kyle Hagan Darkcoin Peertopeer cryptocurrency with anonymous blockchain transactions and an improved proofofwork system 20146 Eiichiro Fujisaki and Koutarou Suzuki Traceable podpis pierścieniowy In Public Key CryptographyndashPKC 2007 pages 181ndash200 Springer 20077 Javier Herranz Aggregate signatures httpwwwiiiacsices~jherranzpapersNijmegen_seminar_aggregatepdf oct 20058 Joseph K Liu Victor K Wei and Duncan S Wong Linkable spontaneous anonymous group signature for ad hoc groups In Information Security and Privacy pages 325ndash335 Springer 20049 Adam Mackenzie Surae Noether and Monero Core Team Improving obfuscation in the cryptonote protocol httpslabgetmoneroorgpubsMRL-0004pdf January 201510 Greg Maxwell Coinjoin Bitcoin privacy for the real world august 2013 Bitcoin Forum httpsbitcointalkorgindexphptopic=2792490 2013 [Online accessed 1-July-2015]11 Greg Maxwell Confidential Transactions httpspeoplexiphorg~gregconfidential_valuestxt 2015 [Online accessed 1-June-2015]12 Greg Maxwell Elements project httpsgithubcomShenNoetherMiniNero 201513 Satoshi Nakamoto Bitcoin A peer-to-peer electronic cash system Consulted 1(2012)28 200814 Shen Noether Mininero httpsgithubcomShenNoetherMiniNero 201515 Ronald L Rivest Adi Shamir and Yael Tauman How to leak a secret In Advances in CryptologyASIACRYPT 2001 pages 552ndash565 Springer 200116 Nicolas van Saberhagen Cryptonote v 2 0 HYPERLINK https cryptonote org whitepaper pdf 2013

Załącznik A Załącznik Security ProofsA1 Brak możliwości sfałszowania MLSAG

Obliczenia przebiegają analogicznie do [8 Teoremat 1] Niech H1 oraz H2 będą losowo wybranymi oracle a SO stanowią podpisy oracle zwracające ważne podpisy MLSAG Załoacuteżmy że istnieje probabilistyczny wielomianowy adwersarz czasowy (PPT) A ktoacutery posiada zdolność sfałszowania MLSAG z listy wektoroacutew kluczy L przy prawdopodobieństwie ktoacuterego nie można pominąć

Gdzie Q1 stanowi wielomianowy parametr bezpieczeństwa k oraz gdzie (m σ) nie stanowi jednego z podpisoacutew zwracanych przez SO Załoacuteżmy że A nie wysyła więcej niż qH + nqS

(gdzie n oznacza liczbę kluczy w L) zapytań dotyczących podpisoacutew oracle H1H2 oraz SO odpowiednio Podpisy oracle H1 oraz H2 uważa się za niezależne i losowe oraz spoacutejne z danymi zapytaniami powtarzającymi się Podpis oracle SO może składać zapytanie H1 oraz H2 Mając wartość A wykaże że istnieje możliwość utworzenia adwersarza M w PPT ktoacutery będzie wykorzystywać A w celu znalezienia logarytmu dyskretnego jednego z kluczy w L

Jeżeli L stanowi zbioacuter kluczy wektoroacutew z ktoacuterych każdy będzie mieć wielkość r (tzn z kluczami publicznymi y1 hellip yr ) to wygenerowany fałszywy podpis

Wygenerowany przez A musi spełniać warunek

Gdzie i są obliczone w ramach mod n oraz są zdefiniowane zgodnie z Rozdziałem 22 Nowy adwersarz M może wykorzystać A w celu sfałszowania podpisoacutew wielomianową liczbę razy i zapisze każdy skrypt Turinga T niezależnie czy sfałszowanie było skuteczne czy nie

Lemma A1 [8 Lemma 1] Niech M wywołuje A w celu uzyskania transkrypcji T Jeżeli T jest skuteczne to M powraca do T do nagłoacutewka H i następnie re-symuluje A w celu uzyskania transkrypcji Trsquo Jeżeli Pr (T okaże się skuteczne) = ϵ to Pr (Trsquo jest skuteczne) = ϵ

Dowoacuted wynika wprost z przywołanego teorematu

Teoremat A2 Prawdopodobieństwo że adwersarz A sfałszuje podpis MLSAG można pominąć przy założeniu logarytmu dyskretnego

Dowoacuted Do przeprowadzenia dowodu będę stosować notację przedstawioną powyżej Podobnie jak w przypadku [8 teoremat 1] ponieważ prawdopodobieństwo odgadnięcia danych wyjściowych z losowego oracle jest znikome w związku z tym dla każdego skutecznego oszustwa A wprowadza transkrypcję uzupełniającą T a zatem mamy mT zapytań w przypadku zapytań do H1 odpowiadających liczbie n zapytań wykorzystywanych w celu weryfikacji podpisu W związku z tym niech Xi1 hellip Xim oznacza zapytania wykorzystywane w procesie weryfikacji fałszu ith oraz niech π oznacza indeks odpowiadający ostatniemu zapytaniu weryfikacyjnego dla danego oszustwa

(Intuicyjnie π odpowiada temu co może stanowić indeks sekretny fałszywego podpisu ponieważ odpowiada on ostatniemu wezwaniu ostatniemu wywołaniu losowego oracle dla danego odpisu)Proacuteba sfałszowania σ podjęta przez A stanowi fałsz (l π) jeżeli i1 = l oraz π jest zgodne z powyższym (zatem fałsz odpowiada zapytaniom l do l + π) Z założenia istnieje para (l π) taka że prawdopodobieństwo związanej transkrypcji T daje skutecznie wygenerowany fałszywy klucz ϵlπ (T) spełnia warunek

1

Teraz przeglądając T do wartości przed zapytaniem l-tym a następnie podejmując proacutebę sfałszowania za pomocą tego samego zbioru kluczy (oraz dopuszczając aby H1 obliczyło nowe rzuty monetami dla wszystkich kolejnych zapytań) z Lemmy A1 wynika że prawdopodobieństwo że Trsquo jest także skuteczne spełnia warunki

_Dlatego prawdopodobieństwo że zaroacutewno T jak i Trsquo odpowiadają weryfikacjom fałszywym σ i σ1 nie może zostać pominięte

Ponieważ nowe rzuty monetami zostały obliczone na podstawie danych wyjściowych losowych oracle H1 oznacza to że przy dużym prawdopodobieństwie istnieje wartość j taka

że oraz W związku z tym możemy rozwiązać klucz prywatny z indeksem π

ktoacutery jest sprzeczny z założeniami logarytmu dyskretnego

A2 Linkowalność MLSAG Teoremat A3 Linkowalność obrazu klucza (Key-Image Linkability) Prawdopodobieństwo że adwersarz a w PPT może utworzyć dwa podpisy weryfikujące (niepołączone w danym

ustawieniu σ σrsquo podpisane w odniesieniu do wektoroacutew kluczy oraz odpowiednio w taki

sposoacuteb że będzie istnieć klucz publiczny i w obu oraz może być pominięte

Dowoacuted Przypuśćmy że w przeciwieństwie do tego co zostało wcześniej powiedziane A utworzył dwa podpisy weryfikujące σ oraz σrsquo o oba są podpisami w odniesieniu do kluczowych wektoroacutew

oraz odpowiednio w taki sposoacuteb że istnieje klucz publiczny y zaroacutewno w jak i

Niech y występuje jako element j należący do a jrsquo jako element należący do rsquo Z teorematu A2 wynika z dużym prawdopodobieństwem że istnieją indeksy π oraz πrsquo dla kluczy publicznych σ oraz σrsquo odpowiednio takie że

oraz

z

oraz

Jeżeli uznamy że x oznacza klucz prywatny y y = xG to po rozwiązaniu powyższego dla Ij

oraz Ij0rsquo mamy następujące roacutewnania oraz podobnie Ijrsquo = xH (y) Tym samym dwa podpisy obejmują Ij = Ijrsquo i w związku z tym ponieważ zduplikowane obrazy kluczy są odrzucone jeden z nich nie może być wykorzystany do weryfikacji

A3 Anonimowość MLSAG W celu udowodnienia anonimowości powyższego protokołu w losowym modelu oracle przyjmijmy że H1 H2 to losowe oracle modelujące dyskretne funkcje haszujące Niech A to adwersarz anonimowości Buduję adwersarza M względem założenia problemu decyzyjnego Diffie Helmana (DDH) zgodnie z poniższym Założenie DDH stwierdza że mając daną krotność (G aG bG ϒG) prawdopodobieństwo ustalenia czy G = abG jest znikome

Teoremat A4 Protokoacuteł pierścieniowy CT jest dwuznaczny w odniesieniu do sygnatariusza przy założeniu problemu decyzyjnego Diffie-HelmanaDowoacuted (zbliżony do dowodu [8 Teoremat 2]) Załoacuteżmy że problem decyzyjny Diffie-Helmana jest trudny w cyklicznej grupie generowanej przez G i załoacuteżmy że istnieje adwersarz A w czasie PPT względem dwuznaczności sygnatariusza Tym samym mając listę L n wektoroacutew

kluczy publicznych o długości m oraz zbioacuter prywatnych kluczy t ważny podpis σ na L podpisany przez użytkownika w odniesieniu do wektora klucza y taki że

odpowiedni wektor klucza prywatnego wynosi spełnia to A może zdeterminować π z prawdopodobieństwem

Dla wybranych wielomianoacutew Q(k) Buduję adwersarza PPT M ktoacutery wykorzystuje krotność danych wejściowych (G aG bG ciG) gdzie I ϵ 0 1 jest losowo wybrany (a nie znany M a priori) c1 = ab oraz c0 jest losowym skalarem a dane wyjściowe i mają prawdopodobieństwo

Dla niektoacuterych wielomianoacutew Q2 (k)Należy rozważyć algorytm SIMNIZKP (zbliżony to tego ktoacutery został zdefiniowany w [6]) ktoacutery jako skalary wejściowe wykorzystuje wektor x klucza prywatnego zbioacuter wektoroacutew kluczy

publicznych indeks π oraz wiadomość m i ktoacutery działa w sposoacuteb następujący1 Wygenerować skalary losowe s1 hellip sm oraz skalar losowy cπ lt- H2 Dla j indeksującego określić

A dla pozostałych j

3 Obliczyć losowe dane wyjściowe na podstawie losowego oracle

4 Dla każdego i roboczego mod m obliczyć

Należy podkreślić że w ostatnim punkcie kiedy i = π - 1 to ci+1 jest już określone w celu utrzymania spoacutejności z losowymi danymi wyjściowymi oracleNależy podkreślić że niezależnie od tego czy jest rzeczywistym kluczem prywatnym odpowiadającym ze względu na to że spoacutejność jest zachowywana przez losowe wartości oracle w kolejnych wezwaniach powyższy podpis jest weryfikowany Jeżeli x jest rzeczywiście wektorem klucza prywatnego y to nie ma roacuteżnicy pomiędzy SIMNIZKP oraz rzeczywistym podpisemNa koniec mając krotność (G aG bG ciG) gdzie a b są losowo wybrany skalarami a c1 = ab c0 elementem losowym i ϵ 0 1 M zachodzi w poniższych krokach i pozwala rozwiązać problem decyzyjny Diffie Helmana za pomocą niepomijalnego prawdopodobieństwa M wychwytuje losowe ϒ lt-H z losowej wartości oracle oraz pobiera parę wektoroacutew klucza prywatnego publicznego (x y) a następnie oblicza s jako a = s + ϒx Teraz M wykonuje

SIMNIZKP za pomocą dowolnie wybranych wektoroacutew kluczy w taki sposoacuteb że w danej wiadomości m oraz Jeżeli prawdziwe jest że i = 1 to c = ab oraz logGaG = logbGcG = a

z uwagi na to że zakłada się iż A jest w stanie znaleźć π z prawdopodobieństwem ktoacuterego nie można pominąć to istnieje niepomijalne prawdopodobieństwo frac12 że A zwroacuteci 1 (i wtedy M zwroacuteci 1) Jeżeli i = 0 to A zwraca 1 wyłącznie z prawdopodobieństwem frac12 a zatem dla niektoacuterych niepomijanych prawdopodobieństw powyżej 1`2 M zwraca tę samą wartość co A i tym samym rozwiązuje problem decyzyjny Diffie-Helmana dla losowo wybranych skalaroacutew bez pomijalnego prawdopodobieństwa powyżej 12 co stanowi sprzeczność

Załącznik B Kod demo Ring CT W repozytorium w [14] zbudowałem prostą demonstrację protokołu poufnych transakcji pierścieniowych (Ring Confidential Transactions) wykorzystujących podpisy MLSAG w części 2 oraz podpisy ASNL w części 5

H_ct = RingCTgetHForCT()print(H H_ct)sr Pr = PaperWalletskpkGen() receivers private publicse pe ss = ecdhecdhgen(Pr) compute shared secret ssdigits = 14 in practice it will be 14print(inputs)Cia L1a s2a sa ska = RingCTgenRangeProof(10000 digits)print(outputs)Cib L1b s2b sb skb = RingCTgenRangeProof(7000 digits)Cic L1c s2c sc skc = RingCTgenRangeProof(3000 digits)print(verifying range proofs of outputs)RingCTverRangeProof(Cib L1b s2b sb)RingCTverRangeProof(Cic L1c s2c sc)x P1 = PaperWalletskpkGen()P2 = PaperWalletpkGen()C2 = PaperWalletpkGen()some random commitment grabbed from the blockchainind = 0Ca = RingCTsumCi(Cia)Cb = RingCTsumCi(Cib)Cc = RingCTsumCi(Cic)sk = [x MiniNerosc_sub_keys(ska MiniNerosc_add_keys(skb skc))]

pk = [[P1 P2] [MiniNerosubKeys(Ca MiniNeroaddKeys(Cb Cc)) MiniNerosubKeys(C2 MiniNeroaddKeys(Cb Cc)) ] ]II cc ssVal = MLSAGMLSAG_Sign(pk sk ind)print(Sig verified MLSAGMLSAG_Ver(pk II cc ssVal) )print(Finding received amount corresponding to Cib)RingCTComputeReceivedAmount(pe sr MiniNeroaddScalars(ss skb) Cib)print(Finding received amount corresponding to Cic)RingCTComputeReceivedAmount(pe sr MiniNeroaddScalars(ss skc) Cic)

Przykład transakcji z danymi wejściowymi 10 000 oraz wyjściowymi 3 000 i 7 000(rsquoHrsquo rsquo61fe7f0f5a607a33427d01dd1fded5ffa03fae2e9df9ebccf2e0a2f5bd77a204rsquo)inputs(rsquob b in binaryrsquo 10000 [0 0 0 0 1 0 0 0 1 1 1 0 0 1])Generating Aggregate Schnorr Non-linkable Podpis pierścieniowy outputs(rsquob b in binaryrsquo 7000 [0 0 0 1 1 0 1 0 1 1 0 1 1 0])Generating Aggregate Schnorr Non-linkable Podpis pierścieniowy (rsquob b in binaryrsquo 3000 [0 0 0 1 1 1 0 1 1 1 0 1 0 0])Generating Aggregate Schnorr Non-linkable Podpis pierścieniowy verifying range proofs of outputsVerifying Aggregate Schnorr Non-linkable Podpis pierścieniowy VerifiedVerifying Aggregate Schnorr Non-linkable Podpis pierścieniowy Verified(rsquoGenerating MLSAG sig of dimensions rsquo 2 rsquox rsquo 2)(rsquoverifying MLSAG sig of dimensions rsquo 2 rsquox rsquo 2)(rsquocrsquo[rsquo80a3cfd06dd2862307cd75c2a1566f20cd743dbb0b9feb22d79dcbecb9023f42rsquorsquoa9b7342ba7bf2f102505ca19dab734fde638916c0a29f5b30e49833ab51393earsquorsquo80a3cfd06dd2862307cd75c2a1566f20cd743dbb0b9feb22d79dcbecb9023f42rsquo])(rsquosig verifiesrsquo True)(rsquoSig verifiedrsquo True)Finding received amount corresponding to Cib(rsquoreceived rsquo 7000c Monero Research Lab Page 20 of 20rsquoa488ec68732fb551841c2c6dcc7ffac895d98ec7e9378275ed20ea12805fc18ersquo)Finding received amount corresponding to Cic(rsquoreceived rsquo3000rsquo1b46626858e130a0f3884c74c9fdeabc4d812c519103ea16a35a3f82a3d0ed6drsquo)

Niniejszy rozdział zawiera definicję podpisoacutew typu Multilayered Linkable Spontaneous Anonymous Group (MLSAG) wykorzystywanych przez protokoacuteł Ring CT Należy podkreślić że definiuję je jako podpis ogoacutelny a niekoniecznie jako przykład wykorzystania w Pierścieniowych Transakcjach Poufnych MLSAG jest zasadniczo zbliżony do LSAG-oacutew opisanych w [8] ale zamiast składać podpis na zbiorze n kluczy MLSAG sam w sobie stanowi podpis pierścieniowy na zbiorze wektoroacutew n kluczy

Definicja 21 Wektor kluczy jest po prostu zbiorem kluczy publicznych odpowiadających kluczom prywatnym

[1] Poprzednio autor założył że mogłoby to roacutewnież umożliwić ujawnienie (odsłonięcie) transakcji ale najnowsza publikacją dotycząca ZeroCash wyraźnie stwierdza że to niemożliwe

21 Podpisy LWW a podpisy FS Podpisy pierścieniowe wykorzystywane w Monero oraz oryginalny protokoacuteł CryptoNote są pochodnymi podpisoacutew pierścieniowych możliwych do wyśledzenia z [6] Podpisy pierścieniowe w ramach CryptoNote [16] zawierają ldquoobraz kluczardquo co oznacza że podpisujący może podpisać jeden pierścień w blockchainie używając danego klucza publicznego oraz pary kluczy prywatnych albo ich transakcja zostanie oznaczona jako nieważna W związku z tym wykorzystywane są klucze jednorazowe w protokole CryptoNote ktoacutere następnie podnoszą poziom anonimowościW [3] Adam Back podkreśla że podpisy w ramach Linkable Spontaneous Anonymous Group (LSAG) w [8] mogą być modyfikowane w taki sposoacuteb aby utworzyć bardziej wydajny linkowany podpis pierścieniowy dający ten sam efekt jaki uzyskuje się w przypadku podpisu pierścieniowego z [6] Modyfikacja ta pozwala obniżyć koszty przechowywania w blockchainie zasadniczo o połowęNa początek przytoczę ndash niemal dosłownie ndash modyfikacje opisane w [3]Keygen [Generowanie klucza] Znajdź pewną liczbę kluczy publicznych Pi i = 0 1 hellip n oraz sekretny indeks j spełniający warunek xG = Pj gdzie G stanowi punkt bazowy ed25519 a x to klucz wydatkowany sygnatariuszy Niech I = xHp (Pj) gdzie Hp jest funkcją haszującą zwracającą punkt [2] Niech m stanowi daną wiadomośćPODPIS Niech α si i ne j i ϵ 1 hellip n będą wartościami losowymi w Zq (pole bazowe ed25519)ObliczLj = αGRj = αHp (Pj)cj+1 = h (m Lj Rj)gdzie h jest funkcją haszującą zwracającą wartość w Zq Teraz dokonując kolejnych obliczeń j modulo n należy zdefiniowaćLj+1 = sj+1G + cj+1Pj+1Rj+1 = sj+1Hp (Pj+1) + cj+1 _ Icj+2 = h (m Lj+1 Rj+1)hellip

Lj-1 = sj-1G + cj-1Pj-1Rj-1 = sj-1Hp (Pj-1) + cj-1∙ Icj = h (mLj-1 Rj-1)

[2] W praktyce Hp(P) = Keccak(P) ∙ G gdzie G jest punktem bazowym ed25519 chociaż należy zauważyć że w odniesieniu do układu zobowiązań będę wykorzystywać toPoint(Keccak(P)) haszujący kolejno aż do zwrotu wielokrotności punktu bazowego przez Keccak(P)

po to aby umożliwić definicję c1 hellip cnNiech sj = α - cj ∙ xj mod l (l stanowi porządek krzywej ed25519) stąd α = sj + cjxj mod l w taki sposoacuteb że Lj = _G = sjG + cjxjG = sjG + cjPjRj = _Hp (Pj) = sjHp (Pj) + cjIorazcj+1 = h (m Lj Rj)stąd mając jednostkową wartość ci wartości Pj obraz klucza I oraz wszystkie wartości sj pozostałe ck k 6= i mogą być odkryte przez obserwatora Podpis w związku ma postaćα = (I c1 s1 hellip sn)reprezentując oszczędności w zakresie zajmowanego miejsca w stosunku do [16 44] gdzie podpis pierścieniowy moacutegłby zamiennie wyglądać w następujący sposoacutebα = (I c1 hellip cn s1 hellip sn)Weryfikacja przebiega w następujący sposoacuteb Obserwator oblicza wartości Li Ri oraz ci dla wszystkich i oraz weryfikuje czy cn+1 = c1 Następnie weryfikator sprawdza czy

ci+1 = h (m Li Ri)dla wszystkich i mod nLINK Podpisy z duplikatami obrazoacutew kluczy I są odrzucaneNależy podkreślić że protokoły proofs of unforgeability anonimowości oraz łączenia obowiązują i stanowią jedynie nieznaczne modyfikacje protokołoacutew proof o ktoacuterych mowa w [8] Przedstawię nieco bardziej uogoacutelnioną wersję tych protokołoacutew dla MLSAG

22 Opis MLSAG W odniesieniu do protokołu Ring CT ktoacuterego opis znajduje się w części 4 wymagam uogoacutelnienia podpisoacutew Back LSAG opisanych w poprzednim rozdziale co umożliwia stosowanie wektoroacutew kluczy (Definicja 21) zamiast po prostu kluczyPrzypuśćmy że każda osoba składająca podpis pod (uogoacutelnionym) pierścieniem

zawierającym n członkoacutew (uczestnikoacutew) ma dokładnie m kluczy Celem podpisu pierścieniowego MLSAG jest realizacja następujących celoacutew

udowodnienie że jeden z podpisujących n zna sekretny klucz właściwy dla całego wektora klucza

Zapewnienie że jeżeli podpisujący wykorzystuje jeden z kluczy podpisoacutew m w innym podpisie MLSAG to dwa pierścienie są połączone a drugi taki podpis MLSAG (zlecony przez blockchain Monero) zostanie odrzucony

Algorytm działa w sposoacuteb następujący niech m stanowi wiadomość Niech π jest sekretnym indeksem odpowiadającym sygnatariuszowi uogoacutelnionego pierścienia Dla j = 1 hellip m niech

oraz dla j = 1 hellip m i = 1 hellip π hellipn (gdzie π oznacza ominięcie indeksu π) niech stanowi jeden z losowych skalaroacutew (elementoacutew Zq) Teraz w sposoacuteb analogiczny do części 21 należy zdefiniować

dla skalaroacutew losowych αj oraz j = 1 hellip m A teraz ponownie analogicznie do części 21 należy określić

i powtoacuterzyć czynność zwiększając przyrostowo i modulo n aż do momentu uzyskania następującej postaci

Na koniec dla każdego rozwiązać mod l Podpis jest następnie przekazywany jako zatem kompleksowość wynosi O (m(n + 1)) Proces weryfikacji przebiega poprzez regenerację wszystkich zaczynając od i = 1 podobnie jak to miało miejsce w części 21 (ktoacutera

stanowi przypadek szczegoacutelny w ktoacuterym m = 1) i przeprowadzając sprawdzenie funkcji haszującej cn+1 = c1 Jeżeli wartości te są wykorzystywane w ustawieniu blockchainowym takim jak Monero podpisy składane za pomocą obrazoacutew kluczy Ij ktoacutere już się pojawiły są następnie odrzucane Można to w bardzo łatwy sposoacuteb wykazać stosując metodę zbliżoną do [8] że

Prawdopodobieństwo że sygnatariusz generujący ważny podpis bez znajomości wszystkich prywatnych kluczy ldquomrdquo należących do ich wektora kluczy dla indeksu π może być pominięty

Prawdopodobieństwo że sygnatariusz nie podpisze żadnego klucza z indeksu π może zostać pominięte (Innymi słowy wszystkie obrazy kluczy stanowiące część podpisu muszą pochodzić z indeksu π)

Jeżeli sygnatariusz podpisuje dwa pierścienie wykorzystując co najmniej jeden z tożsamych kluczy publicznych to następuje skojarzenie (połączenie) dwoacutech pierścieni

Szersze omoacutewienie tych elementoacutew znajduje się w dalszej części materiału dotyczącej zabezpieczeń (security proofs)

23 Model zabezpieczeń MLSAGMLSAG spełnia trzy niżej wymienione właściwości niefałszowalność (Unforgeability) linkowalność (Linkability) oraz Dwuznaczność Sygnatariusza (Signer Ambiguity) ktoacutere są bardzo zbliżone do definicji podanej w [8]

Definicja 22 Niefałszowalność (Unforgeability) System podpisoacutew MLSAG jest niemożliwy do sfałszowania jeżeli dla danego algorytmu A wielomianowego czasu probabilistycznego (PPT) z podpisem oracle SO generującego ważne podpisy oraz dla danej listy wektoroacutew kluczy publicznych n wybranej przez A A może generować przy pomijalnym prawdopodobieństwie ważny podpis w sytuacji gdy A nie zna jednego z odpowiednich wektoroacutew kluczy prywatnych

Uwaga 23 W poniższej definicji należy zauważyć że umieściłem funkcję odrzucania duplikujących się obrazoacutew kluczy jako części kryterioacutew weryfikacji dla MLSAG co przyczynia się do zbudowania nieco zmodyfikowanej definicji linkowalności (Linkability) w stosunku do tej ktoacutera została podana w [8]

Definicja 24 Linkowalność (Linkability) Niech L stanowi zbioacuter wszystkich kluczy publicznych w danym ustawieniu (np w danym łańcuchu blokowym - blockchainie) System składania podpisoacutew MLSAG w L jest połączony z obrazami kluczy jeżeli prawdopodobieństwo że

adwersarz A utworzy w PPT dwa podpisy σ σ1 podpisane w odniesieniu do wektoroacutew kluczy

oraz 1 z ktoacuterych każdy będzie zawierać ten sam klucz publiczny yi = yirsquo W L oraz każdy będzie weryfikowany bez oznaczenia jako duplikat jest pomijalne

Definicja 25 Dwuznaczność sygnatariusza (Signer Ambiguity) System składania podpisoacutew MLSAG uważa się za niejednoznacznie identyfikujący sygnatariusza jeżeli mamy dany podpis weryfikujący σ na wektorach kluczy oraz dowolny zbioacuter kluczy prywatnych t z ktoacuterych każdy będzie mieć oddzielny indeks oraz sekretny indeks w takiej sytuacji prawdopodobieństwo odgadnięcia klucza sekretnego wynosi mniej niż

Dowody potwierdzające powyższe definicje przedstawiono w Załączniku

3 Zarys historyczny transakcji poufnych31 Transakcje poufne w ramach system Bitcoin

W [11] Greg Maxwell opisuje transakcje poufne ktoacutere są pewną metodą przekazywania transakcji w systemie Bitcoin przy jednoczesnym maskowaniu kwot Podstawową kwestią jest stosowanie schematu zobowiązań Pedersena metoda ta jest doskonale opisana w cytowanym materiale źroacutedłowym W niniejszym opracowaniu wprowadzam drobną modyfikację do mechaniki Transakcji Poufnych polegającą na wybieraniu zamiast zobowiązań ktoacuterych suma wynosi zero opcji złożenia podpisu pod zobowiązaniem w celu wykazania że klucz prywatny jest mi znany Schemat ten jest opisany szczegoacutełowo w kolejnym rozdziale

32 Modyfikacja pod kątem podpisoacutew pierścieniowych Niech G stanowi punkt bazowy ed25519 Niech [3]

H = toPoint (cn_fast_hasz (G))

Należy podkreślić że nie każda wartość haszująca pozwala obliczyć punkt w ramach grupy punktu bazowego (tzn dla pewnej niewiadomej) (co jest sprzeczne z tym co dzieje się w secp256k1 krzywej wykorzystywanej w systemie Bitcoin) Nie mniej jednak wydaje się że wyboacuter punktu bazowego jako takiego (wcześniej wykorzystywałem H(123456G) sprawdza się co z resztą wydawało mi się bardziej bezpieczne przy czym punkt bazowy jest z pewnością bardziej naturalnym wyborem) Wyboacuter H = ϒG dla pewnej niewiadomej jest konieczny po to aby pełna matematyka zwykłych krzywych eliptycznych zachowała swoją ważność

[3] H = MiniNerogetHForCT() w kontekście kodu w [14]

Przy założeniu logarytmoacutew dyskretnych w ed25519 prawdopodobieństwo że adwersarz odkryje ϒ jest pomijalne Należy zdefiniować C (a x) = xG+aH zobowiązanie wartości a z maską x Należy podkreślić że tak długo jak wartość logGH nie jest znana oraz jeżeli σ ne 0 to logGC (a x) pozostaje wartością nieznaną Z drugiej strony jeżeli a = 0 to logGC (a x) = x a zatem istnieje możliwość złożenia podpisu za pomocą pary kluczy sk-pk (xC (0 x)) W [11] istnieją dane wejściowe I wyjściowe zobowiązań a sieć sprawdza czy

sumdane wejściowe = sumdane wyjściowe

Nie mniej jednak nie jest to wystarczające w przypadku systemu Monero ponieważ dana transakcja zawiera roacuteżne możliwe do realizacji dane wejściowe Pi i = 1 hellip n z ktoacuterych tylko jedna należa do nadawcy (patrz [16 44]) to jeżeli będziemy w stanie sprawdzić powyższe roacutewnanie to musi być możliwe aby sieć widziała ktoacutere Pi należy do nadawcy transakcji Nie jest to zjawisko pożądane ponieważ eliminuje anonimowość zbudowaną dzięki podpisowi pierścieniowemu W związku z tym zastępczo tworzy się zobowiązania dla danych wejściowych oraz wyjściowych zgodnie z poniższym (załoacuteżmy najpierw że istnieje tylko jeden zestaw danych wejściowych)

Cin = xcG + aHCout10485761 = y1G + b1HCout10485762 = y2G + b2H

W taki sposoacuteb że xc = y1+y2+z xc - y1 - y2 = z yi są wartościami maskującymi z gt 0 oraz a = b1+b2W tym przypadku xc stanowi szczegoacutelny prywatny klucz a ldquokwota kluczardquo znana jest tylko nadawcy oraz osobie do ktoacuterej coiny są wysyłane zatem musi być odmienna od normalnego klucza prywatnego W takim przypadku

= xcG + aH - y1G - b1H - y2G - b2H= zG

A zatem powyższe roacutewnanie staje się zobowiązaniem do 0 przy sk = z oraz pk = zG a nie rzeczywistym roacutewnaniem o sumie zerowej Należy podkreślić że z nie jest wyliczalne dla coinoacutew źroacutedłowych xc chyba że znana jest zaroacutewno wartość y1 jak i y2 nie mniej jednak nawet to można w prosty sposoacuteb złagodzić poprzez uwzględnienie dodatkowych adresoacutew zmiany (zwykły przypadek zakłada że drugie zobowiązanie z wartością y2 jako maską są wysyłane jako zmiana)Ponieważ podawanie informacji ktoacutere dane wejściowe należą do nadawcy nie jest pożądane podpis pierścieniowy zawierający wszystkie zobowiązania wejściowe Ci i = 1 hellip s hellip n (gdzie s stanowi sekretny indeks zobowiązania nadawcy) dodaje się odpowiedni klucz publiczny (dzięki czemu zobowiązania oraz klucze publiczne są parowane (Ci Pi) ale tylko takie ktoacutere mogą być wspoacutelnie wydatkowane) oraz odejmuje sumCout

Jest to podpis pierścieniowy ktoacutery może być złożony ponieważ znamy jeden z prywatnych kluczy (a mianowicie z + xrsquo zawierający z jak wyżej oraz xrsquoG = Ps) Tak naprawdę ponieważ wiemy że dla każdego i zaroacutewno klucze prywatne dla Pi jak i klucze prywatne dla Pi + Ciin - sumjCjout możemy złożyć podpis zgodnie z treścią rozdziału 22 Szczegoacuteły tej procedury są opisane w Definicji 41

Zgodnie z [11] ważne jest udowodnienie że kwoty wyjściowe [4] b1 hellip bn wszystkie mieszczą się w szeregu wartości dodatnich np (0 216) Można to osiągnąć zasadniczo w taki sam sposoacuteb jak w [11] kwestia ta jest bardziej szczegoacutełowo opisana w części 5Na koniec warto zauważyć że w powyższej dyskusji nie wspomniałem o właściwości związanej dołączaniem tagoacutew ktoacutera jest wykorzystywana w Monero oraz Cryptonote w celu zapobiegania podwoacutejnemu wydatkowaniu środkoacutew Dołączanie tagoacutew w tym momencie będzie skutkiem łączenia powyższego omoacutewienia z podpisami MLSAG o ktoacuterych mowa w Definicji 41

4 Ring CT dla protokołu Monero 41 Opis protokołuDefinicja 41 (Tagowalny pierścień CT z mnogimi danymi wejściowymi oraz kluczami jednorazowymi)

Niech stanowi zbioacuter adresoacutew oraz kluczy jednorazowychzobowiązań ktoacuterym odpowiadają sekretne klucze xj j = 1 hellip m

Znaleźć zbiory q + 1 i = 1 hellip q + 1 ktoacutere nie są połączone tagami w sensie [ 6 strona 6]

Należy określić zestaw adresoacutew wyjściowych (Qi Ciout) takich że

stanowią zobowiązania o wartości zero Niech

hellip

stanowi uogoacutelniony pierścień w ktoacuterym chcemy złożyć swoacutej podpis Należy zauważyć że ostatnia kolumna to pierścień Ring-CT w rozumieniu rozdziału 4

Obliczyć podpis MLSAG sum na R

[4] Ponieważ zobowiązania wejściowe mogą być potencjalnie odziedziczone z poprzednich transakcji wystarczy rozważyć kwoty wyjściowe

W takim przypadku zgodnie z teorematem A2 nie może być sygnatariuszem żadnych dodatkowych niezlinkowanych podpisoacutew pierścieniowych w danym nadzbiorze P wszystkich takich par P = (PC) po podpisaniu sum

Uwaga 42 Złożoność przestrzeni powyższego protokołu Warto zauważyć że rozmiar podpisu sum na R zgodnie z definicją 41 jest w rzeczywistości mniejszy dla m gt 1 niż bieżący podpis pierścieniowy transakcji opartej na protokole CryptoNote [16] ktoacutera zawiera mnogie dane wejściowe Dzieje się tak dzięki wprowadzeniu zmian w rozmiarze w [8] do każdej kolumny Należy także podkreślić że prawdopodobnie nie jest konieczne umieszczanie obrazu klucza zobowiązania związanego z wyżej wymienionym podpisem Kolejne optymalizacje rozmiaru są możliwe i można je wykonać w podobny sposoacuteb

42 Konwersja widocznych denominacji na zobowiązaniaPonieważ Monero obecnie wykorzystuje blockchainowe widoczne skalary w celu stworzenia reprezentacji kwot ważne jest aby istniała możliwość (i sposoacuteb) konwersji z kwot widocznych na zobowiązania przy jednoczesnym zachowaniu anonimowości Tak naprawdę wcale nie jest to trudne Mając daną parę (P a) gdzie P jest kluczem publicznym a a stanowi kwotę może ona być wykorzystana jako dane wejściowe transakcji jako (P aH) i transakcja ta musi być zweryfikowana przez weryfikatora pod kątem kwoty wejściowej i jej przemnożenia przez punkt maskujący H oraz czy uzyskana wartość rzeczywiście wynosi aH Zatem jako pierwszy krok kwoty wejściowe nie zostaną ukryte ale ukryte zostaną dane wyjściowe transakcji oraz wszelkie niezbędne relacje o ktoacuterych mowa w rozdziale 4 pozostają ważne Należy podkreślić że range proof nie jest konieczny dla tych danych wejściowych

Uwaga 43 Oczywistą zaletą tej metody jest konwersja z kwot widocznych na zobowiązania oraz to że kwota coinoacutew wygenerowanych w procesie wydobycia jest weryfikowalna bez konieczności udziału elementu zaufanego Jest to przewaga protokołu Ring CT nad systemami płatniczymi takimi jak [4] ktoacutere obejmują fazę ustawień strony zaufanej

43 Opłaty transakcyjnePonieważ system Monero jest silnie zdecentralizowany (tzn proof of work) konieczne jest wynagradzanie goacuternikoacutew i dokonywanie opłat za każdą transakcję Pomaga to podnieść bezpieczeństwo sieci i zapobiegać rozdęcia blockchainu Opłaty te muszą być realizowane w postaci niezamaskowanej tzn Jako bH a nie xG + bH oraz w odniesieniu do pewnej standardowej kwoty b w taki sposoacuteb że goacuternik będzie moacutegł zweryfikować że b ∙ H = bH i tym samym że jest dość środkoacutew na opłatę transakcyjną przy jednoczesnym zachowaniu roacutewnań związanych z H w taki sposoacuteb że zostaną zachowane niezbędne relacje o ktoacuterych mowa w Rozdziale 4

44 Ring MultisignatureWarto zauważyć że prosta wersja t z m z n ring-multisignature [mnogich podpisoacutew pierścieniowych] może być zrealizowana w oparciu o podpisy MLSAG Umożliwia to grupie m uczestnikoacutew zbudowanie multisignature takiego że t uczestnikoacutew z liczby z m musi złożyć podpis aby był on uznany za ważny dodatkowo jest on dwuznaczny w odniesieniu do sygnatariusza klucze m są uczestnikami mieszczącymi się w ogoacutelnej liczbie n kluczy

Liczba n uczestnikoacutew w multisignature stanowi wspoacutelny sekret xe oraz klucz publiczny Pe ktoacutere mają wspoacutelne obrazy kluczy multisig

Ij = xeH(PejPj)

z Pj ndash publicznym kluczem uczestnika Każdy uczestnik multisignature dokonuje wyboru dodatkowych kluczy publicznych n -

m w blockchainie oraz tworzy podpis MLSAG za pomocą pierwszego rzędu wszystkich kluczy n a drugi rząd ma dla każdego wpisu (elementu) klucz wspoacutelny Pe

Każdy sygnatariusz multisignature podaje początkowe Ij j = 1 hellip m w celu umożliwienia zaakceptowania klucza po przekazaniu podpisoacutew weryfikujących t w blockchainie z ktoacuterych każdy odpowiada jednemu obrazowi klucza Ij

Rozszerzony zapis ring-multisignature jest w fazie opracowania

5 Zagregowane schematy identyfikacji Schnorra (Aggregate Schnorr Range Proofs)W części [11] poufne transakcja bez podpisu pierścieniowego wykorzystuje pewien typ podpisu pierścieniowego oparty na [1] nazywany podpisem pierścienia boromejskiego (Borromean ring signature) i pomaga zidentyfikować przekłamania w wartości zobowiązań w pewnym przedziale W niniejszym artykule postaram się nakreślić alternatywną metodę zainspirowaną przez [7] ktoacutera pozwala na uzyskanie tych samych oszczędności w zakresie przestrzeni ale za to opatrzona jest nieco mniej skomplikowanym protokołem bezpieczeństwa Motywacja do tego typu działania jest następująca przypuśćmy że dana transakcja ma dane wejściowe zobowiązań roacutewne

Cin = ainG + 10H

oraz zobowiązania wyjściowe

Cout 1 = aout1G + 5H Cout2 = aout2G + 5H

Scenariusz ten zachowuje ważność gdyż istnieje możliwość złożenia podpisu dla Cin ndash Cout1 ndash Cout2 = (ain ndash aout1 ndash aout2)G

Nie mniej jednak warto podkreślić że (bez range proofs) będzie istniała możliwość alternatywnego ustawienia zobowiązań wyjściowych

Cout1 = aout1G- H Cout2 = aout2G + 11H

Ponieważ -1 jest bardzo dużą liczbą stanowiącą modulo porządkujące grupę krzywej tym samym zostały utworzone darmowe pieniądze Zatem konieczne jest wykazanie że Couti są zobowiązaniami w odniesieniu do wartości ktoacutere są pozytywne (dodatnie) i mieszczą się w ograniczonym przedziale [0 2n] dla niektoacuterych wartości n Aby tego dokonać należy rozłożyć każdą wartość wyjściową na elementy binarne

co pozwala obliczyć zobowiązania do bj ∙ 2j w taki sposoacuteb że

Na koniec wykorzystując sekretny klucz bj można obliczyć podpis pierścieniowy na

dla wszystkich j oraz zapewnia dla weryfikatoroacutew (w tym przypadku goacuternikoacutew)Jeżeli chodzi o oszczędności miejsca można albo wykorzystać boromejski podpis pierścieniowy (podobnie jak w [11]) albo połączyć wszystkie proste podpisy pierścieniowe bądź utworzyć pewien typ zagregowanego podpisu pierścieniowego zdefiniowanego w następujący sposoacuteb

501 Generowanie zagregowanego nielinkowanego podpisu pierścieniowego Schnorra (Aggregate Schnorr Non-linkable Ring Signature) (ASNL)

Niech stanowi zbioacuter kluczy j = 1hellip z jako sekretnym kluczem

Dla każdego j niech Irsquo = i + 1 mod 2 ustawić skalar losowy aj i obliczyć

Ustawić gdzie Hs to kryptograficzna funkcja haszująca zwracająca skalar po dokonaniu wyboru losowego obliczyć

Określić i obliczyć

Zwroacutecić dla wszystkich j i s =

502 Weryfikacja zagregowanego nielinkowalnego podpisu pierścieniowego Schnorra (ASNL)Zacznijmy od dla j = 1hellip n oraz s

Dla wszystkich j obliczyć oraz

Jeżeli to otrzymamy 0 dla ważnego podpisuW przeciwnym razie otrzymamy wartość zwrotną -1

Teoremat 51 Zagregowany nielinkowany podpis pierścieniowy Schnorra nie może być sfałszowany przy założeniu logarytmu dyskretnego

Dowoacuted Przedstawiam szkic dowodu w przypadku n = 2 Przypadek ogoacutelny ma zbliżony charakter Przypuśćmy że adwersarz A jest w stanie sfałszować podpis ASNL na

Przy pomijalnym prawdopodobieństwie znając najwyżej jedną z (przypuśćmy że bez straty ogoacutelnego charakteru założenia że A zna ) Dla każdego danego fałszu

rozwiązuję roacutewnanie logarytmu dyskretnego o niepomijalnym prawdopodobieństwie Po zastosowaniu algorytmu weryfikacji niech Zatem prawdziwe musi być roacutewnanie

Przypuśćmy że oraz a a b są znane A wtedy

ponieważ jest określone protokołem weryfikacji musi być zatem prawdą że A zna klucz

prywatny

=Jest to w sprzeczności z założeniem logarytmu dyskretnego dla danej grupy

51 Reprezentacja kwotKwoty w protokole Ring CT można przedstawiać w sposoacuteb zbliżony do tego ktoacutery przedstawiony został w [11] z drobną modyfikacją w celu dopasowania do systemu Monero Coiny CryptoNote organizują nominały coinoacutew w bazie indeksoacutew w taki sposoacuteb aby mogły być ułożone w porządku występowania jako dane wejściowe dla podpisoacutew pierścieniowych Ponieważ wszystkie wartości coinoacutew w CryptoNote są reprezentowane w postaci 64-bitowych niepodpisanych liczb całkowitych możemy wykorzystać range proof na przestrzeni całego rejestru w celu zakodowania kwoty wyjściowej przekazywanej odbiorcy Na szczęście to także umożliwia wzajemne miksowanie danych wyjściowych zatem wymagany jest tylko jeden indeks danych wyjściowych w porządku rejestracji Przedział weryfikacji (range proof) wynosi ok 5 kilobajtoacutew Podpisy pierścieniowe dla danych wejściowych stają się bardziej odporne na analizę ponieważ anonimowość jest bardzo rozszerzonaPodczas gdy obszary weryfikacji (range proofs) są duże wykorzystywanie układu haszującego ktoacutery dodaje przedrostek do transakcji (zaroacutewno indeksoacutew wejściowych jak i wyjściowych) i przechowuje szeroki zakres range proof wraz z podpisami umożliwia oddzielnie uzyskanie ogromnych oszczędności przestrzeni podczas synchronizacji (syncing) do punktu weryfikacji lub działanie jako węzeł SPV Podobnie do elementoacutew bocznych łańcucha (Sidechains Elements) [12] będziemy przechowywać H(H(prefiks)||H(podpisy)) w drzewie Merkla Następnie węzły syncing do zaufanego punktu weryfikacji muszą jedynie pobrać przedrostek i dodać wartość haszującą do podpisoacutew skutecznie redukując szerokość wiązki Ponieważ prefiks transakcji wykorzystuje wariant dla danych wyjściowych ktoacutere wymienia w swoich podpisach pierścieniowych oraz środkach zapisanych do jednego klucza publicznego stanowi on miniaturowe poroacutewnanie do danych podpisoacutew pierścieniowych w danych wyjściowych oraz range proofs

Następnie podpisy pierścieniowe mogą nawet być przycięte z bazy danych przez niektoacutere węzły w celu uzyskania dalszych zyskoacutew przestrzeni przechowując zastępczo jedynie względnie mały zbioacuter UTXO

511 Przekazywanie informacji o kwotach OdbiorcyObecnie mając dowolną kwotę wyjściową b = b020 + b121 + ∙∙∙ bn2n nadawca oblicza nową prywatnąpubliczną parę kluczy oraz związane wymieniane sekrety ECDH ss oraz udostępnia następujące informacje w swojej transakcji

gdzie ai to losowo wybrane liczby dla j = 0 hellipn Dane Klucz publiczny ECDH oraz a + ss mod l gdzie a = a0 + hellip + an

Następnie odbiorca Oblicza udostępniany sekret ss oraz oblicza a na podstawie a + ss mod l Oblicza C = sumCi oblicza C ndash aG = bH oraz oblicza b poroacutewnując uzyskane wartości do

wszystkich bH w danym przedziale [0 2n] (W praktyce będzie to szybkie 500 kilobajtowe wyszukanie w n = 12 podobnie jak w poprzednim rozdziale Gdyby jednak wartość 232 została wybrana jako goacuterna wartość graniczna podobnie jak w [11] wyszukiwanie stałoby się dużym obliczeniowo wysiłkiem)

6 WnioskiProtokoacuteł pierścieniowych transakcji poufnych (Ring Confidential Transactions) to bardzo silnie zdecentralizowana kryptowaluta (tzn nie ma w niej żadnej uprzywilejowanej strony) ktoacutera posiada proste do udowodnienia wartości szacunkowe zabezpieczeń dotyczące ukrywania kwot transferoacutew ich źroacutedeł oraz odbiorcoacutew Dodatkowo generowanie coinoacutew w oparciu o protokoacuteł Ring Confidential Transactions nie wymaga obecności czynnika zaufanego i proces jego weryfikacji jest całkowicie bezpiecznyTych pięć czynnikoacutew jest niezbędnych w przypadku kryptowalut zbliżonych do środkoacutew gotoacutewkowych takich jak MoneroBibliografia1 Masayuki Abe Miyako Ohkubo and Koutarou Suzuki 1-out-of-n signatures from a variety of keys Advances in CryptologyAsiacrypt 2002 pages 415ndash432 20022 Adam Back Bitcoins with homomorphic value (validatable but encrypted)httpsbitcointalkorgindexphptopic=3057910 2013 [Online accessed 1-May-2015]3 Adam Back Podpis pierścieniowy efficiency httpsbitcointalkorgindexphptopic=972541msg10619684msg10619684 2015 [Online accessed 1-May-2015]4 Eli Ben Sasson Alessandro Chiesa Christina Garman Matthew Green Ian Miers Eran Tromer and Madars Virza Zerocash Decentralized anonymous payments from bitcoin In Security and Privacy (SP) 2014 IEEE Symposium on pages 459ndash474 IEEE 20145 Evan Duffield and Kyle Hagan Darkcoin Peertopeer cryptocurrency with anonymous blockchain transactions and an improved proofofwork system 20146 Eiichiro Fujisaki and Koutarou Suzuki Traceable podpis pierścieniowy In Public Key CryptographyndashPKC 2007 pages 181ndash200 Springer 20077 Javier Herranz Aggregate signatures httpwwwiiiacsices~jherranzpapersNijmegen_seminar_aggregatepdf oct 20058 Joseph K Liu Victor K Wei and Duncan S Wong Linkable spontaneous anonymous group signature for ad hoc groups In Information Security and Privacy pages 325ndash335 Springer 20049 Adam Mackenzie Surae Noether and Monero Core Team Improving obfuscation in the cryptonote protocol httpslabgetmoneroorgpubsMRL-0004pdf January 201510 Greg Maxwell Coinjoin Bitcoin privacy for the real world august 2013 Bitcoin Forum httpsbitcointalkorgindexphptopic=2792490 2013 [Online accessed 1-July-2015]11 Greg Maxwell Confidential Transactions httpspeoplexiphorg~gregconfidential_valuestxt 2015 [Online accessed 1-June-2015]12 Greg Maxwell Elements project httpsgithubcomShenNoetherMiniNero 201513 Satoshi Nakamoto Bitcoin A peer-to-peer electronic cash system Consulted 1(2012)28 200814 Shen Noether Mininero httpsgithubcomShenNoetherMiniNero 201515 Ronald L Rivest Adi Shamir and Yael Tauman How to leak a secret In Advances in CryptologyASIACRYPT 2001 pages 552ndash565 Springer 200116 Nicolas van Saberhagen Cryptonote v 2 0 HYPERLINK https cryptonote org whitepaper pdf 2013

Załącznik A Załącznik Security ProofsA1 Brak możliwości sfałszowania MLSAG

Obliczenia przebiegają analogicznie do [8 Teoremat 1] Niech H1 oraz H2 będą losowo wybranymi oracle a SO stanowią podpisy oracle zwracające ważne podpisy MLSAG Załoacuteżmy że istnieje probabilistyczny wielomianowy adwersarz czasowy (PPT) A ktoacutery posiada zdolność sfałszowania MLSAG z listy wektoroacutew kluczy L przy prawdopodobieństwie ktoacuterego nie można pominąć

Gdzie Q1 stanowi wielomianowy parametr bezpieczeństwa k oraz gdzie (m σ) nie stanowi jednego z podpisoacutew zwracanych przez SO Załoacuteżmy że A nie wysyła więcej niż qH + nqS

(gdzie n oznacza liczbę kluczy w L) zapytań dotyczących podpisoacutew oracle H1H2 oraz SO odpowiednio Podpisy oracle H1 oraz H2 uważa się za niezależne i losowe oraz spoacutejne z danymi zapytaniami powtarzającymi się Podpis oracle SO może składać zapytanie H1 oraz H2 Mając wartość A wykaże że istnieje możliwość utworzenia adwersarza M w PPT ktoacutery będzie wykorzystywać A w celu znalezienia logarytmu dyskretnego jednego z kluczy w L

Jeżeli L stanowi zbioacuter kluczy wektoroacutew z ktoacuterych każdy będzie mieć wielkość r (tzn z kluczami publicznymi y1 hellip yr ) to wygenerowany fałszywy podpis

Wygenerowany przez A musi spełniać warunek

Gdzie i są obliczone w ramach mod n oraz są zdefiniowane zgodnie z Rozdziałem 22 Nowy adwersarz M może wykorzystać A w celu sfałszowania podpisoacutew wielomianową liczbę razy i zapisze każdy skrypt Turinga T niezależnie czy sfałszowanie było skuteczne czy nie

Lemma A1 [8 Lemma 1] Niech M wywołuje A w celu uzyskania transkrypcji T Jeżeli T jest skuteczne to M powraca do T do nagłoacutewka H i następnie re-symuluje A w celu uzyskania transkrypcji Trsquo Jeżeli Pr (T okaże się skuteczne) = ϵ to Pr (Trsquo jest skuteczne) = ϵ

Dowoacuted wynika wprost z przywołanego teorematu

Teoremat A2 Prawdopodobieństwo że adwersarz A sfałszuje podpis MLSAG można pominąć przy założeniu logarytmu dyskretnego

Dowoacuted Do przeprowadzenia dowodu będę stosować notację przedstawioną powyżej Podobnie jak w przypadku [8 teoremat 1] ponieważ prawdopodobieństwo odgadnięcia danych wyjściowych z losowego oracle jest znikome w związku z tym dla każdego skutecznego oszustwa A wprowadza transkrypcję uzupełniającą T a zatem mamy mT zapytań w przypadku zapytań do H1 odpowiadających liczbie n zapytań wykorzystywanych w celu weryfikacji podpisu W związku z tym niech Xi1 hellip Xim oznacza zapytania wykorzystywane w procesie weryfikacji fałszu ith oraz niech π oznacza indeks odpowiadający ostatniemu zapytaniu weryfikacyjnego dla danego oszustwa

(Intuicyjnie π odpowiada temu co może stanowić indeks sekretny fałszywego podpisu ponieważ odpowiada on ostatniemu wezwaniu ostatniemu wywołaniu losowego oracle dla danego odpisu)Proacuteba sfałszowania σ podjęta przez A stanowi fałsz (l π) jeżeli i1 = l oraz π jest zgodne z powyższym (zatem fałsz odpowiada zapytaniom l do l + π) Z założenia istnieje para (l π) taka że prawdopodobieństwo związanej transkrypcji T daje skutecznie wygenerowany fałszywy klucz ϵlπ (T) spełnia warunek

1

Teraz przeglądając T do wartości przed zapytaniem l-tym a następnie podejmując proacutebę sfałszowania za pomocą tego samego zbioru kluczy (oraz dopuszczając aby H1 obliczyło nowe rzuty monetami dla wszystkich kolejnych zapytań) z Lemmy A1 wynika że prawdopodobieństwo że Trsquo jest także skuteczne spełnia warunki

_Dlatego prawdopodobieństwo że zaroacutewno T jak i Trsquo odpowiadają weryfikacjom fałszywym σ i σ1 nie może zostać pominięte

Ponieważ nowe rzuty monetami zostały obliczone na podstawie danych wyjściowych losowych oracle H1 oznacza to że przy dużym prawdopodobieństwie istnieje wartość j taka

że oraz W związku z tym możemy rozwiązać klucz prywatny z indeksem π

ktoacutery jest sprzeczny z założeniami logarytmu dyskretnego

A2 Linkowalność MLSAG Teoremat A3 Linkowalność obrazu klucza (Key-Image Linkability) Prawdopodobieństwo że adwersarz a w PPT może utworzyć dwa podpisy weryfikujące (niepołączone w danym

ustawieniu σ σrsquo podpisane w odniesieniu do wektoroacutew kluczy oraz odpowiednio w taki

sposoacuteb że będzie istnieć klucz publiczny i w obu oraz może być pominięte

Dowoacuted Przypuśćmy że w przeciwieństwie do tego co zostało wcześniej powiedziane A utworzył dwa podpisy weryfikujące σ oraz σrsquo o oba są podpisami w odniesieniu do kluczowych wektoroacutew

oraz odpowiednio w taki sposoacuteb że istnieje klucz publiczny y zaroacutewno w jak i

Niech y występuje jako element j należący do a jrsquo jako element należący do rsquo Z teorematu A2 wynika z dużym prawdopodobieństwem że istnieją indeksy π oraz πrsquo dla kluczy publicznych σ oraz σrsquo odpowiednio takie że

oraz

z

oraz

Jeżeli uznamy że x oznacza klucz prywatny y y = xG to po rozwiązaniu powyższego dla Ij

oraz Ij0rsquo mamy następujące roacutewnania oraz podobnie Ijrsquo = xH (y) Tym samym dwa podpisy obejmują Ij = Ijrsquo i w związku z tym ponieważ zduplikowane obrazy kluczy są odrzucone jeden z nich nie może być wykorzystany do weryfikacji

A3 Anonimowość MLSAG W celu udowodnienia anonimowości powyższego protokołu w losowym modelu oracle przyjmijmy że H1 H2 to losowe oracle modelujące dyskretne funkcje haszujące Niech A to adwersarz anonimowości Buduję adwersarza M względem założenia problemu decyzyjnego Diffie Helmana (DDH) zgodnie z poniższym Założenie DDH stwierdza że mając daną krotność (G aG bG ϒG) prawdopodobieństwo ustalenia czy G = abG jest znikome

Teoremat A4 Protokoacuteł pierścieniowy CT jest dwuznaczny w odniesieniu do sygnatariusza przy założeniu problemu decyzyjnego Diffie-HelmanaDowoacuted (zbliżony do dowodu [8 Teoremat 2]) Załoacuteżmy że problem decyzyjny Diffie-Helmana jest trudny w cyklicznej grupie generowanej przez G i załoacuteżmy że istnieje adwersarz A w czasie PPT względem dwuznaczności sygnatariusza Tym samym mając listę L n wektoroacutew

kluczy publicznych o długości m oraz zbioacuter prywatnych kluczy t ważny podpis σ na L podpisany przez użytkownika w odniesieniu do wektora klucza y taki że

odpowiedni wektor klucza prywatnego wynosi spełnia to A może zdeterminować π z prawdopodobieństwem

Dla wybranych wielomianoacutew Q(k) Buduję adwersarza PPT M ktoacutery wykorzystuje krotność danych wejściowych (G aG bG ciG) gdzie I ϵ 0 1 jest losowo wybrany (a nie znany M a priori) c1 = ab oraz c0 jest losowym skalarem a dane wyjściowe i mają prawdopodobieństwo

Dla niektoacuterych wielomianoacutew Q2 (k)Należy rozważyć algorytm SIMNIZKP (zbliżony to tego ktoacutery został zdefiniowany w [6]) ktoacutery jako skalary wejściowe wykorzystuje wektor x klucza prywatnego zbioacuter wektoroacutew kluczy

publicznych indeks π oraz wiadomość m i ktoacutery działa w sposoacuteb następujący1 Wygenerować skalary losowe s1 hellip sm oraz skalar losowy cπ lt- H2 Dla j indeksującego określić

A dla pozostałych j

3 Obliczyć losowe dane wyjściowe na podstawie losowego oracle

4 Dla każdego i roboczego mod m obliczyć

Należy podkreślić że w ostatnim punkcie kiedy i = π - 1 to ci+1 jest już określone w celu utrzymania spoacutejności z losowymi danymi wyjściowymi oracleNależy podkreślić że niezależnie od tego czy jest rzeczywistym kluczem prywatnym odpowiadającym ze względu na to że spoacutejność jest zachowywana przez losowe wartości oracle w kolejnych wezwaniach powyższy podpis jest weryfikowany Jeżeli x jest rzeczywiście wektorem klucza prywatnego y to nie ma roacuteżnicy pomiędzy SIMNIZKP oraz rzeczywistym podpisemNa koniec mając krotność (G aG bG ciG) gdzie a b są losowo wybrany skalarami a c1 = ab c0 elementem losowym i ϵ 0 1 M zachodzi w poniższych krokach i pozwala rozwiązać problem decyzyjny Diffie Helmana za pomocą niepomijalnego prawdopodobieństwa M wychwytuje losowe ϒ lt-H z losowej wartości oracle oraz pobiera parę wektoroacutew klucza prywatnego publicznego (x y) a następnie oblicza s jako a = s + ϒx Teraz M wykonuje

SIMNIZKP za pomocą dowolnie wybranych wektoroacutew kluczy w taki sposoacuteb że w danej wiadomości m oraz Jeżeli prawdziwe jest że i = 1 to c = ab oraz logGaG = logbGcG = a

z uwagi na to że zakłada się iż A jest w stanie znaleźć π z prawdopodobieństwem ktoacuterego nie można pominąć to istnieje niepomijalne prawdopodobieństwo frac12 że A zwroacuteci 1 (i wtedy M zwroacuteci 1) Jeżeli i = 0 to A zwraca 1 wyłącznie z prawdopodobieństwem frac12 a zatem dla niektoacuterych niepomijanych prawdopodobieństw powyżej 1`2 M zwraca tę samą wartość co A i tym samym rozwiązuje problem decyzyjny Diffie-Helmana dla losowo wybranych skalaroacutew bez pomijalnego prawdopodobieństwa powyżej 12 co stanowi sprzeczność

Załącznik B Kod demo Ring CT W repozytorium w [14] zbudowałem prostą demonstrację protokołu poufnych transakcji pierścieniowych (Ring Confidential Transactions) wykorzystujących podpisy MLSAG w części 2 oraz podpisy ASNL w części 5

H_ct = RingCTgetHForCT()print(H H_ct)sr Pr = PaperWalletskpkGen() receivers private publicse pe ss = ecdhecdhgen(Pr) compute shared secret ssdigits = 14 in practice it will be 14print(inputs)Cia L1a s2a sa ska = RingCTgenRangeProof(10000 digits)print(outputs)Cib L1b s2b sb skb = RingCTgenRangeProof(7000 digits)Cic L1c s2c sc skc = RingCTgenRangeProof(3000 digits)print(verifying range proofs of outputs)RingCTverRangeProof(Cib L1b s2b sb)RingCTverRangeProof(Cic L1c s2c sc)x P1 = PaperWalletskpkGen()P2 = PaperWalletpkGen()C2 = PaperWalletpkGen()some random commitment grabbed from the blockchainind = 0Ca = RingCTsumCi(Cia)Cb = RingCTsumCi(Cib)Cc = RingCTsumCi(Cic)sk = [x MiniNerosc_sub_keys(ska MiniNerosc_add_keys(skb skc))]

pk = [[P1 P2] [MiniNerosubKeys(Ca MiniNeroaddKeys(Cb Cc)) MiniNerosubKeys(C2 MiniNeroaddKeys(Cb Cc)) ] ]II cc ssVal = MLSAGMLSAG_Sign(pk sk ind)print(Sig verified MLSAGMLSAG_Ver(pk II cc ssVal) )print(Finding received amount corresponding to Cib)RingCTComputeReceivedAmount(pe sr MiniNeroaddScalars(ss skb) Cib)print(Finding received amount corresponding to Cic)RingCTComputeReceivedAmount(pe sr MiniNeroaddScalars(ss skc) Cic)

Przykład transakcji z danymi wejściowymi 10 000 oraz wyjściowymi 3 000 i 7 000(rsquoHrsquo rsquo61fe7f0f5a607a33427d01dd1fded5ffa03fae2e9df9ebccf2e0a2f5bd77a204rsquo)inputs(rsquob b in binaryrsquo 10000 [0 0 0 0 1 0 0 0 1 1 1 0 0 1])Generating Aggregate Schnorr Non-linkable Podpis pierścieniowy outputs(rsquob b in binaryrsquo 7000 [0 0 0 1 1 0 1 0 1 1 0 1 1 0])Generating Aggregate Schnorr Non-linkable Podpis pierścieniowy (rsquob b in binaryrsquo 3000 [0 0 0 1 1 1 0 1 1 1 0 1 0 0])Generating Aggregate Schnorr Non-linkable Podpis pierścieniowy verifying range proofs of outputsVerifying Aggregate Schnorr Non-linkable Podpis pierścieniowy VerifiedVerifying Aggregate Schnorr Non-linkable Podpis pierścieniowy Verified(rsquoGenerating MLSAG sig of dimensions rsquo 2 rsquox rsquo 2)(rsquoverifying MLSAG sig of dimensions rsquo 2 rsquox rsquo 2)(rsquocrsquo[rsquo80a3cfd06dd2862307cd75c2a1566f20cd743dbb0b9feb22d79dcbecb9023f42rsquorsquoa9b7342ba7bf2f102505ca19dab734fde638916c0a29f5b30e49833ab51393earsquorsquo80a3cfd06dd2862307cd75c2a1566f20cd743dbb0b9feb22d79dcbecb9023f42rsquo])(rsquosig verifiesrsquo True)(rsquoSig verifiedrsquo True)Finding received amount corresponding to Cib(rsquoreceived rsquo 7000c Monero Research Lab Page 20 of 20rsquoa488ec68732fb551841c2c6dcc7ffac895d98ec7e9378275ed20ea12805fc18ersquo)Finding received amount corresponding to Cic(rsquoreceived rsquo3000rsquo1b46626858e130a0f3884c74c9fdeabc4d812c519103ea16a35a3f82a3d0ed6drsquo)

21 Podpisy LWW a podpisy FS Podpisy pierścieniowe wykorzystywane w Monero oraz oryginalny protokoacuteł CryptoNote są pochodnymi podpisoacutew pierścieniowych możliwych do wyśledzenia z [6] Podpisy pierścieniowe w ramach CryptoNote [16] zawierają ldquoobraz kluczardquo co oznacza że podpisujący może podpisać jeden pierścień w blockchainie używając danego klucza publicznego oraz pary kluczy prywatnych albo ich transakcja zostanie oznaczona jako nieważna W związku z tym wykorzystywane są klucze jednorazowe w protokole CryptoNote ktoacutere następnie podnoszą poziom anonimowościW [3] Adam Back podkreśla że podpisy w ramach Linkable Spontaneous Anonymous Group (LSAG) w [8] mogą być modyfikowane w taki sposoacuteb aby utworzyć bardziej wydajny linkowany podpis pierścieniowy dający ten sam efekt jaki uzyskuje się w przypadku podpisu pierścieniowego z [6] Modyfikacja ta pozwala obniżyć koszty przechowywania w blockchainie zasadniczo o połowęNa początek przytoczę ndash niemal dosłownie ndash modyfikacje opisane w [3]Keygen [Generowanie klucza] Znajdź pewną liczbę kluczy publicznych Pi i = 0 1 hellip n oraz sekretny indeks j spełniający warunek xG = Pj gdzie G stanowi punkt bazowy ed25519 a x to klucz wydatkowany sygnatariuszy Niech I = xHp (Pj) gdzie Hp jest funkcją haszującą zwracającą punkt [2] Niech m stanowi daną wiadomośćPODPIS Niech α si i ne j i ϵ 1 hellip n będą wartościami losowymi w Zq (pole bazowe ed25519)ObliczLj = αGRj = αHp (Pj)cj+1 = h (m Lj Rj)gdzie h jest funkcją haszującą zwracającą wartość w Zq Teraz dokonując kolejnych obliczeń j modulo n należy zdefiniowaćLj+1 = sj+1G + cj+1Pj+1Rj+1 = sj+1Hp (Pj+1) + cj+1 _ Icj+2 = h (m Lj+1 Rj+1)hellip

Lj-1 = sj-1G + cj-1Pj-1Rj-1 = sj-1Hp (Pj-1) + cj-1∙ Icj = h (mLj-1 Rj-1)

[2] W praktyce Hp(P) = Keccak(P) ∙ G gdzie G jest punktem bazowym ed25519 chociaż należy zauważyć że w odniesieniu do układu zobowiązań będę wykorzystywać toPoint(Keccak(P)) haszujący kolejno aż do zwrotu wielokrotności punktu bazowego przez Keccak(P)

po to aby umożliwić definicję c1 hellip cnNiech sj = α - cj ∙ xj mod l (l stanowi porządek krzywej ed25519) stąd α = sj + cjxj mod l w taki sposoacuteb że Lj = _G = sjG + cjxjG = sjG + cjPjRj = _Hp (Pj) = sjHp (Pj) + cjIorazcj+1 = h (m Lj Rj)stąd mając jednostkową wartość ci wartości Pj obraz klucza I oraz wszystkie wartości sj pozostałe ck k 6= i mogą być odkryte przez obserwatora Podpis w związku ma postaćα = (I c1 s1 hellip sn)reprezentując oszczędności w zakresie zajmowanego miejsca w stosunku do [16 44] gdzie podpis pierścieniowy moacutegłby zamiennie wyglądać w następujący sposoacutebα = (I c1 hellip cn s1 hellip sn)Weryfikacja przebiega w następujący sposoacuteb Obserwator oblicza wartości Li Ri oraz ci dla wszystkich i oraz weryfikuje czy cn+1 = c1 Następnie weryfikator sprawdza czy

ci+1 = h (m Li Ri)dla wszystkich i mod nLINK Podpisy z duplikatami obrazoacutew kluczy I są odrzucaneNależy podkreślić że protokoły proofs of unforgeability anonimowości oraz łączenia obowiązują i stanowią jedynie nieznaczne modyfikacje protokołoacutew proof o ktoacuterych mowa w [8] Przedstawię nieco bardziej uogoacutelnioną wersję tych protokołoacutew dla MLSAG

22 Opis MLSAG W odniesieniu do protokołu Ring CT ktoacuterego opis znajduje się w części 4 wymagam uogoacutelnienia podpisoacutew Back LSAG opisanych w poprzednim rozdziale co umożliwia stosowanie wektoroacutew kluczy (Definicja 21) zamiast po prostu kluczyPrzypuśćmy że każda osoba składająca podpis pod (uogoacutelnionym) pierścieniem

zawierającym n członkoacutew (uczestnikoacutew) ma dokładnie m kluczy Celem podpisu pierścieniowego MLSAG jest realizacja następujących celoacutew

udowodnienie że jeden z podpisujących n zna sekretny klucz właściwy dla całego wektora klucza

Zapewnienie że jeżeli podpisujący wykorzystuje jeden z kluczy podpisoacutew m w innym podpisie MLSAG to dwa pierścienie są połączone a drugi taki podpis MLSAG (zlecony przez blockchain Monero) zostanie odrzucony

Algorytm działa w sposoacuteb następujący niech m stanowi wiadomość Niech π jest sekretnym indeksem odpowiadającym sygnatariuszowi uogoacutelnionego pierścienia Dla j = 1 hellip m niech

oraz dla j = 1 hellip m i = 1 hellip π hellipn (gdzie π oznacza ominięcie indeksu π) niech stanowi jeden z losowych skalaroacutew (elementoacutew Zq) Teraz w sposoacuteb analogiczny do części 21 należy zdefiniować

dla skalaroacutew losowych αj oraz j = 1 hellip m A teraz ponownie analogicznie do części 21 należy określić

i powtoacuterzyć czynność zwiększając przyrostowo i modulo n aż do momentu uzyskania następującej postaci

Na koniec dla każdego rozwiązać mod l Podpis jest następnie przekazywany jako zatem kompleksowość wynosi O (m(n + 1)) Proces weryfikacji przebiega poprzez regenerację wszystkich zaczynając od i = 1 podobnie jak to miało miejsce w części 21 (ktoacutera

stanowi przypadek szczegoacutelny w ktoacuterym m = 1) i przeprowadzając sprawdzenie funkcji haszującej cn+1 = c1 Jeżeli wartości te są wykorzystywane w ustawieniu blockchainowym takim jak Monero podpisy składane za pomocą obrazoacutew kluczy Ij ktoacutere już się pojawiły są następnie odrzucane Można to w bardzo łatwy sposoacuteb wykazać stosując metodę zbliżoną do [8] że

Prawdopodobieństwo że sygnatariusz generujący ważny podpis bez znajomości wszystkich prywatnych kluczy ldquomrdquo należących do ich wektora kluczy dla indeksu π może być pominięty

Prawdopodobieństwo że sygnatariusz nie podpisze żadnego klucza z indeksu π może zostać pominięte (Innymi słowy wszystkie obrazy kluczy stanowiące część podpisu muszą pochodzić z indeksu π)

Jeżeli sygnatariusz podpisuje dwa pierścienie wykorzystując co najmniej jeden z tożsamych kluczy publicznych to następuje skojarzenie (połączenie) dwoacutech pierścieni

Szersze omoacutewienie tych elementoacutew znajduje się w dalszej części materiału dotyczącej zabezpieczeń (security proofs)

23 Model zabezpieczeń MLSAGMLSAG spełnia trzy niżej wymienione właściwości niefałszowalność (Unforgeability) linkowalność (Linkability) oraz Dwuznaczność Sygnatariusza (Signer Ambiguity) ktoacutere są bardzo zbliżone do definicji podanej w [8]

Definicja 22 Niefałszowalność (Unforgeability) System podpisoacutew MLSAG jest niemożliwy do sfałszowania jeżeli dla danego algorytmu A wielomianowego czasu probabilistycznego (PPT) z podpisem oracle SO generującego ważne podpisy oraz dla danej listy wektoroacutew kluczy publicznych n wybranej przez A A może generować przy pomijalnym prawdopodobieństwie ważny podpis w sytuacji gdy A nie zna jednego z odpowiednich wektoroacutew kluczy prywatnych

Uwaga 23 W poniższej definicji należy zauważyć że umieściłem funkcję odrzucania duplikujących się obrazoacutew kluczy jako części kryterioacutew weryfikacji dla MLSAG co przyczynia się do zbudowania nieco zmodyfikowanej definicji linkowalności (Linkability) w stosunku do tej ktoacutera została podana w [8]

Definicja 24 Linkowalność (Linkability) Niech L stanowi zbioacuter wszystkich kluczy publicznych w danym ustawieniu (np w danym łańcuchu blokowym - blockchainie) System składania podpisoacutew MLSAG w L jest połączony z obrazami kluczy jeżeli prawdopodobieństwo że

adwersarz A utworzy w PPT dwa podpisy σ σ1 podpisane w odniesieniu do wektoroacutew kluczy

oraz 1 z ktoacuterych każdy będzie zawierać ten sam klucz publiczny yi = yirsquo W L oraz każdy będzie weryfikowany bez oznaczenia jako duplikat jest pomijalne

Definicja 25 Dwuznaczność sygnatariusza (Signer Ambiguity) System składania podpisoacutew MLSAG uważa się za niejednoznacznie identyfikujący sygnatariusza jeżeli mamy dany podpis weryfikujący σ na wektorach kluczy oraz dowolny zbioacuter kluczy prywatnych t z ktoacuterych każdy będzie mieć oddzielny indeks oraz sekretny indeks w takiej sytuacji prawdopodobieństwo odgadnięcia klucza sekretnego wynosi mniej niż

Dowody potwierdzające powyższe definicje przedstawiono w Załączniku

3 Zarys historyczny transakcji poufnych31 Transakcje poufne w ramach system Bitcoin

W [11] Greg Maxwell opisuje transakcje poufne ktoacutere są pewną metodą przekazywania transakcji w systemie Bitcoin przy jednoczesnym maskowaniu kwot Podstawową kwestią jest stosowanie schematu zobowiązań Pedersena metoda ta jest doskonale opisana w cytowanym materiale źroacutedłowym W niniejszym opracowaniu wprowadzam drobną modyfikację do mechaniki Transakcji Poufnych polegającą na wybieraniu zamiast zobowiązań ktoacuterych suma wynosi zero opcji złożenia podpisu pod zobowiązaniem w celu wykazania że klucz prywatny jest mi znany Schemat ten jest opisany szczegoacutełowo w kolejnym rozdziale

32 Modyfikacja pod kątem podpisoacutew pierścieniowych Niech G stanowi punkt bazowy ed25519 Niech [3]

H = toPoint (cn_fast_hasz (G))

Należy podkreślić że nie każda wartość haszująca pozwala obliczyć punkt w ramach grupy punktu bazowego (tzn dla pewnej niewiadomej) (co jest sprzeczne z tym co dzieje się w secp256k1 krzywej wykorzystywanej w systemie Bitcoin) Nie mniej jednak wydaje się że wyboacuter punktu bazowego jako takiego (wcześniej wykorzystywałem H(123456G) sprawdza się co z resztą wydawało mi się bardziej bezpieczne przy czym punkt bazowy jest z pewnością bardziej naturalnym wyborem) Wyboacuter H = ϒG dla pewnej niewiadomej jest konieczny po to aby pełna matematyka zwykłych krzywych eliptycznych zachowała swoją ważność

[3] H = MiniNerogetHForCT() w kontekście kodu w [14]

Przy założeniu logarytmoacutew dyskretnych w ed25519 prawdopodobieństwo że adwersarz odkryje ϒ jest pomijalne Należy zdefiniować C (a x) = xG+aH zobowiązanie wartości a z maską x Należy podkreślić że tak długo jak wartość logGH nie jest znana oraz jeżeli σ ne 0 to logGC (a x) pozostaje wartością nieznaną Z drugiej strony jeżeli a = 0 to logGC (a x) = x a zatem istnieje możliwość złożenia podpisu za pomocą pary kluczy sk-pk (xC (0 x)) W [11] istnieją dane wejściowe I wyjściowe zobowiązań a sieć sprawdza czy

sumdane wejściowe = sumdane wyjściowe

Nie mniej jednak nie jest to wystarczające w przypadku systemu Monero ponieważ dana transakcja zawiera roacuteżne możliwe do realizacji dane wejściowe Pi i = 1 hellip n z ktoacuterych tylko jedna należa do nadawcy (patrz [16 44]) to jeżeli będziemy w stanie sprawdzić powyższe roacutewnanie to musi być możliwe aby sieć widziała ktoacutere Pi należy do nadawcy transakcji Nie jest to zjawisko pożądane ponieważ eliminuje anonimowość zbudowaną dzięki podpisowi pierścieniowemu W związku z tym zastępczo tworzy się zobowiązania dla danych wejściowych oraz wyjściowych zgodnie z poniższym (załoacuteżmy najpierw że istnieje tylko jeden zestaw danych wejściowych)

Cin = xcG + aHCout10485761 = y1G + b1HCout10485762 = y2G + b2H

W taki sposoacuteb że xc = y1+y2+z xc - y1 - y2 = z yi są wartościami maskującymi z gt 0 oraz a = b1+b2W tym przypadku xc stanowi szczegoacutelny prywatny klucz a ldquokwota kluczardquo znana jest tylko nadawcy oraz osobie do ktoacuterej coiny są wysyłane zatem musi być odmienna od normalnego klucza prywatnego W takim przypadku

= xcG + aH - y1G - b1H - y2G - b2H= zG

A zatem powyższe roacutewnanie staje się zobowiązaniem do 0 przy sk = z oraz pk = zG a nie rzeczywistym roacutewnaniem o sumie zerowej Należy podkreślić że z nie jest wyliczalne dla coinoacutew źroacutedłowych xc chyba że znana jest zaroacutewno wartość y1 jak i y2 nie mniej jednak nawet to można w prosty sposoacuteb złagodzić poprzez uwzględnienie dodatkowych adresoacutew zmiany (zwykły przypadek zakłada że drugie zobowiązanie z wartością y2 jako maską są wysyłane jako zmiana)Ponieważ podawanie informacji ktoacutere dane wejściowe należą do nadawcy nie jest pożądane podpis pierścieniowy zawierający wszystkie zobowiązania wejściowe Ci i = 1 hellip s hellip n (gdzie s stanowi sekretny indeks zobowiązania nadawcy) dodaje się odpowiedni klucz publiczny (dzięki czemu zobowiązania oraz klucze publiczne są parowane (Ci Pi) ale tylko takie ktoacutere mogą być wspoacutelnie wydatkowane) oraz odejmuje sumCout

Jest to podpis pierścieniowy ktoacutery może być złożony ponieważ znamy jeden z prywatnych kluczy (a mianowicie z + xrsquo zawierający z jak wyżej oraz xrsquoG = Ps) Tak naprawdę ponieważ wiemy że dla każdego i zaroacutewno klucze prywatne dla Pi jak i klucze prywatne dla Pi + Ciin - sumjCjout możemy złożyć podpis zgodnie z treścią rozdziału 22 Szczegoacuteły tej procedury są opisane w Definicji 41

Zgodnie z [11] ważne jest udowodnienie że kwoty wyjściowe [4] b1 hellip bn wszystkie mieszczą się w szeregu wartości dodatnich np (0 216) Można to osiągnąć zasadniczo w taki sam sposoacuteb jak w [11] kwestia ta jest bardziej szczegoacutełowo opisana w części 5Na koniec warto zauważyć że w powyższej dyskusji nie wspomniałem o właściwości związanej dołączaniem tagoacutew ktoacutera jest wykorzystywana w Monero oraz Cryptonote w celu zapobiegania podwoacutejnemu wydatkowaniu środkoacutew Dołączanie tagoacutew w tym momencie będzie skutkiem łączenia powyższego omoacutewienia z podpisami MLSAG o ktoacuterych mowa w Definicji 41

4 Ring CT dla protokołu Monero 41 Opis protokołuDefinicja 41 (Tagowalny pierścień CT z mnogimi danymi wejściowymi oraz kluczami jednorazowymi)

Niech stanowi zbioacuter adresoacutew oraz kluczy jednorazowychzobowiązań ktoacuterym odpowiadają sekretne klucze xj j = 1 hellip m

Znaleźć zbiory q + 1 i = 1 hellip q + 1 ktoacutere nie są połączone tagami w sensie [ 6 strona 6]

Należy określić zestaw adresoacutew wyjściowych (Qi Ciout) takich że

stanowią zobowiązania o wartości zero Niech

hellip

stanowi uogoacutelniony pierścień w ktoacuterym chcemy złożyć swoacutej podpis Należy zauważyć że ostatnia kolumna to pierścień Ring-CT w rozumieniu rozdziału 4

Obliczyć podpis MLSAG sum na R

[4] Ponieważ zobowiązania wejściowe mogą być potencjalnie odziedziczone z poprzednich transakcji wystarczy rozważyć kwoty wyjściowe

W takim przypadku zgodnie z teorematem A2 nie może być sygnatariuszem żadnych dodatkowych niezlinkowanych podpisoacutew pierścieniowych w danym nadzbiorze P wszystkich takich par P = (PC) po podpisaniu sum

Uwaga 42 Złożoność przestrzeni powyższego protokołu Warto zauważyć że rozmiar podpisu sum na R zgodnie z definicją 41 jest w rzeczywistości mniejszy dla m gt 1 niż bieżący podpis pierścieniowy transakcji opartej na protokole CryptoNote [16] ktoacutera zawiera mnogie dane wejściowe Dzieje się tak dzięki wprowadzeniu zmian w rozmiarze w [8] do każdej kolumny Należy także podkreślić że prawdopodobnie nie jest konieczne umieszczanie obrazu klucza zobowiązania związanego z wyżej wymienionym podpisem Kolejne optymalizacje rozmiaru są możliwe i można je wykonać w podobny sposoacuteb

42 Konwersja widocznych denominacji na zobowiązaniaPonieważ Monero obecnie wykorzystuje blockchainowe widoczne skalary w celu stworzenia reprezentacji kwot ważne jest aby istniała możliwość (i sposoacuteb) konwersji z kwot widocznych na zobowiązania przy jednoczesnym zachowaniu anonimowości Tak naprawdę wcale nie jest to trudne Mając daną parę (P a) gdzie P jest kluczem publicznym a a stanowi kwotę może ona być wykorzystana jako dane wejściowe transakcji jako (P aH) i transakcja ta musi być zweryfikowana przez weryfikatora pod kątem kwoty wejściowej i jej przemnożenia przez punkt maskujący H oraz czy uzyskana wartość rzeczywiście wynosi aH Zatem jako pierwszy krok kwoty wejściowe nie zostaną ukryte ale ukryte zostaną dane wyjściowe transakcji oraz wszelkie niezbędne relacje o ktoacuterych mowa w rozdziale 4 pozostają ważne Należy podkreślić że range proof nie jest konieczny dla tych danych wejściowych

Uwaga 43 Oczywistą zaletą tej metody jest konwersja z kwot widocznych na zobowiązania oraz to że kwota coinoacutew wygenerowanych w procesie wydobycia jest weryfikowalna bez konieczności udziału elementu zaufanego Jest to przewaga protokołu Ring CT nad systemami płatniczymi takimi jak [4] ktoacutere obejmują fazę ustawień strony zaufanej

43 Opłaty transakcyjnePonieważ system Monero jest silnie zdecentralizowany (tzn proof of work) konieczne jest wynagradzanie goacuternikoacutew i dokonywanie opłat za każdą transakcję Pomaga to podnieść bezpieczeństwo sieci i zapobiegać rozdęcia blockchainu Opłaty te muszą być realizowane w postaci niezamaskowanej tzn Jako bH a nie xG + bH oraz w odniesieniu do pewnej standardowej kwoty b w taki sposoacuteb że goacuternik będzie moacutegł zweryfikować że b ∙ H = bH i tym samym że jest dość środkoacutew na opłatę transakcyjną przy jednoczesnym zachowaniu roacutewnań związanych z H w taki sposoacuteb że zostaną zachowane niezbędne relacje o ktoacuterych mowa w Rozdziale 4

44 Ring MultisignatureWarto zauważyć że prosta wersja t z m z n ring-multisignature [mnogich podpisoacutew pierścieniowych] może być zrealizowana w oparciu o podpisy MLSAG Umożliwia to grupie m uczestnikoacutew zbudowanie multisignature takiego że t uczestnikoacutew z liczby z m musi złożyć podpis aby był on uznany za ważny dodatkowo jest on dwuznaczny w odniesieniu do sygnatariusza klucze m są uczestnikami mieszczącymi się w ogoacutelnej liczbie n kluczy

Liczba n uczestnikoacutew w multisignature stanowi wspoacutelny sekret xe oraz klucz publiczny Pe ktoacutere mają wspoacutelne obrazy kluczy multisig

Ij = xeH(PejPj)

z Pj ndash publicznym kluczem uczestnika Każdy uczestnik multisignature dokonuje wyboru dodatkowych kluczy publicznych n -

m w blockchainie oraz tworzy podpis MLSAG za pomocą pierwszego rzędu wszystkich kluczy n a drugi rząd ma dla każdego wpisu (elementu) klucz wspoacutelny Pe

Każdy sygnatariusz multisignature podaje początkowe Ij j = 1 hellip m w celu umożliwienia zaakceptowania klucza po przekazaniu podpisoacutew weryfikujących t w blockchainie z ktoacuterych każdy odpowiada jednemu obrazowi klucza Ij

Rozszerzony zapis ring-multisignature jest w fazie opracowania

5 Zagregowane schematy identyfikacji Schnorra (Aggregate Schnorr Range Proofs)W części [11] poufne transakcja bez podpisu pierścieniowego wykorzystuje pewien typ podpisu pierścieniowego oparty na [1] nazywany podpisem pierścienia boromejskiego (Borromean ring signature) i pomaga zidentyfikować przekłamania w wartości zobowiązań w pewnym przedziale W niniejszym artykule postaram się nakreślić alternatywną metodę zainspirowaną przez [7] ktoacutera pozwala na uzyskanie tych samych oszczędności w zakresie przestrzeni ale za to opatrzona jest nieco mniej skomplikowanym protokołem bezpieczeństwa Motywacja do tego typu działania jest następująca przypuśćmy że dana transakcja ma dane wejściowe zobowiązań roacutewne

Cin = ainG + 10H

oraz zobowiązania wyjściowe

Cout 1 = aout1G + 5H Cout2 = aout2G + 5H

Scenariusz ten zachowuje ważność gdyż istnieje możliwość złożenia podpisu dla Cin ndash Cout1 ndash Cout2 = (ain ndash aout1 ndash aout2)G

Nie mniej jednak warto podkreślić że (bez range proofs) będzie istniała możliwość alternatywnego ustawienia zobowiązań wyjściowych

Cout1 = aout1G- H Cout2 = aout2G + 11H

Ponieważ -1 jest bardzo dużą liczbą stanowiącą modulo porządkujące grupę krzywej tym samym zostały utworzone darmowe pieniądze Zatem konieczne jest wykazanie że Couti są zobowiązaniami w odniesieniu do wartości ktoacutere są pozytywne (dodatnie) i mieszczą się w ograniczonym przedziale [0 2n] dla niektoacuterych wartości n Aby tego dokonać należy rozłożyć każdą wartość wyjściową na elementy binarne

co pozwala obliczyć zobowiązania do bj ∙ 2j w taki sposoacuteb że

Na koniec wykorzystując sekretny klucz bj można obliczyć podpis pierścieniowy na

dla wszystkich j oraz zapewnia dla weryfikatoroacutew (w tym przypadku goacuternikoacutew)Jeżeli chodzi o oszczędności miejsca można albo wykorzystać boromejski podpis pierścieniowy (podobnie jak w [11]) albo połączyć wszystkie proste podpisy pierścieniowe bądź utworzyć pewien typ zagregowanego podpisu pierścieniowego zdefiniowanego w następujący sposoacuteb

501 Generowanie zagregowanego nielinkowanego podpisu pierścieniowego Schnorra (Aggregate Schnorr Non-linkable Ring Signature) (ASNL)

Niech stanowi zbioacuter kluczy j = 1hellip z jako sekretnym kluczem

Dla każdego j niech Irsquo = i + 1 mod 2 ustawić skalar losowy aj i obliczyć

Ustawić gdzie Hs to kryptograficzna funkcja haszująca zwracająca skalar po dokonaniu wyboru losowego obliczyć

Określić i obliczyć

Zwroacutecić dla wszystkich j i s =

502 Weryfikacja zagregowanego nielinkowalnego podpisu pierścieniowego Schnorra (ASNL)Zacznijmy od dla j = 1hellip n oraz s

Dla wszystkich j obliczyć oraz

Jeżeli to otrzymamy 0 dla ważnego podpisuW przeciwnym razie otrzymamy wartość zwrotną -1

Teoremat 51 Zagregowany nielinkowany podpis pierścieniowy Schnorra nie może być sfałszowany przy założeniu logarytmu dyskretnego

Dowoacuted Przedstawiam szkic dowodu w przypadku n = 2 Przypadek ogoacutelny ma zbliżony charakter Przypuśćmy że adwersarz A jest w stanie sfałszować podpis ASNL na

Przy pomijalnym prawdopodobieństwie znając najwyżej jedną z (przypuśćmy że bez straty ogoacutelnego charakteru założenia że A zna ) Dla każdego danego fałszu

rozwiązuję roacutewnanie logarytmu dyskretnego o niepomijalnym prawdopodobieństwie Po zastosowaniu algorytmu weryfikacji niech Zatem prawdziwe musi być roacutewnanie

Przypuśćmy że oraz a a b są znane A wtedy

ponieważ jest określone protokołem weryfikacji musi być zatem prawdą że A zna klucz

prywatny

=Jest to w sprzeczności z założeniem logarytmu dyskretnego dla danej grupy

51 Reprezentacja kwotKwoty w protokole Ring CT można przedstawiać w sposoacuteb zbliżony do tego ktoacutery przedstawiony został w [11] z drobną modyfikacją w celu dopasowania do systemu Monero Coiny CryptoNote organizują nominały coinoacutew w bazie indeksoacutew w taki sposoacuteb aby mogły być ułożone w porządku występowania jako dane wejściowe dla podpisoacutew pierścieniowych Ponieważ wszystkie wartości coinoacutew w CryptoNote są reprezentowane w postaci 64-bitowych niepodpisanych liczb całkowitych możemy wykorzystać range proof na przestrzeni całego rejestru w celu zakodowania kwoty wyjściowej przekazywanej odbiorcy Na szczęście to także umożliwia wzajemne miksowanie danych wyjściowych zatem wymagany jest tylko jeden indeks danych wyjściowych w porządku rejestracji Przedział weryfikacji (range proof) wynosi ok 5 kilobajtoacutew Podpisy pierścieniowe dla danych wejściowych stają się bardziej odporne na analizę ponieważ anonimowość jest bardzo rozszerzonaPodczas gdy obszary weryfikacji (range proofs) są duże wykorzystywanie układu haszującego ktoacutery dodaje przedrostek do transakcji (zaroacutewno indeksoacutew wejściowych jak i wyjściowych) i przechowuje szeroki zakres range proof wraz z podpisami umożliwia oddzielnie uzyskanie ogromnych oszczędności przestrzeni podczas synchronizacji (syncing) do punktu weryfikacji lub działanie jako węzeł SPV Podobnie do elementoacutew bocznych łańcucha (Sidechains Elements) [12] będziemy przechowywać H(H(prefiks)||H(podpisy)) w drzewie Merkla Następnie węzły syncing do zaufanego punktu weryfikacji muszą jedynie pobrać przedrostek i dodać wartość haszującą do podpisoacutew skutecznie redukując szerokość wiązki Ponieważ prefiks transakcji wykorzystuje wariant dla danych wyjściowych ktoacutere wymienia w swoich podpisach pierścieniowych oraz środkach zapisanych do jednego klucza publicznego stanowi on miniaturowe poroacutewnanie do danych podpisoacutew pierścieniowych w danych wyjściowych oraz range proofs

Następnie podpisy pierścieniowe mogą nawet być przycięte z bazy danych przez niektoacutere węzły w celu uzyskania dalszych zyskoacutew przestrzeni przechowując zastępczo jedynie względnie mały zbioacuter UTXO

511 Przekazywanie informacji o kwotach OdbiorcyObecnie mając dowolną kwotę wyjściową b = b020 + b121 + ∙∙∙ bn2n nadawca oblicza nową prywatnąpubliczną parę kluczy oraz związane wymieniane sekrety ECDH ss oraz udostępnia następujące informacje w swojej transakcji

gdzie ai to losowo wybrane liczby dla j = 0 hellipn Dane Klucz publiczny ECDH oraz a + ss mod l gdzie a = a0 + hellip + an

Następnie odbiorca Oblicza udostępniany sekret ss oraz oblicza a na podstawie a + ss mod l Oblicza C = sumCi oblicza C ndash aG = bH oraz oblicza b poroacutewnując uzyskane wartości do

wszystkich bH w danym przedziale [0 2n] (W praktyce będzie to szybkie 500 kilobajtowe wyszukanie w n = 12 podobnie jak w poprzednim rozdziale Gdyby jednak wartość 232 została wybrana jako goacuterna wartość graniczna podobnie jak w [11] wyszukiwanie stałoby się dużym obliczeniowo wysiłkiem)

6 WnioskiProtokoacuteł pierścieniowych transakcji poufnych (Ring Confidential Transactions) to bardzo silnie zdecentralizowana kryptowaluta (tzn nie ma w niej żadnej uprzywilejowanej strony) ktoacutera posiada proste do udowodnienia wartości szacunkowe zabezpieczeń dotyczące ukrywania kwot transferoacutew ich źroacutedeł oraz odbiorcoacutew Dodatkowo generowanie coinoacutew w oparciu o protokoacuteł Ring Confidential Transactions nie wymaga obecności czynnika zaufanego i proces jego weryfikacji jest całkowicie bezpiecznyTych pięć czynnikoacutew jest niezbędnych w przypadku kryptowalut zbliżonych do środkoacutew gotoacutewkowych takich jak MoneroBibliografia1 Masayuki Abe Miyako Ohkubo and Koutarou Suzuki 1-out-of-n signatures from a variety of keys Advances in CryptologyAsiacrypt 2002 pages 415ndash432 20022 Adam Back Bitcoins with homomorphic value (validatable but encrypted)httpsbitcointalkorgindexphptopic=3057910 2013 [Online accessed 1-May-2015]3 Adam Back Podpis pierścieniowy efficiency httpsbitcointalkorgindexphptopic=972541msg10619684msg10619684 2015 [Online accessed 1-May-2015]4 Eli Ben Sasson Alessandro Chiesa Christina Garman Matthew Green Ian Miers Eran Tromer and Madars Virza Zerocash Decentralized anonymous payments from bitcoin In Security and Privacy (SP) 2014 IEEE Symposium on pages 459ndash474 IEEE 20145 Evan Duffield and Kyle Hagan Darkcoin Peertopeer cryptocurrency with anonymous blockchain transactions and an improved proofofwork system 20146 Eiichiro Fujisaki and Koutarou Suzuki Traceable podpis pierścieniowy In Public Key CryptographyndashPKC 2007 pages 181ndash200 Springer 20077 Javier Herranz Aggregate signatures httpwwwiiiacsices~jherranzpapersNijmegen_seminar_aggregatepdf oct 20058 Joseph K Liu Victor K Wei and Duncan S Wong Linkable spontaneous anonymous group signature for ad hoc groups In Information Security and Privacy pages 325ndash335 Springer 20049 Adam Mackenzie Surae Noether and Monero Core Team Improving obfuscation in the cryptonote protocol httpslabgetmoneroorgpubsMRL-0004pdf January 201510 Greg Maxwell Coinjoin Bitcoin privacy for the real world august 2013 Bitcoin Forum httpsbitcointalkorgindexphptopic=2792490 2013 [Online accessed 1-July-2015]11 Greg Maxwell Confidential Transactions httpspeoplexiphorg~gregconfidential_valuestxt 2015 [Online accessed 1-June-2015]12 Greg Maxwell Elements project httpsgithubcomShenNoetherMiniNero 201513 Satoshi Nakamoto Bitcoin A peer-to-peer electronic cash system Consulted 1(2012)28 200814 Shen Noether Mininero httpsgithubcomShenNoetherMiniNero 201515 Ronald L Rivest Adi Shamir and Yael Tauman How to leak a secret In Advances in CryptologyASIACRYPT 2001 pages 552ndash565 Springer 200116 Nicolas van Saberhagen Cryptonote v 2 0 HYPERLINK https cryptonote org whitepaper pdf 2013

Załącznik A Załącznik Security ProofsA1 Brak możliwości sfałszowania MLSAG

Obliczenia przebiegają analogicznie do [8 Teoremat 1] Niech H1 oraz H2 będą losowo wybranymi oracle a SO stanowią podpisy oracle zwracające ważne podpisy MLSAG Załoacuteżmy że istnieje probabilistyczny wielomianowy adwersarz czasowy (PPT) A ktoacutery posiada zdolność sfałszowania MLSAG z listy wektoroacutew kluczy L przy prawdopodobieństwie ktoacuterego nie można pominąć

Gdzie Q1 stanowi wielomianowy parametr bezpieczeństwa k oraz gdzie (m σ) nie stanowi jednego z podpisoacutew zwracanych przez SO Załoacuteżmy że A nie wysyła więcej niż qH + nqS

(gdzie n oznacza liczbę kluczy w L) zapytań dotyczących podpisoacutew oracle H1H2 oraz SO odpowiednio Podpisy oracle H1 oraz H2 uważa się za niezależne i losowe oraz spoacutejne z danymi zapytaniami powtarzającymi się Podpis oracle SO może składać zapytanie H1 oraz H2 Mając wartość A wykaże że istnieje możliwość utworzenia adwersarza M w PPT ktoacutery będzie wykorzystywać A w celu znalezienia logarytmu dyskretnego jednego z kluczy w L

Jeżeli L stanowi zbioacuter kluczy wektoroacutew z ktoacuterych każdy będzie mieć wielkość r (tzn z kluczami publicznymi y1 hellip yr ) to wygenerowany fałszywy podpis

Wygenerowany przez A musi spełniać warunek

Gdzie i są obliczone w ramach mod n oraz są zdefiniowane zgodnie z Rozdziałem 22 Nowy adwersarz M może wykorzystać A w celu sfałszowania podpisoacutew wielomianową liczbę razy i zapisze każdy skrypt Turinga T niezależnie czy sfałszowanie było skuteczne czy nie

Lemma A1 [8 Lemma 1] Niech M wywołuje A w celu uzyskania transkrypcji T Jeżeli T jest skuteczne to M powraca do T do nagłoacutewka H i następnie re-symuluje A w celu uzyskania transkrypcji Trsquo Jeżeli Pr (T okaże się skuteczne) = ϵ to Pr (Trsquo jest skuteczne) = ϵ

Dowoacuted wynika wprost z przywołanego teorematu

Teoremat A2 Prawdopodobieństwo że adwersarz A sfałszuje podpis MLSAG można pominąć przy założeniu logarytmu dyskretnego

Dowoacuted Do przeprowadzenia dowodu będę stosować notację przedstawioną powyżej Podobnie jak w przypadku [8 teoremat 1] ponieważ prawdopodobieństwo odgadnięcia danych wyjściowych z losowego oracle jest znikome w związku z tym dla każdego skutecznego oszustwa A wprowadza transkrypcję uzupełniającą T a zatem mamy mT zapytań w przypadku zapytań do H1 odpowiadających liczbie n zapytań wykorzystywanych w celu weryfikacji podpisu W związku z tym niech Xi1 hellip Xim oznacza zapytania wykorzystywane w procesie weryfikacji fałszu ith oraz niech π oznacza indeks odpowiadający ostatniemu zapytaniu weryfikacyjnego dla danego oszustwa

(Intuicyjnie π odpowiada temu co może stanowić indeks sekretny fałszywego podpisu ponieważ odpowiada on ostatniemu wezwaniu ostatniemu wywołaniu losowego oracle dla danego odpisu)Proacuteba sfałszowania σ podjęta przez A stanowi fałsz (l π) jeżeli i1 = l oraz π jest zgodne z powyższym (zatem fałsz odpowiada zapytaniom l do l + π) Z założenia istnieje para (l π) taka że prawdopodobieństwo związanej transkrypcji T daje skutecznie wygenerowany fałszywy klucz ϵlπ (T) spełnia warunek

1

Teraz przeglądając T do wartości przed zapytaniem l-tym a następnie podejmując proacutebę sfałszowania za pomocą tego samego zbioru kluczy (oraz dopuszczając aby H1 obliczyło nowe rzuty monetami dla wszystkich kolejnych zapytań) z Lemmy A1 wynika że prawdopodobieństwo że Trsquo jest także skuteczne spełnia warunki

_Dlatego prawdopodobieństwo że zaroacutewno T jak i Trsquo odpowiadają weryfikacjom fałszywym σ i σ1 nie może zostać pominięte

Ponieważ nowe rzuty monetami zostały obliczone na podstawie danych wyjściowych losowych oracle H1 oznacza to że przy dużym prawdopodobieństwie istnieje wartość j taka

że oraz W związku z tym możemy rozwiązać klucz prywatny z indeksem π

ktoacutery jest sprzeczny z założeniami logarytmu dyskretnego

A2 Linkowalność MLSAG Teoremat A3 Linkowalność obrazu klucza (Key-Image Linkability) Prawdopodobieństwo że adwersarz a w PPT może utworzyć dwa podpisy weryfikujące (niepołączone w danym

ustawieniu σ σrsquo podpisane w odniesieniu do wektoroacutew kluczy oraz odpowiednio w taki

sposoacuteb że będzie istnieć klucz publiczny i w obu oraz może być pominięte

Dowoacuted Przypuśćmy że w przeciwieństwie do tego co zostało wcześniej powiedziane A utworzył dwa podpisy weryfikujące σ oraz σrsquo o oba są podpisami w odniesieniu do kluczowych wektoroacutew

oraz odpowiednio w taki sposoacuteb że istnieje klucz publiczny y zaroacutewno w jak i

Niech y występuje jako element j należący do a jrsquo jako element należący do rsquo Z teorematu A2 wynika z dużym prawdopodobieństwem że istnieją indeksy π oraz πrsquo dla kluczy publicznych σ oraz σrsquo odpowiednio takie że

oraz

z

oraz

Jeżeli uznamy że x oznacza klucz prywatny y y = xG to po rozwiązaniu powyższego dla Ij

oraz Ij0rsquo mamy następujące roacutewnania oraz podobnie Ijrsquo = xH (y) Tym samym dwa podpisy obejmują Ij = Ijrsquo i w związku z tym ponieważ zduplikowane obrazy kluczy są odrzucone jeden z nich nie może być wykorzystany do weryfikacji

A3 Anonimowość MLSAG W celu udowodnienia anonimowości powyższego protokołu w losowym modelu oracle przyjmijmy że H1 H2 to losowe oracle modelujące dyskretne funkcje haszujące Niech A to adwersarz anonimowości Buduję adwersarza M względem założenia problemu decyzyjnego Diffie Helmana (DDH) zgodnie z poniższym Założenie DDH stwierdza że mając daną krotność (G aG bG ϒG) prawdopodobieństwo ustalenia czy G = abG jest znikome

Teoremat A4 Protokoacuteł pierścieniowy CT jest dwuznaczny w odniesieniu do sygnatariusza przy założeniu problemu decyzyjnego Diffie-HelmanaDowoacuted (zbliżony do dowodu [8 Teoremat 2]) Załoacuteżmy że problem decyzyjny Diffie-Helmana jest trudny w cyklicznej grupie generowanej przez G i załoacuteżmy że istnieje adwersarz A w czasie PPT względem dwuznaczności sygnatariusza Tym samym mając listę L n wektoroacutew

kluczy publicznych o długości m oraz zbioacuter prywatnych kluczy t ważny podpis σ na L podpisany przez użytkownika w odniesieniu do wektora klucza y taki że

odpowiedni wektor klucza prywatnego wynosi spełnia to A może zdeterminować π z prawdopodobieństwem

Dla wybranych wielomianoacutew Q(k) Buduję adwersarza PPT M ktoacutery wykorzystuje krotność danych wejściowych (G aG bG ciG) gdzie I ϵ 0 1 jest losowo wybrany (a nie znany M a priori) c1 = ab oraz c0 jest losowym skalarem a dane wyjściowe i mają prawdopodobieństwo

Dla niektoacuterych wielomianoacutew Q2 (k)Należy rozważyć algorytm SIMNIZKP (zbliżony to tego ktoacutery został zdefiniowany w [6]) ktoacutery jako skalary wejściowe wykorzystuje wektor x klucza prywatnego zbioacuter wektoroacutew kluczy

publicznych indeks π oraz wiadomość m i ktoacutery działa w sposoacuteb następujący1 Wygenerować skalary losowe s1 hellip sm oraz skalar losowy cπ lt- H2 Dla j indeksującego określić

A dla pozostałych j

3 Obliczyć losowe dane wyjściowe na podstawie losowego oracle

4 Dla każdego i roboczego mod m obliczyć

Należy podkreślić że w ostatnim punkcie kiedy i = π - 1 to ci+1 jest już określone w celu utrzymania spoacutejności z losowymi danymi wyjściowymi oracleNależy podkreślić że niezależnie od tego czy jest rzeczywistym kluczem prywatnym odpowiadającym ze względu na to że spoacutejność jest zachowywana przez losowe wartości oracle w kolejnych wezwaniach powyższy podpis jest weryfikowany Jeżeli x jest rzeczywiście wektorem klucza prywatnego y to nie ma roacuteżnicy pomiędzy SIMNIZKP oraz rzeczywistym podpisemNa koniec mając krotność (G aG bG ciG) gdzie a b są losowo wybrany skalarami a c1 = ab c0 elementem losowym i ϵ 0 1 M zachodzi w poniższych krokach i pozwala rozwiązać problem decyzyjny Diffie Helmana za pomocą niepomijalnego prawdopodobieństwa M wychwytuje losowe ϒ lt-H z losowej wartości oracle oraz pobiera parę wektoroacutew klucza prywatnego publicznego (x y) a następnie oblicza s jako a = s + ϒx Teraz M wykonuje

SIMNIZKP za pomocą dowolnie wybranych wektoroacutew kluczy w taki sposoacuteb że w danej wiadomości m oraz Jeżeli prawdziwe jest że i = 1 to c = ab oraz logGaG = logbGcG = a

z uwagi na to że zakłada się iż A jest w stanie znaleźć π z prawdopodobieństwem ktoacuterego nie można pominąć to istnieje niepomijalne prawdopodobieństwo frac12 że A zwroacuteci 1 (i wtedy M zwroacuteci 1) Jeżeli i = 0 to A zwraca 1 wyłącznie z prawdopodobieństwem frac12 a zatem dla niektoacuterych niepomijanych prawdopodobieństw powyżej 1`2 M zwraca tę samą wartość co A i tym samym rozwiązuje problem decyzyjny Diffie-Helmana dla losowo wybranych skalaroacutew bez pomijalnego prawdopodobieństwa powyżej 12 co stanowi sprzeczność

Załącznik B Kod demo Ring CT W repozytorium w [14] zbudowałem prostą demonstrację protokołu poufnych transakcji pierścieniowych (Ring Confidential Transactions) wykorzystujących podpisy MLSAG w części 2 oraz podpisy ASNL w części 5

H_ct = RingCTgetHForCT()print(H H_ct)sr Pr = PaperWalletskpkGen() receivers private publicse pe ss = ecdhecdhgen(Pr) compute shared secret ssdigits = 14 in practice it will be 14print(inputs)Cia L1a s2a sa ska = RingCTgenRangeProof(10000 digits)print(outputs)Cib L1b s2b sb skb = RingCTgenRangeProof(7000 digits)Cic L1c s2c sc skc = RingCTgenRangeProof(3000 digits)print(verifying range proofs of outputs)RingCTverRangeProof(Cib L1b s2b sb)RingCTverRangeProof(Cic L1c s2c sc)x P1 = PaperWalletskpkGen()P2 = PaperWalletpkGen()C2 = PaperWalletpkGen()some random commitment grabbed from the blockchainind = 0Ca = RingCTsumCi(Cia)Cb = RingCTsumCi(Cib)Cc = RingCTsumCi(Cic)sk = [x MiniNerosc_sub_keys(ska MiniNerosc_add_keys(skb skc))]

pk = [[P1 P2] [MiniNerosubKeys(Ca MiniNeroaddKeys(Cb Cc)) MiniNerosubKeys(C2 MiniNeroaddKeys(Cb Cc)) ] ]II cc ssVal = MLSAGMLSAG_Sign(pk sk ind)print(Sig verified MLSAGMLSAG_Ver(pk II cc ssVal) )print(Finding received amount corresponding to Cib)RingCTComputeReceivedAmount(pe sr MiniNeroaddScalars(ss skb) Cib)print(Finding received amount corresponding to Cic)RingCTComputeReceivedAmount(pe sr MiniNeroaddScalars(ss skc) Cic)

Przykład transakcji z danymi wejściowymi 10 000 oraz wyjściowymi 3 000 i 7 000(rsquoHrsquo rsquo61fe7f0f5a607a33427d01dd1fded5ffa03fae2e9df9ebccf2e0a2f5bd77a204rsquo)inputs(rsquob b in binaryrsquo 10000 [0 0 0 0 1 0 0 0 1 1 1 0 0 1])Generating Aggregate Schnorr Non-linkable Podpis pierścieniowy outputs(rsquob b in binaryrsquo 7000 [0 0 0 1 1 0 1 0 1 1 0 1 1 0])Generating Aggregate Schnorr Non-linkable Podpis pierścieniowy (rsquob b in binaryrsquo 3000 [0 0 0 1 1 1 0 1 1 1 0 1 0 0])Generating Aggregate Schnorr Non-linkable Podpis pierścieniowy verifying range proofs of outputsVerifying Aggregate Schnorr Non-linkable Podpis pierścieniowy VerifiedVerifying Aggregate Schnorr Non-linkable Podpis pierścieniowy Verified(rsquoGenerating MLSAG sig of dimensions rsquo 2 rsquox rsquo 2)(rsquoverifying MLSAG sig of dimensions rsquo 2 rsquox rsquo 2)(rsquocrsquo[rsquo80a3cfd06dd2862307cd75c2a1566f20cd743dbb0b9feb22d79dcbecb9023f42rsquorsquoa9b7342ba7bf2f102505ca19dab734fde638916c0a29f5b30e49833ab51393earsquorsquo80a3cfd06dd2862307cd75c2a1566f20cd743dbb0b9feb22d79dcbecb9023f42rsquo])(rsquosig verifiesrsquo True)(rsquoSig verifiedrsquo True)Finding received amount corresponding to Cib(rsquoreceived rsquo 7000c Monero Research Lab Page 20 of 20rsquoa488ec68732fb551841c2c6dcc7ffac895d98ec7e9378275ed20ea12805fc18ersquo)Finding received amount corresponding to Cic(rsquoreceived rsquo3000rsquo1b46626858e130a0f3884c74c9fdeabc4d812c519103ea16a35a3f82a3d0ed6drsquo)

ci+1 = h (m Li Ri)dla wszystkich i mod nLINK Podpisy z duplikatami obrazoacutew kluczy I są odrzucaneNależy podkreślić że protokoły proofs of unforgeability anonimowości oraz łączenia obowiązują i stanowią jedynie nieznaczne modyfikacje protokołoacutew proof o ktoacuterych mowa w [8] Przedstawię nieco bardziej uogoacutelnioną wersję tych protokołoacutew dla MLSAG

22 Opis MLSAG W odniesieniu do protokołu Ring CT ktoacuterego opis znajduje się w części 4 wymagam uogoacutelnienia podpisoacutew Back LSAG opisanych w poprzednim rozdziale co umożliwia stosowanie wektoroacutew kluczy (Definicja 21) zamiast po prostu kluczyPrzypuśćmy że każda osoba składająca podpis pod (uogoacutelnionym) pierścieniem

zawierającym n członkoacutew (uczestnikoacutew) ma dokładnie m kluczy Celem podpisu pierścieniowego MLSAG jest realizacja następujących celoacutew

udowodnienie że jeden z podpisujących n zna sekretny klucz właściwy dla całego wektora klucza

Zapewnienie że jeżeli podpisujący wykorzystuje jeden z kluczy podpisoacutew m w innym podpisie MLSAG to dwa pierścienie są połączone a drugi taki podpis MLSAG (zlecony przez blockchain Monero) zostanie odrzucony

Algorytm działa w sposoacuteb następujący niech m stanowi wiadomość Niech π jest sekretnym indeksem odpowiadającym sygnatariuszowi uogoacutelnionego pierścienia Dla j = 1 hellip m niech

oraz dla j = 1 hellip m i = 1 hellip π hellipn (gdzie π oznacza ominięcie indeksu π) niech stanowi jeden z losowych skalaroacutew (elementoacutew Zq) Teraz w sposoacuteb analogiczny do części 21 należy zdefiniować

dla skalaroacutew losowych αj oraz j = 1 hellip m A teraz ponownie analogicznie do części 21 należy określić

i powtoacuterzyć czynność zwiększając przyrostowo i modulo n aż do momentu uzyskania następującej postaci

Na koniec dla każdego rozwiązać mod l Podpis jest następnie przekazywany jako zatem kompleksowość wynosi O (m(n + 1)) Proces weryfikacji przebiega poprzez regenerację wszystkich zaczynając od i = 1 podobnie jak to miało miejsce w części 21 (ktoacutera

stanowi przypadek szczegoacutelny w ktoacuterym m = 1) i przeprowadzając sprawdzenie funkcji haszującej cn+1 = c1 Jeżeli wartości te są wykorzystywane w ustawieniu blockchainowym takim jak Monero podpisy składane za pomocą obrazoacutew kluczy Ij ktoacutere już się pojawiły są następnie odrzucane Można to w bardzo łatwy sposoacuteb wykazać stosując metodę zbliżoną do [8] że

Prawdopodobieństwo że sygnatariusz generujący ważny podpis bez znajomości wszystkich prywatnych kluczy ldquomrdquo należących do ich wektora kluczy dla indeksu π może być pominięty

Prawdopodobieństwo że sygnatariusz nie podpisze żadnego klucza z indeksu π może zostać pominięte (Innymi słowy wszystkie obrazy kluczy stanowiące część podpisu muszą pochodzić z indeksu π)

Jeżeli sygnatariusz podpisuje dwa pierścienie wykorzystując co najmniej jeden z tożsamych kluczy publicznych to następuje skojarzenie (połączenie) dwoacutech pierścieni

Szersze omoacutewienie tych elementoacutew znajduje się w dalszej części materiału dotyczącej zabezpieczeń (security proofs)

23 Model zabezpieczeń MLSAGMLSAG spełnia trzy niżej wymienione właściwości niefałszowalność (Unforgeability) linkowalność (Linkability) oraz Dwuznaczność Sygnatariusza (Signer Ambiguity) ktoacutere są bardzo zbliżone do definicji podanej w [8]

Definicja 22 Niefałszowalność (Unforgeability) System podpisoacutew MLSAG jest niemożliwy do sfałszowania jeżeli dla danego algorytmu A wielomianowego czasu probabilistycznego (PPT) z podpisem oracle SO generującego ważne podpisy oraz dla danej listy wektoroacutew kluczy publicznych n wybranej przez A A może generować przy pomijalnym prawdopodobieństwie ważny podpis w sytuacji gdy A nie zna jednego z odpowiednich wektoroacutew kluczy prywatnych

Uwaga 23 W poniższej definicji należy zauważyć że umieściłem funkcję odrzucania duplikujących się obrazoacutew kluczy jako części kryterioacutew weryfikacji dla MLSAG co przyczynia się do zbudowania nieco zmodyfikowanej definicji linkowalności (Linkability) w stosunku do tej ktoacutera została podana w [8]

Definicja 24 Linkowalność (Linkability) Niech L stanowi zbioacuter wszystkich kluczy publicznych w danym ustawieniu (np w danym łańcuchu blokowym - blockchainie) System składania podpisoacutew MLSAG w L jest połączony z obrazami kluczy jeżeli prawdopodobieństwo że

adwersarz A utworzy w PPT dwa podpisy σ σ1 podpisane w odniesieniu do wektoroacutew kluczy

oraz 1 z ktoacuterych każdy będzie zawierać ten sam klucz publiczny yi = yirsquo W L oraz każdy będzie weryfikowany bez oznaczenia jako duplikat jest pomijalne

Definicja 25 Dwuznaczność sygnatariusza (Signer Ambiguity) System składania podpisoacutew MLSAG uważa się za niejednoznacznie identyfikujący sygnatariusza jeżeli mamy dany podpis weryfikujący σ na wektorach kluczy oraz dowolny zbioacuter kluczy prywatnych t z ktoacuterych każdy będzie mieć oddzielny indeks oraz sekretny indeks w takiej sytuacji prawdopodobieństwo odgadnięcia klucza sekretnego wynosi mniej niż

Dowody potwierdzające powyższe definicje przedstawiono w Załączniku

3 Zarys historyczny transakcji poufnych31 Transakcje poufne w ramach system Bitcoin

W [11] Greg Maxwell opisuje transakcje poufne ktoacutere są pewną metodą przekazywania transakcji w systemie Bitcoin przy jednoczesnym maskowaniu kwot Podstawową kwestią jest stosowanie schematu zobowiązań Pedersena metoda ta jest doskonale opisana w cytowanym materiale źroacutedłowym W niniejszym opracowaniu wprowadzam drobną modyfikację do mechaniki Transakcji Poufnych polegającą na wybieraniu zamiast zobowiązań ktoacuterych suma wynosi zero opcji złożenia podpisu pod zobowiązaniem w celu wykazania że klucz prywatny jest mi znany Schemat ten jest opisany szczegoacutełowo w kolejnym rozdziale

32 Modyfikacja pod kątem podpisoacutew pierścieniowych Niech G stanowi punkt bazowy ed25519 Niech [3]

H = toPoint (cn_fast_hasz (G))

Należy podkreślić że nie każda wartość haszująca pozwala obliczyć punkt w ramach grupy punktu bazowego (tzn dla pewnej niewiadomej) (co jest sprzeczne z tym co dzieje się w secp256k1 krzywej wykorzystywanej w systemie Bitcoin) Nie mniej jednak wydaje się że wyboacuter punktu bazowego jako takiego (wcześniej wykorzystywałem H(123456G) sprawdza się co z resztą wydawało mi się bardziej bezpieczne przy czym punkt bazowy jest z pewnością bardziej naturalnym wyborem) Wyboacuter H = ϒG dla pewnej niewiadomej jest konieczny po to aby pełna matematyka zwykłych krzywych eliptycznych zachowała swoją ważność

[3] H = MiniNerogetHForCT() w kontekście kodu w [14]

Przy założeniu logarytmoacutew dyskretnych w ed25519 prawdopodobieństwo że adwersarz odkryje ϒ jest pomijalne Należy zdefiniować C (a x) = xG+aH zobowiązanie wartości a z maską x Należy podkreślić że tak długo jak wartość logGH nie jest znana oraz jeżeli σ ne 0 to logGC (a x) pozostaje wartością nieznaną Z drugiej strony jeżeli a = 0 to logGC (a x) = x a zatem istnieje możliwość złożenia podpisu za pomocą pary kluczy sk-pk (xC (0 x)) W [11] istnieją dane wejściowe I wyjściowe zobowiązań a sieć sprawdza czy

sumdane wejściowe = sumdane wyjściowe

Nie mniej jednak nie jest to wystarczające w przypadku systemu Monero ponieważ dana transakcja zawiera roacuteżne możliwe do realizacji dane wejściowe Pi i = 1 hellip n z ktoacuterych tylko jedna należa do nadawcy (patrz [16 44]) to jeżeli będziemy w stanie sprawdzić powyższe roacutewnanie to musi być możliwe aby sieć widziała ktoacutere Pi należy do nadawcy transakcji Nie jest to zjawisko pożądane ponieważ eliminuje anonimowość zbudowaną dzięki podpisowi pierścieniowemu W związku z tym zastępczo tworzy się zobowiązania dla danych wejściowych oraz wyjściowych zgodnie z poniższym (załoacuteżmy najpierw że istnieje tylko jeden zestaw danych wejściowych)

Cin = xcG + aHCout10485761 = y1G + b1HCout10485762 = y2G + b2H

W taki sposoacuteb że xc = y1+y2+z xc - y1 - y2 = z yi są wartościami maskującymi z gt 0 oraz a = b1+b2W tym przypadku xc stanowi szczegoacutelny prywatny klucz a ldquokwota kluczardquo znana jest tylko nadawcy oraz osobie do ktoacuterej coiny są wysyłane zatem musi być odmienna od normalnego klucza prywatnego W takim przypadku

= xcG + aH - y1G - b1H - y2G - b2H= zG

A zatem powyższe roacutewnanie staje się zobowiązaniem do 0 przy sk = z oraz pk = zG a nie rzeczywistym roacutewnaniem o sumie zerowej Należy podkreślić że z nie jest wyliczalne dla coinoacutew źroacutedłowych xc chyba że znana jest zaroacutewno wartość y1 jak i y2 nie mniej jednak nawet to można w prosty sposoacuteb złagodzić poprzez uwzględnienie dodatkowych adresoacutew zmiany (zwykły przypadek zakłada że drugie zobowiązanie z wartością y2 jako maską są wysyłane jako zmiana)Ponieważ podawanie informacji ktoacutere dane wejściowe należą do nadawcy nie jest pożądane podpis pierścieniowy zawierający wszystkie zobowiązania wejściowe Ci i = 1 hellip s hellip n (gdzie s stanowi sekretny indeks zobowiązania nadawcy) dodaje się odpowiedni klucz publiczny (dzięki czemu zobowiązania oraz klucze publiczne są parowane (Ci Pi) ale tylko takie ktoacutere mogą być wspoacutelnie wydatkowane) oraz odejmuje sumCout

Jest to podpis pierścieniowy ktoacutery może być złożony ponieważ znamy jeden z prywatnych kluczy (a mianowicie z + xrsquo zawierający z jak wyżej oraz xrsquoG = Ps) Tak naprawdę ponieważ wiemy że dla każdego i zaroacutewno klucze prywatne dla Pi jak i klucze prywatne dla Pi + Ciin - sumjCjout możemy złożyć podpis zgodnie z treścią rozdziału 22 Szczegoacuteły tej procedury są opisane w Definicji 41

Zgodnie z [11] ważne jest udowodnienie że kwoty wyjściowe [4] b1 hellip bn wszystkie mieszczą się w szeregu wartości dodatnich np (0 216) Można to osiągnąć zasadniczo w taki sam sposoacuteb jak w [11] kwestia ta jest bardziej szczegoacutełowo opisana w części 5Na koniec warto zauważyć że w powyższej dyskusji nie wspomniałem o właściwości związanej dołączaniem tagoacutew ktoacutera jest wykorzystywana w Monero oraz Cryptonote w celu zapobiegania podwoacutejnemu wydatkowaniu środkoacutew Dołączanie tagoacutew w tym momencie będzie skutkiem łączenia powyższego omoacutewienia z podpisami MLSAG o ktoacuterych mowa w Definicji 41

4 Ring CT dla protokołu Monero 41 Opis protokołuDefinicja 41 (Tagowalny pierścień CT z mnogimi danymi wejściowymi oraz kluczami jednorazowymi)

Niech stanowi zbioacuter adresoacutew oraz kluczy jednorazowychzobowiązań ktoacuterym odpowiadają sekretne klucze xj j = 1 hellip m

Znaleźć zbiory q + 1 i = 1 hellip q + 1 ktoacutere nie są połączone tagami w sensie [ 6 strona 6]

Należy określić zestaw adresoacutew wyjściowych (Qi Ciout) takich że

stanowią zobowiązania o wartości zero Niech

hellip

stanowi uogoacutelniony pierścień w ktoacuterym chcemy złożyć swoacutej podpis Należy zauważyć że ostatnia kolumna to pierścień Ring-CT w rozumieniu rozdziału 4

Obliczyć podpis MLSAG sum na R

[4] Ponieważ zobowiązania wejściowe mogą być potencjalnie odziedziczone z poprzednich transakcji wystarczy rozważyć kwoty wyjściowe

W takim przypadku zgodnie z teorematem A2 nie może być sygnatariuszem żadnych dodatkowych niezlinkowanych podpisoacutew pierścieniowych w danym nadzbiorze P wszystkich takich par P = (PC) po podpisaniu sum

Uwaga 42 Złożoność przestrzeni powyższego protokołu Warto zauważyć że rozmiar podpisu sum na R zgodnie z definicją 41 jest w rzeczywistości mniejszy dla m gt 1 niż bieżący podpis pierścieniowy transakcji opartej na protokole CryptoNote [16] ktoacutera zawiera mnogie dane wejściowe Dzieje się tak dzięki wprowadzeniu zmian w rozmiarze w [8] do każdej kolumny Należy także podkreślić że prawdopodobnie nie jest konieczne umieszczanie obrazu klucza zobowiązania związanego z wyżej wymienionym podpisem Kolejne optymalizacje rozmiaru są możliwe i można je wykonać w podobny sposoacuteb

42 Konwersja widocznych denominacji na zobowiązaniaPonieważ Monero obecnie wykorzystuje blockchainowe widoczne skalary w celu stworzenia reprezentacji kwot ważne jest aby istniała możliwość (i sposoacuteb) konwersji z kwot widocznych na zobowiązania przy jednoczesnym zachowaniu anonimowości Tak naprawdę wcale nie jest to trudne Mając daną parę (P a) gdzie P jest kluczem publicznym a a stanowi kwotę może ona być wykorzystana jako dane wejściowe transakcji jako (P aH) i transakcja ta musi być zweryfikowana przez weryfikatora pod kątem kwoty wejściowej i jej przemnożenia przez punkt maskujący H oraz czy uzyskana wartość rzeczywiście wynosi aH Zatem jako pierwszy krok kwoty wejściowe nie zostaną ukryte ale ukryte zostaną dane wyjściowe transakcji oraz wszelkie niezbędne relacje o ktoacuterych mowa w rozdziale 4 pozostają ważne Należy podkreślić że range proof nie jest konieczny dla tych danych wejściowych

Uwaga 43 Oczywistą zaletą tej metody jest konwersja z kwot widocznych na zobowiązania oraz to że kwota coinoacutew wygenerowanych w procesie wydobycia jest weryfikowalna bez konieczności udziału elementu zaufanego Jest to przewaga protokołu Ring CT nad systemami płatniczymi takimi jak [4] ktoacutere obejmują fazę ustawień strony zaufanej

43 Opłaty transakcyjnePonieważ system Monero jest silnie zdecentralizowany (tzn proof of work) konieczne jest wynagradzanie goacuternikoacutew i dokonywanie opłat za każdą transakcję Pomaga to podnieść bezpieczeństwo sieci i zapobiegać rozdęcia blockchainu Opłaty te muszą być realizowane w postaci niezamaskowanej tzn Jako bH a nie xG + bH oraz w odniesieniu do pewnej standardowej kwoty b w taki sposoacuteb że goacuternik będzie moacutegł zweryfikować że b ∙ H = bH i tym samym że jest dość środkoacutew na opłatę transakcyjną przy jednoczesnym zachowaniu roacutewnań związanych z H w taki sposoacuteb że zostaną zachowane niezbędne relacje o ktoacuterych mowa w Rozdziale 4

44 Ring MultisignatureWarto zauważyć że prosta wersja t z m z n ring-multisignature [mnogich podpisoacutew pierścieniowych] może być zrealizowana w oparciu o podpisy MLSAG Umożliwia to grupie m uczestnikoacutew zbudowanie multisignature takiego że t uczestnikoacutew z liczby z m musi złożyć podpis aby był on uznany za ważny dodatkowo jest on dwuznaczny w odniesieniu do sygnatariusza klucze m są uczestnikami mieszczącymi się w ogoacutelnej liczbie n kluczy

Liczba n uczestnikoacutew w multisignature stanowi wspoacutelny sekret xe oraz klucz publiczny Pe ktoacutere mają wspoacutelne obrazy kluczy multisig

Ij = xeH(PejPj)

z Pj ndash publicznym kluczem uczestnika Każdy uczestnik multisignature dokonuje wyboru dodatkowych kluczy publicznych n -

m w blockchainie oraz tworzy podpis MLSAG za pomocą pierwszego rzędu wszystkich kluczy n a drugi rząd ma dla każdego wpisu (elementu) klucz wspoacutelny Pe

Każdy sygnatariusz multisignature podaje początkowe Ij j = 1 hellip m w celu umożliwienia zaakceptowania klucza po przekazaniu podpisoacutew weryfikujących t w blockchainie z ktoacuterych każdy odpowiada jednemu obrazowi klucza Ij

Rozszerzony zapis ring-multisignature jest w fazie opracowania

5 Zagregowane schematy identyfikacji Schnorra (Aggregate Schnorr Range Proofs)W części [11] poufne transakcja bez podpisu pierścieniowego wykorzystuje pewien typ podpisu pierścieniowego oparty na [1] nazywany podpisem pierścienia boromejskiego (Borromean ring signature) i pomaga zidentyfikować przekłamania w wartości zobowiązań w pewnym przedziale W niniejszym artykule postaram się nakreślić alternatywną metodę zainspirowaną przez [7] ktoacutera pozwala na uzyskanie tych samych oszczędności w zakresie przestrzeni ale za to opatrzona jest nieco mniej skomplikowanym protokołem bezpieczeństwa Motywacja do tego typu działania jest następująca przypuśćmy że dana transakcja ma dane wejściowe zobowiązań roacutewne

Cin = ainG + 10H

oraz zobowiązania wyjściowe

Cout 1 = aout1G + 5H Cout2 = aout2G + 5H

Scenariusz ten zachowuje ważność gdyż istnieje możliwość złożenia podpisu dla Cin ndash Cout1 ndash Cout2 = (ain ndash aout1 ndash aout2)G

Nie mniej jednak warto podkreślić że (bez range proofs) będzie istniała możliwość alternatywnego ustawienia zobowiązań wyjściowych

Cout1 = aout1G- H Cout2 = aout2G + 11H

Ponieważ -1 jest bardzo dużą liczbą stanowiącą modulo porządkujące grupę krzywej tym samym zostały utworzone darmowe pieniądze Zatem konieczne jest wykazanie że Couti są zobowiązaniami w odniesieniu do wartości ktoacutere są pozytywne (dodatnie) i mieszczą się w ograniczonym przedziale [0 2n] dla niektoacuterych wartości n Aby tego dokonać należy rozłożyć każdą wartość wyjściową na elementy binarne

co pozwala obliczyć zobowiązania do bj ∙ 2j w taki sposoacuteb że

Na koniec wykorzystując sekretny klucz bj można obliczyć podpis pierścieniowy na

dla wszystkich j oraz zapewnia dla weryfikatoroacutew (w tym przypadku goacuternikoacutew)Jeżeli chodzi o oszczędności miejsca można albo wykorzystać boromejski podpis pierścieniowy (podobnie jak w [11]) albo połączyć wszystkie proste podpisy pierścieniowe bądź utworzyć pewien typ zagregowanego podpisu pierścieniowego zdefiniowanego w następujący sposoacuteb

501 Generowanie zagregowanego nielinkowanego podpisu pierścieniowego Schnorra (Aggregate Schnorr Non-linkable Ring Signature) (ASNL)

Niech stanowi zbioacuter kluczy j = 1hellip z jako sekretnym kluczem

Dla każdego j niech Irsquo = i + 1 mod 2 ustawić skalar losowy aj i obliczyć

Ustawić gdzie Hs to kryptograficzna funkcja haszująca zwracająca skalar po dokonaniu wyboru losowego obliczyć

Określić i obliczyć

Zwroacutecić dla wszystkich j i s =

502 Weryfikacja zagregowanego nielinkowalnego podpisu pierścieniowego Schnorra (ASNL)Zacznijmy od dla j = 1hellip n oraz s

Dla wszystkich j obliczyć oraz

Jeżeli to otrzymamy 0 dla ważnego podpisuW przeciwnym razie otrzymamy wartość zwrotną -1

Teoremat 51 Zagregowany nielinkowany podpis pierścieniowy Schnorra nie może być sfałszowany przy założeniu logarytmu dyskretnego

Dowoacuted Przedstawiam szkic dowodu w przypadku n = 2 Przypadek ogoacutelny ma zbliżony charakter Przypuśćmy że adwersarz A jest w stanie sfałszować podpis ASNL na

Przy pomijalnym prawdopodobieństwie znając najwyżej jedną z (przypuśćmy że bez straty ogoacutelnego charakteru założenia że A zna ) Dla każdego danego fałszu

rozwiązuję roacutewnanie logarytmu dyskretnego o niepomijalnym prawdopodobieństwie Po zastosowaniu algorytmu weryfikacji niech Zatem prawdziwe musi być roacutewnanie

Przypuśćmy że oraz a a b są znane A wtedy

ponieważ jest określone protokołem weryfikacji musi być zatem prawdą że A zna klucz

prywatny

=Jest to w sprzeczności z założeniem logarytmu dyskretnego dla danej grupy

51 Reprezentacja kwotKwoty w protokole Ring CT można przedstawiać w sposoacuteb zbliżony do tego ktoacutery przedstawiony został w [11] z drobną modyfikacją w celu dopasowania do systemu Monero Coiny CryptoNote organizują nominały coinoacutew w bazie indeksoacutew w taki sposoacuteb aby mogły być ułożone w porządku występowania jako dane wejściowe dla podpisoacutew pierścieniowych Ponieważ wszystkie wartości coinoacutew w CryptoNote są reprezentowane w postaci 64-bitowych niepodpisanych liczb całkowitych możemy wykorzystać range proof na przestrzeni całego rejestru w celu zakodowania kwoty wyjściowej przekazywanej odbiorcy Na szczęście to także umożliwia wzajemne miksowanie danych wyjściowych zatem wymagany jest tylko jeden indeks danych wyjściowych w porządku rejestracji Przedział weryfikacji (range proof) wynosi ok 5 kilobajtoacutew Podpisy pierścieniowe dla danych wejściowych stają się bardziej odporne na analizę ponieważ anonimowość jest bardzo rozszerzonaPodczas gdy obszary weryfikacji (range proofs) są duże wykorzystywanie układu haszującego ktoacutery dodaje przedrostek do transakcji (zaroacutewno indeksoacutew wejściowych jak i wyjściowych) i przechowuje szeroki zakres range proof wraz z podpisami umożliwia oddzielnie uzyskanie ogromnych oszczędności przestrzeni podczas synchronizacji (syncing) do punktu weryfikacji lub działanie jako węzeł SPV Podobnie do elementoacutew bocznych łańcucha (Sidechains Elements) [12] będziemy przechowywać H(H(prefiks)||H(podpisy)) w drzewie Merkla Następnie węzły syncing do zaufanego punktu weryfikacji muszą jedynie pobrać przedrostek i dodać wartość haszującą do podpisoacutew skutecznie redukując szerokość wiązki Ponieważ prefiks transakcji wykorzystuje wariant dla danych wyjściowych ktoacutere wymienia w swoich podpisach pierścieniowych oraz środkach zapisanych do jednego klucza publicznego stanowi on miniaturowe poroacutewnanie do danych podpisoacutew pierścieniowych w danych wyjściowych oraz range proofs

Następnie podpisy pierścieniowe mogą nawet być przycięte z bazy danych przez niektoacutere węzły w celu uzyskania dalszych zyskoacutew przestrzeni przechowując zastępczo jedynie względnie mały zbioacuter UTXO

511 Przekazywanie informacji o kwotach OdbiorcyObecnie mając dowolną kwotę wyjściową b = b020 + b121 + ∙∙∙ bn2n nadawca oblicza nową prywatnąpubliczną parę kluczy oraz związane wymieniane sekrety ECDH ss oraz udostępnia następujące informacje w swojej transakcji

gdzie ai to losowo wybrane liczby dla j = 0 hellipn Dane Klucz publiczny ECDH oraz a + ss mod l gdzie a = a0 + hellip + an

Następnie odbiorca Oblicza udostępniany sekret ss oraz oblicza a na podstawie a + ss mod l Oblicza C = sumCi oblicza C ndash aG = bH oraz oblicza b poroacutewnując uzyskane wartości do

wszystkich bH w danym przedziale [0 2n] (W praktyce będzie to szybkie 500 kilobajtowe wyszukanie w n = 12 podobnie jak w poprzednim rozdziale Gdyby jednak wartość 232 została wybrana jako goacuterna wartość graniczna podobnie jak w [11] wyszukiwanie stałoby się dużym obliczeniowo wysiłkiem)

6 WnioskiProtokoacuteł pierścieniowych transakcji poufnych (Ring Confidential Transactions) to bardzo silnie zdecentralizowana kryptowaluta (tzn nie ma w niej żadnej uprzywilejowanej strony) ktoacutera posiada proste do udowodnienia wartości szacunkowe zabezpieczeń dotyczące ukrywania kwot transferoacutew ich źroacutedeł oraz odbiorcoacutew Dodatkowo generowanie coinoacutew w oparciu o protokoacuteł Ring Confidential Transactions nie wymaga obecności czynnika zaufanego i proces jego weryfikacji jest całkowicie bezpiecznyTych pięć czynnikoacutew jest niezbędnych w przypadku kryptowalut zbliżonych do środkoacutew gotoacutewkowych takich jak MoneroBibliografia1 Masayuki Abe Miyako Ohkubo and Koutarou Suzuki 1-out-of-n signatures from a variety of keys Advances in CryptologyAsiacrypt 2002 pages 415ndash432 20022 Adam Back Bitcoins with homomorphic value (validatable but encrypted)httpsbitcointalkorgindexphptopic=3057910 2013 [Online accessed 1-May-2015]3 Adam Back Podpis pierścieniowy efficiency httpsbitcointalkorgindexphptopic=972541msg10619684msg10619684 2015 [Online accessed 1-May-2015]4 Eli Ben Sasson Alessandro Chiesa Christina Garman Matthew Green Ian Miers Eran Tromer and Madars Virza Zerocash Decentralized anonymous payments from bitcoin In Security and Privacy (SP) 2014 IEEE Symposium on pages 459ndash474 IEEE 20145 Evan Duffield and Kyle Hagan Darkcoin Peertopeer cryptocurrency with anonymous blockchain transactions and an improved proofofwork system 20146 Eiichiro Fujisaki and Koutarou Suzuki Traceable podpis pierścieniowy In Public Key CryptographyndashPKC 2007 pages 181ndash200 Springer 20077 Javier Herranz Aggregate signatures httpwwwiiiacsices~jherranzpapersNijmegen_seminar_aggregatepdf oct 20058 Joseph K Liu Victor K Wei and Duncan S Wong Linkable spontaneous anonymous group signature for ad hoc groups In Information Security and Privacy pages 325ndash335 Springer 20049 Adam Mackenzie Surae Noether and Monero Core Team Improving obfuscation in the cryptonote protocol httpslabgetmoneroorgpubsMRL-0004pdf January 201510 Greg Maxwell Coinjoin Bitcoin privacy for the real world august 2013 Bitcoin Forum httpsbitcointalkorgindexphptopic=2792490 2013 [Online accessed 1-July-2015]11 Greg Maxwell Confidential Transactions httpspeoplexiphorg~gregconfidential_valuestxt 2015 [Online accessed 1-June-2015]12 Greg Maxwell Elements project httpsgithubcomShenNoetherMiniNero 201513 Satoshi Nakamoto Bitcoin A peer-to-peer electronic cash system Consulted 1(2012)28 200814 Shen Noether Mininero httpsgithubcomShenNoetherMiniNero 201515 Ronald L Rivest Adi Shamir and Yael Tauman How to leak a secret In Advances in CryptologyASIACRYPT 2001 pages 552ndash565 Springer 200116 Nicolas van Saberhagen Cryptonote v 2 0 HYPERLINK https cryptonote org whitepaper pdf 2013

Załącznik A Załącznik Security ProofsA1 Brak możliwości sfałszowania MLSAG

Obliczenia przebiegają analogicznie do [8 Teoremat 1] Niech H1 oraz H2 będą losowo wybranymi oracle a SO stanowią podpisy oracle zwracające ważne podpisy MLSAG Załoacuteżmy że istnieje probabilistyczny wielomianowy adwersarz czasowy (PPT) A ktoacutery posiada zdolność sfałszowania MLSAG z listy wektoroacutew kluczy L przy prawdopodobieństwie ktoacuterego nie można pominąć

Gdzie Q1 stanowi wielomianowy parametr bezpieczeństwa k oraz gdzie (m σ) nie stanowi jednego z podpisoacutew zwracanych przez SO Załoacuteżmy że A nie wysyła więcej niż qH + nqS

(gdzie n oznacza liczbę kluczy w L) zapytań dotyczących podpisoacutew oracle H1H2 oraz SO odpowiednio Podpisy oracle H1 oraz H2 uważa się za niezależne i losowe oraz spoacutejne z danymi zapytaniami powtarzającymi się Podpis oracle SO może składać zapytanie H1 oraz H2 Mając wartość A wykaże że istnieje możliwość utworzenia adwersarza M w PPT ktoacutery będzie wykorzystywać A w celu znalezienia logarytmu dyskretnego jednego z kluczy w L

Jeżeli L stanowi zbioacuter kluczy wektoroacutew z ktoacuterych każdy będzie mieć wielkość r (tzn z kluczami publicznymi y1 hellip yr ) to wygenerowany fałszywy podpis

Wygenerowany przez A musi spełniać warunek

Gdzie i są obliczone w ramach mod n oraz są zdefiniowane zgodnie z Rozdziałem 22 Nowy adwersarz M może wykorzystać A w celu sfałszowania podpisoacutew wielomianową liczbę razy i zapisze każdy skrypt Turinga T niezależnie czy sfałszowanie było skuteczne czy nie

Lemma A1 [8 Lemma 1] Niech M wywołuje A w celu uzyskania transkrypcji T Jeżeli T jest skuteczne to M powraca do T do nagłoacutewka H i następnie re-symuluje A w celu uzyskania transkrypcji Trsquo Jeżeli Pr (T okaże się skuteczne) = ϵ to Pr (Trsquo jest skuteczne) = ϵ

Dowoacuted wynika wprost z przywołanego teorematu

Teoremat A2 Prawdopodobieństwo że adwersarz A sfałszuje podpis MLSAG można pominąć przy założeniu logarytmu dyskretnego

Dowoacuted Do przeprowadzenia dowodu będę stosować notację przedstawioną powyżej Podobnie jak w przypadku [8 teoremat 1] ponieważ prawdopodobieństwo odgadnięcia danych wyjściowych z losowego oracle jest znikome w związku z tym dla każdego skutecznego oszustwa A wprowadza transkrypcję uzupełniającą T a zatem mamy mT zapytań w przypadku zapytań do H1 odpowiadających liczbie n zapytań wykorzystywanych w celu weryfikacji podpisu W związku z tym niech Xi1 hellip Xim oznacza zapytania wykorzystywane w procesie weryfikacji fałszu ith oraz niech π oznacza indeks odpowiadający ostatniemu zapytaniu weryfikacyjnego dla danego oszustwa

(Intuicyjnie π odpowiada temu co może stanowić indeks sekretny fałszywego podpisu ponieważ odpowiada on ostatniemu wezwaniu ostatniemu wywołaniu losowego oracle dla danego odpisu)Proacuteba sfałszowania σ podjęta przez A stanowi fałsz (l π) jeżeli i1 = l oraz π jest zgodne z powyższym (zatem fałsz odpowiada zapytaniom l do l + π) Z założenia istnieje para (l π) taka że prawdopodobieństwo związanej transkrypcji T daje skutecznie wygenerowany fałszywy klucz ϵlπ (T) spełnia warunek

1

Teraz przeglądając T do wartości przed zapytaniem l-tym a następnie podejmując proacutebę sfałszowania za pomocą tego samego zbioru kluczy (oraz dopuszczając aby H1 obliczyło nowe rzuty monetami dla wszystkich kolejnych zapytań) z Lemmy A1 wynika że prawdopodobieństwo że Trsquo jest także skuteczne spełnia warunki

_Dlatego prawdopodobieństwo że zaroacutewno T jak i Trsquo odpowiadają weryfikacjom fałszywym σ i σ1 nie może zostać pominięte

Ponieważ nowe rzuty monetami zostały obliczone na podstawie danych wyjściowych losowych oracle H1 oznacza to że przy dużym prawdopodobieństwie istnieje wartość j taka

że oraz W związku z tym możemy rozwiązać klucz prywatny z indeksem π

ktoacutery jest sprzeczny z założeniami logarytmu dyskretnego

A2 Linkowalność MLSAG Teoremat A3 Linkowalność obrazu klucza (Key-Image Linkability) Prawdopodobieństwo że adwersarz a w PPT może utworzyć dwa podpisy weryfikujące (niepołączone w danym

ustawieniu σ σrsquo podpisane w odniesieniu do wektoroacutew kluczy oraz odpowiednio w taki

sposoacuteb że będzie istnieć klucz publiczny i w obu oraz może być pominięte

Dowoacuted Przypuśćmy że w przeciwieństwie do tego co zostało wcześniej powiedziane A utworzył dwa podpisy weryfikujące σ oraz σrsquo o oba są podpisami w odniesieniu do kluczowych wektoroacutew

oraz odpowiednio w taki sposoacuteb że istnieje klucz publiczny y zaroacutewno w jak i

Niech y występuje jako element j należący do a jrsquo jako element należący do rsquo Z teorematu A2 wynika z dużym prawdopodobieństwem że istnieją indeksy π oraz πrsquo dla kluczy publicznych σ oraz σrsquo odpowiednio takie że

oraz

z

oraz

Jeżeli uznamy że x oznacza klucz prywatny y y = xG to po rozwiązaniu powyższego dla Ij

oraz Ij0rsquo mamy następujące roacutewnania oraz podobnie Ijrsquo = xH (y) Tym samym dwa podpisy obejmują Ij = Ijrsquo i w związku z tym ponieważ zduplikowane obrazy kluczy są odrzucone jeden z nich nie może być wykorzystany do weryfikacji

A3 Anonimowość MLSAG W celu udowodnienia anonimowości powyższego protokołu w losowym modelu oracle przyjmijmy że H1 H2 to losowe oracle modelujące dyskretne funkcje haszujące Niech A to adwersarz anonimowości Buduję adwersarza M względem założenia problemu decyzyjnego Diffie Helmana (DDH) zgodnie z poniższym Założenie DDH stwierdza że mając daną krotność (G aG bG ϒG) prawdopodobieństwo ustalenia czy G = abG jest znikome

Teoremat A4 Protokoacuteł pierścieniowy CT jest dwuznaczny w odniesieniu do sygnatariusza przy założeniu problemu decyzyjnego Diffie-HelmanaDowoacuted (zbliżony do dowodu [8 Teoremat 2]) Załoacuteżmy że problem decyzyjny Diffie-Helmana jest trudny w cyklicznej grupie generowanej przez G i załoacuteżmy że istnieje adwersarz A w czasie PPT względem dwuznaczności sygnatariusza Tym samym mając listę L n wektoroacutew

kluczy publicznych o długości m oraz zbioacuter prywatnych kluczy t ważny podpis σ na L podpisany przez użytkownika w odniesieniu do wektora klucza y taki że

odpowiedni wektor klucza prywatnego wynosi spełnia to A może zdeterminować π z prawdopodobieństwem

Dla wybranych wielomianoacutew Q(k) Buduję adwersarza PPT M ktoacutery wykorzystuje krotność danych wejściowych (G aG bG ciG) gdzie I ϵ 0 1 jest losowo wybrany (a nie znany M a priori) c1 = ab oraz c0 jest losowym skalarem a dane wyjściowe i mają prawdopodobieństwo

Dla niektoacuterych wielomianoacutew Q2 (k)Należy rozważyć algorytm SIMNIZKP (zbliżony to tego ktoacutery został zdefiniowany w [6]) ktoacutery jako skalary wejściowe wykorzystuje wektor x klucza prywatnego zbioacuter wektoroacutew kluczy

publicznych indeks π oraz wiadomość m i ktoacutery działa w sposoacuteb następujący1 Wygenerować skalary losowe s1 hellip sm oraz skalar losowy cπ lt- H2 Dla j indeksującego określić

A dla pozostałych j

3 Obliczyć losowe dane wyjściowe na podstawie losowego oracle

4 Dla każdego i roboczego mod m obliczyć

Należy podkreślić że w ostatnim punkcie kiedy i = π - 1 to ci+1 jest już określone w celu utrzymania spoacutejności z losowymi danymi wyjściowymi oracleNależy podkreślić że niezależnie od tego czy jest rzeczywistym kluczem prywatnym odpowiadającym ze względu na to że spoacutejność jest zachowywana przez losowe wartości oracle w kolejnych wezwaniach powyższy podpis jest weryfikowany Jeżeli x jest rzeczywiście wektorem klucza prywatnego y to nie ma roacuteżnicy pomiędzy SIMNIZKP oraz rzeczywistym podpisemNa koniec mając krotność (G aG bG ciG) gdzie a b są losowo wybrany skalarami a c1 = ab c0 elementem losowym i ϵ 0 1 M zachodzi w poniższych krokach i pozwala rozwiązać problem decyzyjny Diffie Helmana za pomocą niepomijalnego prawdopodobieństwa M wychwytuje losowe ϒ lt-H z losowej wartości oracle oraz pobiera parę wektoroacutew klucza prywatnego publicznego (x y) a następnie oblicza s jako a = s + ϒx Teraz M wykonuje

SIMNIZKP za pomocą dowolnie wybranych wektoroacutew kluczy w taki sposoacuteb że w danej wiadomości m oraz Jeżeli prawdziwe jest że i = 1 to c = ab oraz logGaG = logbGcG = a

z uwagi na to że zakłada się iż A jest w stanie znaleźć π z prawdopodobieństwem ktoacuterego nie można pominąć to istnieje niepomijalne prawdopodobieństwo frac12 że A zwroacuteci 1 (i wtedy M zwroacuteci 1) Jeżeli i = 0 to A zwraca 1 wyłącznie z prawdopodobieństwem frac12 a zatem dla niektoacuterych niepomijanych prawdopodobieństw powyżej 1`2 M zwraca tę samą wartość co A i tym samym rozwiązuje problem decyzyjny Diffie-Helmana dla losowo wybranych skalaroacutew bez pomijalnego prawdopodobieństwa powyżej 12 co stanowi sprzeczność

Załącznik B Kod demo Ring CT W repozytorium w [14] zbudowałem prostą demonstrację protokołu poufnych transakcji pierścieniowych (Ring Confidential Transactions) wykorzystujących podpisy MLSAG w części 2 oraz podpisy ASNL w części 5

H_ct = RingCTgetHForCT()print(H H_ct)sr Pr = PaperWalletskpkGen() receivers private publicse pe ss = ecdhecdhgen(Pr) compute shared secret ssdigits = 14 in practice it will be 14print(inputs)Cia L1a s2a sa ska = RingCTgenRangeProof(10000 digits)print(outputs)Cib L1b s2b sb skb = RingCTgenRangeProof(7000 digits)Cic L1c s2c sc skc = RingCTgenRangeProof(3000 digits)print(verifying range proofs of outputs)RingCTverRangeProof(Cib L1b s2b sb)RingCTverRangeProof(Cic L1c s2c sc)x P1 = PaperWalletskpkGen()P2 = PaperWalletpkGen()C2 = PaperWalletpkGen()some random commitment grabbed from the blockchainind = 0Ca = RingCTsumCi(Cia)Cb = RingCTsumCi(Cib)Cc = RingCTsumCi(Cic)sk = [x MiniNerosc_sub_keys(ska MiniNerosc_add_keys(skb skc))]

pk = [[P1 P2] [MiniNerosubKeys(Ca MiniNeroaddKeys(Cb Cc)) MiniNerosubKeys(C2 MiniNeroaddKeys(Cb Cc)) ] ]II cc ssVal = MLSAGMLSAG_Sign(pk sk ind)print(Sig verified MLSAGMLSAG_Ver(pk II cc ssVal) )print(Finding received amount corresponding to Cib)RingCTComputeReceivedAmount(pe sr MiniNeroaddScalars(ss skb) Cib)print(Finding received amount corresponding to Cic)RingCTComputeReceivedAmount(pe sr MiniNeroaddScalars(ss skc) Cic)

Przykład transakcji z danymi wejściowymi 10 000 oraz wyjściowymi 3 000 i 7 000(rsquoHrsquo rsquo61fe7f0f5a607a33427d01dd1fded5ffa03fae2e9df9ebccf2e0a2f5bd77a204rsquo)inputs(rsquob b in binaryrsquo 10000 [0 0 0 0 1 0 0 0 1 1 1 0 0 1])Generating Aggregate Schnorr Non-linkable Podpis pierścieniowy outputs(rsquob b in binaryrsquo 7000 [0 0 0 1 1 0 1 0 1 1 0 1 1 0])Generating Aggregate Schnorr Non-linkable Podpis pierścieniowy (rsquob b in binaryrsquo 3000 [0 0 0 1 1 1 0 1 1 1 0 1 0 0])Generating Aggregate Schnorr Non-linkable Podpis pierścieniowy verifying range proofs of outputsVerifying Aggregate Schnorr Non-linkable Podpis pierścieniowy VerifiedVerifying Aggregate Schnorr Non-linkable Podpis pierścieniowy Verified(rsquoGenerating MLSAG sig of dimensions rsquo 2 rsquox rsquo 2)(rsquoverifying MLSAG sig of dimensions rsquo 2 rsquox rsquo 2)(rsquocrsquo[rsquo80a3cfd06dd2862307cd75c2a1566f20cd743dbb0b9feb22d79dcbecb9023f42rsquorsquoa9b7342ba7bf2f102505ca19dab734fde638916c0a29f5b30e49833ab51393earsquorsquo80a3cfd06dd2862307cd75c2a1566f20cd743dbb0b9feb22d79dcbecb9023f42rsquo])(rsquosig verifiesrsquo True)(rsquoSig verifiedrsquo True)Finding received amount corresponding to Cib(rsquoreceived rsquo 7000c Monero Research Lab Page 20 of 20rsquoa488ec68732fb551841c2c6dcc7ffac895d98ec7e9378275ed20ea12805fc18ersquo)Finding received amount corresponding to Cic(rsquoreceived rsquo3000rsquo1b46626858e130a0f3884c74c9fdeabc4d812c519103ea16a35a3f82a3d0ed6drsquo)

stanowi przypadek szczegoacutelny w ktoacuterym m = 1) i przeprowadzając sprawdzenie funkcji haszującej cn+1 = c1 Jeżeli wartości te są wykorzystywane w ustawieniu blockchainowym takim jak Monero podpisy składane za pomocą obrazoacutew kluczy Ij ktoacutere już się pojawiły są następnie odrzucane Można to w bardzo łatwy sposoacuteb wykazać stosując metodę zbliżoną do [8] że

Prawdopodobieństwo że sygnatariusz generujący ważny podpis bez znajomości wszystkich prywatnych kluczy ldquomrdquo należących do ich wektora kluczy dla indeksu π może być pominięty

Prawdopodobieństwo że sygnatariusz nie podpisze żadnego klucza z indeksu π może zostać pominięte (Innymi słowy wszystkie obrazy kluczy stanowiące część podpisu muszą pochodzić z indeksu π)

Jeżeli sygnatariusz podpisuje dwa pierścienie wykorzystując co najmniej jeden z tożsamych kluczy publicznych to następuje skojarzenie (połączenie) dwoacutech pierścieni

Szersze omoacutewienie tych elementoacutew znajduje się w dalszej części materiału dotyczącej zabezpieczeń (security proofs)

23 Model zabezpieczeń MLSAGMLSAG spełnia trzy niżej wymienione właściwości niefałszowalność (Unforgeability) linkowalność (Linkability) oraz Dwuznaczność Sygnatariusza (Signer Ambiguity) ktoacutere są bardzo zbliżone do definicji podanej w [8]

Definicja 22 Niefałszowalność (Unforgeability) System podpisoacutew MLSAG jest niemożliwy do sfałszowania jeżeli dla danego algorytmu A wielomianowego czasu probabilistycznego (PPT) z podpisem oracle SO generującego ważne podpisy oraz dla danej listy wektoroacutew kluczy publicznych n wybranej przez A A może generować przy pomijalnym prawdopodobieństwie ważny podpis w sytuacji gdy A nie zna jednego z odpowiednich wektoroacutew kluczy prywatnych

Uwaga 23 W poniższej definicji należy zauważyć że umieściłem funkcję odrzucania duplikujących się obrazoacutew kluczy jako części kryterioacutew weryfikacji dla MLSAG co przyczynia się do zbudowania nieco zmodyfikowanej definicji linkowalności (Linkability) w stosunku do tej ktoacutera została podana w [8]

Definicja 24 Linkowalność (Linkability) Niech L stanowi zbioacuter wszystkich kluczy publicznych w danym ustawieniu (np w danym łańcuchu blokowym - blockchainie) System składania podpisoacutew MLSAG w L jest połączony z obrazami kluczy jeżeli prawdopodobieństwo że

adwersarz A utworzy w PPT dwa podpisy σ σ1 podpisane w odniesieniu do wektoroacutew kluczy

oraz 1 z ktoacuterych każdy będzie zawierać ten sam klucz publiczny yi = yirsquo W L oraz każdy będzie weryfikowany bez oznaczenia jako duplikat jest pomijalne

Definicja 25 Dwuznaczność sygnatariusza (Signer Ambiguity) System składania podpisoacutew MLSAG uważa się za niejednoznacznie identyfikujący sygnatariusza jeżeli mamy dany podpis weryfikujący σ na wektorach kluczy oraz dowolny zbioacuter kluczy prywatnych t z ktoacuterych każdy będzie mieć oddzielny indeks oraz sekretny indeks w takiej sytuacji prawdopodobieństwo odgadnięcia klucza sekretnego wynosi mniej niż

Dowody potwierdzające powyższe definicje przedstawiono w Załączniku

3 Zarys historyczny transakcji poufnych31 Transakcje poufne w ramach system Bitcoin

W [11] Greg Maxwell opisuje transakcje poufne ktoacutere są pewną metodą przekazywania transakcji w systemie Bitcoin przy jednoczesnym maskowaniu kwot Podstawową kwestią jest stosowanie schematu zobowiązań Pedersena metoda ta jest doskonale opisana w cytowanym materiale źroacutedłowym W niniejszym opracowaniu wprowadzam drobną modyfikację do mechaniki Transakcji Poufnych polegającą na wybieraniu zamiast zobowiązań ktoacuterych suma wynosi zero opcji złożenia podpisu pod zobowiązaniem w celu wykazania że klucz prywatny jest mi znany Schemat ten jest opisany szczegoacutełowo w kolejnym rozdziale

32 Modyfikacja pod kątem podpisoacutew pierścieniowych Niech G stanowi punkt bazowy ed25519 Niech [3]

H = toPoint (cn_fast_hasz (G))

Należy podkreślić że nie każda wartość haszująca pozwala obliczyć punkt w ramach grupy punktu bazowego (tzn dla pewnej niewiadomej) (co jest sprzeczne z tym co dzieje się w secp256k1 krzywej wykorzystywanej w systemie Bitcoin) Nie mniej jednak wydaje się że wyboacuter punktu bazowego jako takiego (wcześniej wykorzystywałem H(123456G) sprawdza się co z resztą wydawało mi się bardziej bezpieczne przy czym punkt bazowy jest z pewnością bardziej naturalnym wyborem) Wyboacuter H = ϒG dla pewnej niewiadomej jest konieczny po to aby pełna matematyka zwykłych krzywych eliptycznych zachowała swoją ważność

[3] H = MiniNerogetHForCT() w kontekście kodu w [14]

Przy założeniu logarytmoacutew dyskretnych w ed25519 prawdopodobieństwo że adwersarz odkryje ϒ jest pomijalne Należy zdefiniować C (a x) = xG+aH zobowiązanie wartości a z maską x Należy podkreślić że tak długo jak wartość logGH nie jest znana oraz jeżeli σ ne 0 to logGC (a x) pozostaje wartością nieznaną Z drugiej strony jeżeli a = 0 to logGC (a x) = x a zatem istnieje możliwość złożenia podpisu za pomocą pary kluczy sk-pk (xC (0 x)) W [11] istnieją dane wejściowe I wyjściowe zobowiązań a sieć sprawdza czy

sumdane wejściowe = sumdane wyjściowe

Nie mniej jednak nie jest to wystarczające w przypadku systemu Monero ponieważ dana transakcja zawiera roacuteżne możliwe do realizacji dane wejściowe Pi i = 1 hellip n z ktoacuterych tylko jedna należa do nadawcy (patrz [16 44]) to jeżeli będziemy w stanie sprawdzić powyższe roacutewnanie to musi być możliwe aby sieć widziała ktoacutere Pi należy do nadawcy transakcji Nie jest to zjawisko pożądane ponieważ eliminuje anonimowość zbudowaną dzięki podpisowi pierścieniowemu W związku z tym zastępczo tworzy się zobowiązania dla danych wejściowych oraz wyjściowych zgodnie z poniższym (załoacuteżmy najpierw że istnieje tylko jeden zestaw danych wejściowych)

Cin = xcG + aHCout10485761 = y1G + b1HCout10485762 = y2G + b2H

W taki sposoacuteb że xc = y1+y2+z xc - y1 - y2 = z yi są wartościami maskującymi z gt 0 oraz a = b1+b2W tym przypadku xc stanowi szczegoacutelny prywatny klucz a ldquokwota kluczardquo znana jest tylko nadawcy oraz osobie do ktoacuterej coiny są wysyłane zatem musi być odmienna od normalnego klucza prywatnego W takim przypadku

= xcG + aH - y1G - b1H - y2G - b2H= zG

A zatem powyższe roacutewnanie staje się zobowiązaniem do 0 przy sk = z oraz pk = zG a nie rzeczywistym roacutewnaniem o sumie zerowej Należy podkreślić że z nie jest wyliczalne dla coinoacutew źroacutedłowych xc chyba że znana jest zaroacutewno wartość y1 jak i y2 nie mniej jednak nawet to można w prosty sposoacuteb złagodzić poprzez uwzględnienie dodatkowych adresoacutew zmiany (zwykły przypadek zakłada że drugie zobowiązanie z wartością y2 jako maską są wysyłane jako zmiana)Ponieważ podawanie informacji ktoacutere dane wejściowe należą do nadawcy nie jest pożądane podpis pierścieniowy zawierający wszystkie zobowiązania wejściowe Ci i = 1 hellip s hellip n (gdzie s stanowi sekretny indeks zobowiązania nadawcy) dodaje się odpowiedni klucz publiczny (dzięki czemu zobowiązania oraz klucze publiczne są parowane (Ci Pi) ale tylko takie ktoacutere mogą być wspoacutelnie wydatkowane) oraz odejmuje sumCout

Jest to podpis pierścieniowy ktoacutery może być złożony ponieważ znamy jeden z prywatnych kluczy (a mianowicie z + xrsquo zawierający z jak wyżej oraz xrsquoG = Ps) Tak naprawdę ponieważ wiemy że dla każdego i zaroacutewno klucze prywatne dla Pi jak i klucze prywatne dla Pi + Ciin - sumjCjout możemy złożyć podpis zgodnie z treścią rozdziału 22 Szczegoacuteły tej procedury są opisane w Definicji 41

Zgodnie z [11] ważne jest udowodnienie że kwoty wyjściowe [4] b1 hellip bn wszystkie mieszczą się w szeregu wartości dodatnich np (0 216) Można to osiągnąć zasadniczo w taki sam sposoacuteb jak w [11] kwestia ta jest bardziej szczegoacutełowo opisana w części 5Na koniec warto zauważyć że w powyższej dyskusji nie wspomniałem o właściwości związanej dołączaniem tagoacutew ktoacutera jest wykorzystywana w Monero oraz Cryptonote w celu zapobiegania podwoacutejnemu wydatkowaniu środkoacutew Dołączanie tagoacutew w tym momencie będzie skutkiem łączenia powyższego omoacutewienia z podpisami MLSAG o ktoacuterych mowa w Definicji 41

4 Ring CT dla protokołu Monero 41 Opis protokołuDefinicja 41 (Tagowalny pierścień CT z mnogimi danymi wejściowymi oraz kluczami jednorazowymi)

Niech stanowi zbioacuter adresoacutew oraz kluczy jednorazowychzobowiązań ktoacuterym odpowiadają sekretne klucze xj j = 1 hellip m

Znaleźć zbiory q + 1 i = 1 hellip q + 1 ktoacutere nie są połączone tagami w sensie [ 6 strona 6]

Należy określić zestaw adresoacutew wyjściowych (Qi Ciout) takich że

stanowią zobowiązania o wartości zero Niech

hellip

stanowi uogoacutelniony pierścień w ktoacuterym chcemy złożyć swoacutej podpis Należy zauważyć że ostatnia kolumna to pierścień Ring-CT w rozumieniu rozdziału 4

Obliczyć podpis MLSAG sum na R

[4] Ponieważ zobowiązania wejściowe mogą być potencjalnie odziedziczone z poprzednich transakcji wystarczy rozważyć kwoty wyjściowe

W takim przypadku zgodnie z teorematem A2 nie może być sygnatariuszem żadnych dodatkowych niezlinkowanych podpisoacutew pierścieniowych w danym nadzbiorze P wszystkich takich par P = (PC) po podpisaniu sum

Uwaga 42 Złożoność przestrzeni powyższego protokołu Warto zauważyć że rozmiar podpisu sum na R zgodnie z definicją 41 jest w rzeczywistości mniejszy dla m gt 1 niż bieżący podpis pierścieniowy transakcji opartej na protokole CryptoNote [16] ktoacutera zawiera mnogie dane wejściowe Dzieje się tak dzięki wprowadzeniu zmian w rozmiarze w [8] do każdej kolumny Należy także podkreślić że prawdopodobnie nie jest konieczne umieszczanie obrazu klucza zobowiązania związanego z wyżej wymienionym podpisem Kolejne optymalizacje rozmiaru są możliwe i można je wykonać w podobny sposoacuteb

42 Konwersja widocznych denominacji na zobowiązaniaPonieważ Monero obecnie wykorzystuje blockchainowe widoczne skalary w celu stworzenia reprezentacji kwot ważne jest aby istniała możliwość (i sposoacuteb) konwersji z kwot widocznych na zobowiązania przy jednoczesnym zachowaniu anonimowości Tak naprawdę wcale nie jest to trudne Mając daną parę (P a) gdzie P jest kluczem publicznym a a stanowi kwotę może ona być wykorzystana jako dane wejściowe transakcji jako (P aH) i transakcja ta musi być zweryfikowana przez weryfikatora pod kątem kwoty wejściowej i jej przemnożenia przez punkt maskujący H oraz czy uzyskana wartość rzeczywiście wynosi aH Zatem jako pierwszy krok kwoty wejściowe nie zostaną ukryte ale ukryte zostaną dane wyjściowe transakcji oraz wszelkie niezbędne relacje o ktoacuterych mowa w rozdziale 4 pozostają ważne Należy podkreślić że range proof nie jest konieczny dla tych danych wejściowych

Uwaga 43 Oczywistą zaletą tej metody jest konwersja z kwot widocznych na zobowiązania oraz to że kwota coinoacutew wygenerowanych w procesie wydobycia jest weryfikowalna bez konieczności udziału elementu zaufanego Jest to przewaga protokołu Ring CT nad systemami płatniczymi takimi jak [4] ktoacutere obejmują fazę ustawień strony zaufanej

43 Opłaty transakcyjnePonieważ system Monero jest silnie zdecentralizowany (tzn proof of work) konieczne jest wynagradzanie goacuternikoacutew i dokonywanie opłat za każdą transakcję Pomaga to podnieść bezpieczeństwo sieci i zapobiegać rozdęcia blockchainu Opłaty te muszą być realizowane w postaci niezamaskowanej tzn Jako bH a nie xG + bH oraz w odniesieniu do pewnej standardowej kwoty b w taki sposoacuteb że goacuternik będzie moacutegł zweryfikować że b ∙ H = bH i tym samym że jest dość środkoacutew na opłatę transakcyjną przy jednoczesnym zachowaniu roacutewnań związanych z H w taki sposoacuteb że zostaną zachowane niezbędne relacje o ktoacuterych mowa w Rozdziale 4

44 Ring MultisignatureWarto zauważyć że prosta wersja t z m z n ring-multisignature [mnogich podpisoacutew pierścieniowych] może być zrealizowana w oparciu o podpisy MLSAG Umożliwia to grupie m uczestnikoacutew zbudowanie multisignature takiego że t uczestnikoacutew z liczby z m musi złożyć podpis aby był on uznany za ważny dodatkowo jest on dwuznaczny w odniesieniu do sygnatariusza klucze m są uczestnikami mieszczącymi się w ogoacutelnej liczbie n kluczy

Liczba n uczestnikoacutew w multisignature stanowi wspoacutelny sekret xe oraz klucz publiczny Pe ktoacutere mają wspoacutelne obrazy kluczy multisig

Ij = xeH(PejPj)

z Pj ndash publicznym kluczem uczestnika Każdy uczestnik multisignature dokonuje wyboru dodatkowych kluczy publicznych n -

m w blockchainie oraz tworzy podpis MLSAG za pomocą pierwszego rzędu wszystkich kluczy n a drugi rząd ma dla każdego wpisu (elementu) klucz wspoacutelny Pe

Każdy sygnatariusz multisignature podaje początkowe Ij j = 1 hellip m w celu umożliwienia zaakceptowania klucza po przekazaniu podpisoacutew weryfikujących t w blockchainie z ktoacuterych każdy odpowiada jednemu obrazowi klucza Ij

Rozszerzony zapis ring-multisignature jest w fazie opracowania

5 Zagregowane schematy identyfikacji Schnorra (Aggregate Schnorr Range Proofs)W części [11] poufne transakcja bez podpisu pierścieniowego wykorzystuje pewien typ podpisu pierścieniowego oparty na [1] nazywany podpisem pierścienia boromejskiego (Borromean ring signature) i pomaga zidentyfikować przekłamania w wartości zobowiązań w pewnym przedziale W niniejszym artykule postaram się nakreślić alternatywną metodę zainspirowaną przez [7] ktoacutera pozwala na uzyskanie tych samych oszczędności w zakresie przestrzeni ale za to opatrzona jest nieco mniej skomplikowanym protokołem bezpieczeństwa Motywacja do tego typu działania jest następująca przypuśćmy że dana transakcja ma dane wejściowe zobowiązań roacutewne

Cin = ainG + 10H

oraz zobowiązania wyjściowe

Cout 1 = aout1G + 5H Cout2 = aout2G + 5H

Scenariusz ten zachowuje ważność gdyż istnieje możliwość złożenia podpisu dla Cin ndash Cout1 ndash Cout2 = (ain ndash aout1 ndash aout2)G

Nie mniej jednak warto podkreślić że (bez range proofs) będzie istniała możliwość alternatywnego ustawienia zobowiązań wyjściowych

Cout1 = aout1G- H Cout2 = aout2G + 11H

Ponieważ -1 jest bardzo dużą liczbą stanowiącą modulo porządkujące grupę krzywej tym samym zostały utworzone darmowe pieniądze Zatem konieczne jest wykazanie że Couti są zobowiązaniami w odniesieniu do wartości ktoacutere są pozytywne (dodatnie) i mieszczą się w ograniczonym przedziale [0 2n] dla niektoacuterych wartości n Aby tego dokonać należy rozłożyć każdą wartość wyjściową na elementy binarne

co pozwala obliczyć zobowiązania do bj ∙ 2j w taki sposoacuteb że

Na koniec wykorzystując sekretny klucz bj można obliczyć podpis pierścieniowy na

dla wszystkich j oraz zapewnia dla weryfikatoroacutew (w tym przypadku goacuternikoacutew)Jeżeli chodzi o oszczędności miejsca można albo wykorzystać boromejski podpis pierścieniowy (podobnie jak w [11]) albo połączyć wszystkie proste podpisy pierścieniowe bądź utworzyć pewien typ zagregowanego podpisu pierścieniowego zdefiniowanego w następujący sposoacuteb

501 Generowanie zagregowanego nielinkowanego podpisu pierścieniowego Schnorra (Aggregate Schnorr Non-linkable Ring Signature) (ASNL)

Niech stanowi zbioacuter kluczy j = 1hellip z jako sekretnym kluczem

Dla każdego j niech Irsquo = i + 1 mod 2 ustawić skalar losowy aj i obliczyć

Ustawić gdzie Hs to kryptograficzna funkcja haszująca zwracająca skalar po dokonaniu wyboru losowego obliczyć

Określić i obliczyć

Zwroacutecić dla wszystkich j i s =

502 Weryfikacja zagregowanego nielinkowalnego podpisu pierścieniowego Schnorra (ASNL)Zacznijmy od dla j = 1hellip n oraz s

Dla wszystkich j obliczyć oraz

Jeżeli to otrzymamy 0 dla ważnego podpisuW przeciwnym razie otrzymamy wartość zwrotną -1

Teoremat 51 Zagregowany nielinkowany podpis pierścieniowy Schnorra nie może być sfałszowany przy założeniu logarytmu dyskretnego

Dowoacuted Przedstawiam szkic dowodu w przypadku n = 2 Przypadek ogoacutelny ma zbliżony charakter Przypuśćmy że adwersarz A jest w stanie sfałszować podpis ASNL na

Przy pomijalnym prawdopodobieństwie znając najwyżej jedną z (przypuśćmy że bez straty ogoacutelnego charakteru założenia że A zna ) Dla każdego danego fałszu

rozwiązuję roacutewnanie logarytmu dyskretnego o niepomijalnym prawdopodobieństwie Po zastosowaniu algorytmu weryfikacji niech Zatem prawdziwe musi być roacutewnanie

Przypuśćmy że oraz a a b są znane A wtedy

ponieważ jest określone protokołem weryfikacji musi być zatem prawdą że A zna klucz

prywatny

=Jest to w sprzeczności z założeniem logarytmu dyskretnego dla danej grupy

51 Reprezentacja kwotKwoty w protokole Ring CT można przedstawiać w sposoacuteb zbliżony do tego ktoacutery przedstawiony został w [11] z drobną modyfikacją w celu dopasowania do systemu Monero Coiny CryptoNote organizują nominały coinoacutew w bazie indeksoacutew w taki sposoacuteb aby mogły być ułożone w porządku występowania jako dane wejściowe dla podpisoacutew pierścieniowych Ponieważ wszystkie wartości coinoacutew w CryptoNote są reprezentowane w postaci 64-bitowych niepodpisanych liczb całkowitych możemy wykorzystać range proof na przestrzeni całego rejestru w celu zakodowania kwoty wyjściowej przekazywanej odbiorcy Na szczęście to także umożliwia wzajemne miksowanie danych wyjściowych zatem wymagany jest tylko jeden indeks danych wyjściowych w porządku rejestracji Przedział weryfikacji (range proof) wynosi ok 5 kilobajtoacutew Podpisy pierścieniowe dla danych wejściowych stają się bardziej odporne na analizę ponieważ anonimowość jest bardzo rozszerzonaPodczas gdy obszary weryfikacji (range proofs) są duże wykorzystywanie układu haszującego ktoacutery dodaje przedrostek do transakcji (zaroacutewno indeksoacutew wejściowych jak i wyjściowych) i przechowuje szeroki zakres range proof wraz z podpisami umożliwia oddzielnie uzyskanie ogromnych oszczędności przestrzeni podczas synchronizacji (syncing) do punktu weryfikacji lub działanie jako węzeł SPV Podobnie do elementoacutew bocznych łańcucha (Sidechains Elements) [12] będziemy przechowywać H(H(prefiks)||H(podpisy)) w drzewie Merkla Następnie węzły syncing do zaufanego punktu weryfikacji muszą jedynie pobrać przedrostek i dodać wartość haszującą do podpisoacutew skutecznie redukując szerokość wiązki Ponieważ prefiks transakcji wykorzystuje wariant dla danych wyjściowych ktoacutere wymienia w swoich podpisach pierścieniowych oraz środkach zapisanych do jednego klucza publicznego stanowi on miniaturowe poroacutewnanie do danych podpisoacutew pierścieniowych w danych wyjściowych oraz range proofs

Następnie podpisy pierścieniowe mogą nawet być przycięte z bazy danych przez niektoacutere węzły w celu uzyskania dalszych zyskoacutew przestrzeni przechowując zastępczo jedynie względnie mały zbioacuter UTXO

511 Przekazywanie informacji o kwotach OdbiorcyObecnie mając dowolną kwotę wyjściową b = b020 + b121 + ∙∙∙ bn2n nadawca oblicza nową prywatnąpubliczną parę kluczy oraz związane wymieniane sekrety ECDH ss oraz udostępnia następujące informacje w swojej transakcji

gdzie ai to losowo wybrane liczby dla j = 0 hellipn Dane Klucz publiczny ECDH oraz a + ss mod l gdzie a = a0 + hellip + an

Następnie odbiorca Oblicza udostępniany sekret ss oraz oblicza a na podstawie a + ss mod l Oblicza C = sumCi oblicza C ndash aG = bH oraz oblicza b poroacutewnując uzyskane wartości do

wszystkich bH w danym przedziale [0 2n] (W praktyce będzie to szybkie 500 kilobajtowe wyszukanie w n = 12 podobnie jak w poprzednim rozdziale Gdyby jednak wartość 232 została wybrana jako goacuterna wartość graniczna podobnie jak w [11] wyszukiwanie stałoby się dużym obliczeniowo wysiłkiem)

6 WnioskiProtokoacuteł pierścieniowych transakcji poufnych (Ring Confidential Transactions) to bardzo silnie zdecentralizowana kryptowaluta (tzn nie ma w niej żadnej uprzywilejowanej strony) ktoacutera posiada proste do udowodnienia wartości szacunkowe zabezpieczeń dotyczące ukrywania kwot transferoacutew ich źroacutedeł oraz odbiorcoacutew Dodatkowo generowanie coinoacutew w oparciu o protokoacuteł Ring Confidential Transactions nie wymaga obecności czynnika zaufanego i proces jego weryfikacji jest całkowicie bezpiecznyTych pięć czynnikoacutew jest niezbędnych w przypadku kryptowalut zbliżonych do środkoacutew gotoacutewkowych takich jak MoneroBibliografia1 Masayuki Abe Miyako Ohkubo and Koutarou Suzuki 1-out-of-n signatures from a variety of keys Advances in CryptologyAsiacrypt 2002 pages 415ndash432 20022 Adam Back Bitcoins with homomorphic value (validatable but encrypted)httpsbitcointalkorgindexphptopic=3057910 2013 [Online accessed 1-May-2015]3 Adam Back Podpis pierścieniowy efficiency httpsbitcointalkorgindexphptopic=972541msg10619684msg10619684 2015 [Online accessed 1-May-2015]4 Eli Ben Sasson Alessandro Chiesa Christina Garman Matthew Green Ian Miers Eran Tromer and Madars Virza Zerocash Decentralized anonymous payments from bitcoin In Security and Privacy (SP) 2014 IEEE Symposium on pages 459ndash474 IEEE 20145 Evan Duffield and Kyle Hagan Darkcoin Peertopeer cryptocurrency with anonymous blockchain transactions and an improved proofofwork system 20146 Eiichiro Fujisaki and Koutarou Suzuki Traceable podpis pierścieniowy In Public Key CryptographyndashPKC 2007 pages 181ndash200 Springer 20077 Javier Herranz Aggregate signatures httpwwwiiiacsices~jherranzpapersNijmegen_seminar_aggregatepdf oct 20058 Joseph K Liu Victor K Wei and Duncan S Wong Linkable spontaneous anonymous group signature for ad hoc groups In Information Security and Privacy pages 325ndash335 Springer 20049 Adam Mackenzie Surae Noether and Monero Core Team Improving obfuscation in the cryptonote protocol httpslabgetmoneroorgpubsMRL-0004pdf January 201510 Greg Maxwell Coinjoin Bitcoin privacy for the real world august 2013 Bitcoin Forum httpsbitcointalkorgindexphptopic=2792490 2013 [Online accessed 1-July-2015]11 Greg Maxwell Confidential Transactions httpspeoplexiphorg~gregconfidential_valuestxt 2015 [Online accessed 1-June-2015]12 Greg Maxwell Elements project httpsgithubcomShenNoetherMiniNero 201513 Satoshi Nakamoto Bitcoin A peer-to-peer electronic cash system Consulted 1(2012)28 200814 Shen Noether Mininero httpsgithubcomShenNoetherMiniNero 201515 Ronald L Rivest Adi Shamir and Yael Tauman How to leak a secret In Advances in CryptologyASIACRYPT 2001 pages 552ndash565 Springer 200116 Nicolas van Saberhagen Cryptonote v 2 0 HYPERLINK https cryptonote org whitepaper pdf 2013

Załącznik A Załącznik Security ProofsA1 Brak możliwości sfałszowania MLSAG

Obliczenia przebiegają analogicznie do [8 Teoremat 1] Niech H1 oraz H2 będą losowo wybranymi oracle a SO stanowią podpisy oracle zwracające ważne podpisy MLSAG Załoacuteżmy że istnieje probabilistyczny wielomianowy adwersarz czasowy (PPT) A ktoacutery posiada zdolność sfałszowania MLSAG z listy wektoroacutew kluczy L przy prawdopodobieństwie ktoacuterego nie można pominąć

Gdzie Q1 stanowi wielomianowy parametr bezpieczeństwa k oraz gdzie (m σ) nie stanowi jednego z podpisoacutew zwracanych przez SO Załoacuteżmy że A nie wysyła więcej niż qH + nqS

(gdzie n oznacza liczbę kluczy w L) zapytań dotyczących podpisoacutew oracle H1H2 oraz SO odpowiednio Podpisy oracle H1 oraz H2 uważa się za niezależne i losowe oraz spoacutejne z danymi zapytaniami powtarzającymi się Podpis oracle SO może składać zapytanie H1 oraz H2 Mając wartość A wykaże że istnieje możliwość utworzenia adwersarza M w PPT ktoacutery będzie wykorzystywać A w celu znalezienia logarytmu dyskretnego jednego z kluczy w L

Jeżeli L stanowi zbioacuter kluczy wektoroacutew z ktoacuterych każdy będzie mieć wielkość r (tzn z kluczami publicznymi y1 hellip yr ) to wygenerowany fałszywy podpis

Wygenerowany przez A musi spełniać warunek

Gdzie i są obliczone w ramach mod n oraz są zdefiniowane zgodnie z Rozdziałem 22 Nowy adwersarz M może wykorzystać A w celu sfałszowania podpisoacutew wielomianową liczbę razy i zapisze każdy skrypt Turinga T niezależnie czy sfałszowanie było skuteczne czy nie

Lemma A1 [8 Lemma 1] Niech M wywołuje A w celu uzyskania transkrypcji T Jeżeli T jest skuteczne to M powraca do T do nagłoacutewka H i następnie re-symuluje A w celu uzyskania transkrypcji Trsquo Jeżeli Pr (T okaże się skuteczne) = ϵ to Pr (Trsquo jest skuteczne) = ϵ

Dowoacuted wynika wprost z przywołanego teorematu

Teoremat A2 Prawdopodobieństwo że adwersarz A sfałszuje podpis MLSAG można pominąć przy założeniu logarytmu dyskretnego

Dowoacuted Do przeprowadzenia dowodu będę stosować notację przedstawioną powyżej Podobnie jak w przypadku [8 teoremat 1] ponieważ prawdopodobieństwo odgadnięcia danych wyjściowych z losowego oracle jest znikome w związku z tym dla każdego skutecznego oszustwa A wprowadza transkrypcję uzupełniającą T a zatem mamy mT zapytań w przypadku zapytań do H1 odpowiadających liczbie n zapytań wykorzystywanych w celu weryfikacji podpisu W związku z tym niech Xi1 hellip Xim oznacza zapytania wykorzystywane w procesie weryfikacji fałszu ith oraz niech π oznacza indeks odpowiadający ostatniemu zapytaniu weryfikacyjnego dla danego oszustwa

(Intuicyjnie π odpowiada temu co może stanowić indeks sekretny fałszywego podpisu ponieważ odpowiada on ostatniemu wezwaniu ostatniemu wywołaniu losowego oracle dla danego odpisu)Proacuteba sfałszowania σ podjęta przez A stanowi fałsz (l π) jeżeli i1 = l oraz π jest zgodne z powyższym (zatem fałsz odpowiada zapytaniom l do l + π) Z założenia istnieje para (l π) taka że prawdopodobieństwo związanej transkrypcji T daje skutecznie wygenerowany fałszywy klucz ϵlπ (T) spełnia warunek

1

Teraz przeglądając T do wartości przed zapytaniem l-tym a następnie podejmując proacutebę sfałszowania za pomocą tego samego zbioru kluczy (oraz dopuszczając aby H1 obliczyło nowe rzuty monetami dla wszystkich kolejnych zapytań) z Lemmy A1 wynika że prawdopodobieństwo że Trsquo jest także skuteczne spełnia warunki

_Dlatego prawdopodobieństwo że zaroacutewno T jak i Trsquo odpowiadają weryfikacjom fałszywym σ i σ1 nie może zostać pominięte

Ponieważ nowe rzuty monetami zostały obliczone na podstawie danych wyjściowych losowych oracle H1 oznacza to że przy dużym prawdopodobieństwie istnieje wartość j taka

że oraz W związku z tym możemy rozwiązać klucz prywatny z indeksem π

ktoacutery jest sprzeczny z założeniami logarytmu dyskretnego

A2 Linkowalność MLSAG Teoremat A3 Linkowalność obrazu klucza (Key-Image Linkability) Prawdopodobieństwo że adwersarz a w PPT może utworzyć dwa podpisy weryfikujące (niepołączone w danym

ustawieniu σ σrsquo podpisane w odniesieniu do wektoroacutew kluczy oraz odpowiednio w taki

sposoacuteb że będzie istnieć klucz publiczny i w obu oraz może być pominięte

Dowoacuted Przypuśćmy że w przeciwieństwie do tego co zostało wcześniej powiedziane A utworzył dwa podpisy weryfikujące σ oraz σrsquo o oba są podpisami w odniesieniu do kluczowych wektoroacutew

oraz odpowiednio w taki sposoacuteb że istnieje klucz publiczny y zaroacutewno w jak i

Niech y występuje jako element j należący do a jrsquo jako element należący do rsquo Z teorematu A2 wynika z dużym prawdopodobieństwem że istnieją indeksy π oraz πrsquo dla kluczy publicznych σ oraz σrsquo odpowiednio takie że

oraz

z

oraz

Jeżeli uznamy że x oznacza klucz prywatny y y = xG to po rozwiązaniu powyższego dla Ij

oraz Ij0rsquo mamy następujące roacutewnania oraz podobnie Ijrsquo = xH (y) Tym samym dwa podpisy obejmują Ij = Ijrsquo i w związku z tym ponieważ zduplikowane obrazy kluczy są odrzucone jeden z nich nie może być wykorzystany do weryfikacji

A3 Anonimowość MLSAG W celu udowodnienia anonimowości powyższego protokołu w losowym modelu oracle przyjmijmy że H1 H2 to losowe oracle modelujące dyskretne funkcje haszujące Niech A to adwersarz anonimowości Buduję adwersarza M względem założenia problemu decyzyjnego Diffie Helmana (DDH) zgodnie z poniższym Założenie DDH stwierdza że mając daną krotność (G aG bG ϒG) prawdopodobieństwo ustalenia czy G = abG jest znikome

Teoremat A4 Protokoacuteł pierścieniowy CT jest dwuznaczny w odniesieniu do sygnatariusza przy założeniu problemu decyzyjnego Diffie-HelmanaDowoacuted (zbliżony do dowodu [8 Teoremat 2]) Załoacuteżmy że problem decyzyjny Diffie-Helmana jest trudny w cyklicznej grupie generowanej przez G i załoacuteżmy że istnieje adwersarz A w czasie PPT względem dwuznaczności sygnatariusza Tym samym mając listę L n wektoroacutew

kluczy publicznych o długości m oraz zbioacuter prywatnych kluczy t ważny podpis σ na L podpisany przez użytkownika w odniesieniu do wektora klucza y taki że

odpowiedni wektor klucza prywatnego wynosi spełnia to A może zdeterminować π z prawdopodobieństwem

Dla wybranych wielomianoacutew Q(k) Buduję adwersarza PPT M ktoacutery wykorzystuje krotność danych wejściowych (G aG bG ciG) gdzie I ϵ 0 1 jest losowo wybrany (a nie znany M a priori) c1 = ab oraz c0 jest losowym skalarem a dane wyjściowe i mają prawdopodobieństwo

Dla niektoacuterych wielomianoacutew Q2 (k)Należy rozważyć algorytm SIMNIZKP (zbliżony to tego ktoacutery został zdefiniowany w [6]) ktoacutery jako skalary wejściowe wykorzystuje wektor x klucza prywatnego zbioacuter wektoroacutew kluczy

publicznych indeks π oraz wiadomość m i ktoacutery działa w sposoacuteb następujący1 Wygenerować skalary losowe s1 hellip sm oraz skalar losowy cπ lt- H2 Dla j indeksującego określić

A dla pozostałych j

3 Obliczyć losowe dane wyjściowe na podstawie losowego oracle

4 Dla każdego i roboczego mod m obliczyć

Należy podkreślić że w ostatnim punkcie kiedy i = π - 1 to ci+1 jest już określone w celu utrzymania spoacutejności z losowymi danymi wyjściowymi oracleNależy podkreślić że niezależnie od tego czy jest rzeczywistym kluczem prywatnym odpowiadającym ze względu na to że spoacutejność jest zachowywana przez losowe wartości oracle w kolejnych wezwaniach powyższy podpis jest weryfikowany Jeżeli x jest rzeczywiście wektorem klucza prywatnego y to nie ma roacuteżnicy pomiędzy SIMNIZKP oraz rzeczywistym podpisemNa koniec mając krotność (G aG bG ciG) gdzie a b są losowo wybrany skalarami a c1 = ab c0 elementem losowym i ϵ 0 1 M zachodzi w poniższych krokach i pozwala rozwiązać problem decyzyjny Diffie Helmana za pomocą niepomijalnego prawdopodobieństwa M wychwytuje losowe ϒ lt-H z losowej wartości oracle oraz pobiera parę wektoroacutew klucza prywatnego publicznego (x y) a następnie oblicza s jako a = s + ϒx Teraz M wykonuje

SIMNIZKP za pomocą dowolnie wybranych wektoroacutew kluczy w taki sposoacuteb że w danej wiadomości m oraz Jeżeli prawdziwe jest że i = 1 to c = ab oraz logGaG = logbGcG = a

z uwagi na to że zakłada się iż A jest w stanie znaleźć π z prawdopodobieństwem ktoacuterego nie można pominąć to istnieje niepomijalne prawdopodobieństwo frac12 że A zwroacuteci 1 (i wtedy M zwroacuteci 1) Jeżeli i = 0 to A zwraca 1 wyłącznie z prawdopodobieństwem frac12 a zatem dla niektoacuterych niepomijanych prawdopodobieństw powyżej 1`2 M zwraca tę samą wartość co A i tym samym rozwiązuje problem decyzyjny Diffie-Helmana dla losowo wybranych skalaroacutew bez pomijalnego prawdopodobieństwa powyżej 12 co stanowi sprzeczność

Załącznik B Kod demo Ring CT W repozytorium w [14] zbudowałem prostą demonstrację protokołu poufnych transakcji pierścieniowych (Ring Confidential Transactions) wykorzystujących podpisy MLSAG w części 2 oraz podpisy ASNL w części 5

H_ct = RingCTgetHForCT()print(H H_ct)sr Pr = PaperWalletskpkGen() receivers private publicse pe ss = ecdhecdhgen(Pr) compute shared secret ssdigits = 14 in practice it will be 14print(inputs)Cia L1a s2a sa ska = RingCTgenRangeProof(10000 digits)print(outputs)Cib L1b s2b sb skb = RingCTgenRangeProof(7000 digits)Cic L1c s2c sc skc = RingCTgenRangeProof(3000 digits)print(verifying range proofs of outputs)RingCTverRangeProof(Cib L1b s2b sb)RingCTverRangeProof(Cic L1c s2c sc)x P1 = PaperWalletskpkGen()P2 = PaperWalletpkGen()C2 = PaperWalletpkGen()some random commitment grabbed from the blockchainind = 0Ca = RingCTsumCi(Cia)Cb = RingCTsumCi(Cib)Cc = RingCTsumCi(Cic)sk = [x MiniNerosc_sub_keys(ska MiniNerosc_add_keys(skb skc))]

pk = [[P1 P2] [MiniNerosubKeys(Ca MiniNeroaddKeys(Cb Cc)) MiniNerosubKeys(C2 MiniNeroaddKeys(Cb Cc)) ] ]II cc ssVal = MLSAGMLSAG_Sign(pk sk ind)print(Sig verified MLSAGMLSAG_Ver(pk II cc ssVal) )print(Finding received amount corresponding to Cib)RingCTComputeReceivedAmount(pe sr MiniNeroaddScalars(ss skb) Cib)print(Finding received amount corresponding to Cic)RingCTComputeReceivedAmount(pe sr MiniNeroaddScalars(ss skc) Cic)

Przykład transakcji z danymi wejściowymi 10 000 oraz wyjściowymi 3 000 i 7 000(rsquoHrsquo rsquo61fe7f0f5a607a33427d01dd1fded5ffa03fae2e9df9ebccf2e0a2f5bd77a204rsquo)inputs(rsquob b in binaryrsquo 10000 [0 0 0 0 1 0 0 0 1 1 1 0 0 1])Generating Aggregate Schnorr Non-linkable Podpis pierścieniowy outputs(rsquob b in binaryrsquo 7000 [0 0 0 1 1 0 1 0 1 1 0 1 1 0])Generating Aggregate Schnorr Non-linkable Podpis pierścieniowy (rsquob b in binaryrsquo 3000 [0 0 0 1 1 1 0 1 1 1 0 1 0 0])Generating Aggregate Schnorr Non-linkable Podpis pierścieniowy verifying range proofs of outputsVerifying Aggregate Schnorr Non-linkable Podpis pierścieniowy VerifiedVerifying Aggregate Schnorr Non-linkable Podpis pierścieniowy Verified(rsquoGenerating MLSAG sig of dimensions rsquo 2 rsquox rsquo 2)(rsquoverifying MLSAG sig of dimensions rsquo 2 rsquox rsquo 2)(rsquocrsquo[rsquo80a3cfd06dd2862307cd75c2a1566f20cd743dbb0b9feb22d79dcbecb9023f42rsquorsquoa9b7342ba7bf2f102505ca19dab734fde638916c0a29f5b30e49833ab51393earsquorsquo80a3cfd06dd2862307cd75c2a1566f20cd743dbb0b9feb22d79dcbecb9023f42rsquo])(rsquosig verifiesrsquo True)(rsquoSig verifiedrsquo True)Finding received amount corresponding to Cib(rsquoreceived rsquo 7000c Monero Research Lab Page 20 of 20rsquoa488ec68732fb551841c2c6dcc7ffac895d98ec7e9378275ed20ea12805fc18ersquo)Finding received amount corresponding to Cic(rsquoreceived rsquo3000rsquo1b46626858e130a0f3884c74c9fdeabc4d812c519103ea16a35a3f82a3d0ed6drsquo)

W [11] Greg Maxwell opisuje transakcje poufne ktoacutere są pewną metodą przekazywania transakcji w systemie Bitcoin przy jednoczesnym maskowaniu kwot Podstawową kwestią jest stosowanie schematu zobowiązań Pedersena metoda ta jest doskonale opisana w cytowanym materiale źroacutedłowym W niniejszym opracowaniu wprowadzam drobną modyfikację do mechaniki Transakcji Poufnych polegającą na wybieraniu zamiast zobowiązań ktoacuterych suma wynosi zero opcji złożenia podpisu pod zobowiązaniem w celu wykazania że klucz prywatny jest mi znany Schemat ten jest opisany szczegoacutełowo w kolejnym rozdziale

32 Modyfikacja pod kątem podpisoacutew pierścieniowych Niech G stanowi punkt bazowy ed25519 Niech [3]

H = toPoint (cn_fast_hasz (G))

Należy podkreślić że nie każda wartość haszująca pozwala obliczyć punkt w ramach grupy punktu bazowego (tzn dla pewnej niewiadomej) (co jest sprzeczne z tym co dzieje się w secp256k1 krzywej wykorzystywanej w systemie Bitcoin) Nie mniej jednak wydaje się że wyboacuter punktu bazowego jako takiego (wcześniej wykorzystywałem H(123456G) sprawdza się co z resztą wydawało mi się bardziej bezpieczne przy czym punkt bazowy jest z pewnością bardziej naturalnym wyborem) Wyboacuter H = ϒG dla pewnej niewiadomej jest konieczny po to aby pełna matematyka zwykłych krzywych eliptycznych zachowała swoją ważność

[3] H = MiniNerogetHForCT() w kontekście kodu w [14]

Przy założeniu logarytmoacutew dyskretnych w ed25519 prawdopodobieństwo że adwersarz odkryje ϒ jest pomijalne Należy zdefiniować C (a x) = xG+aH zobowiązanie wartości a z maską x Należy podkreślić że tak długo jak wartość logGH nie jest znana oraz jeżeli σ ne 0 to logGC (a x) pozostaje wartością nieznaną Z drugiej strony jeżeli a = 0 to logGC (a x) = x a zatem istnieje możliwość złożenia podpisu za pomocą pary kluczy sk-pk (xC (0 x)) W [11] istnieją dane wejściowe I wyjściowe zobowiązań a sieć sprawdza czy

sumdane wejściowe = sumdane wyjściowe

Nie mniej jednak nie jest to wystarczające w przypadku systemu Monero ponieważ dana transakcja zawiera roacuteżne możliwe do realizacji dane wejściowe Pi i = 1 hellip n z ktoacuterych tylko jedna należa do nadawcy (patrz [16 44]) to jeżeli będziemy w stanie sprawdzić powyższe roacutewnanie to musi być możliwe aby sieć widziała ktoacutere Pi należy do nadawcy transakcji Nie jest to zjawisko pożądane ponieważ eliminuje anonimowość zbudowaną dzięki podpisowi pierścieniowemu W związku z tym zastępczo tworzy się zobowiązania dla danych wejściowych oraz wyjściowych zgodnie z poniższym (załoacuteżmy najpierw że istnieje tylko jeden zestaw danych wejściowych)

Cin = xcG + aHCout10485761 = y1G + b1HCout10485762 = y2G + b2H

W taki sposoacuteb że xc = y1+y2+z xc - y1 - y2 = z yi są wartościami maskującymi z gt 0 oraz a = b1+b2W tym przypadku xc stanowi szczegoacutelny prywatny klucz a ldquokwota kluczardquo znana jest tylko nadawcy oraz osobie do ktoacuterej coiny są wysyłane zatem musi być odmienna od normalnego klucza prywatnego W takim przypadku

= xcG + aH - y1G - b1H - y2G - b2H= zG

A zatem powyższe roacutewnanie staje się zobowiązaniem do 0 przy sk = z oraz pk = zG a nie rzeczywistym roacutewnaniem o sumie zerowej Należy podkreślić że z nie jest wyliczalne dla coinoacutew źroacutedłowych xc chyba że znana jest zaroacutewno wartość y1 jak i y2 nie mniej jednak nawet to można w prosty sposoacuteb złagodzić poprzez uwzględnienie dodatkowych adresoacutew zmiany (zwykły przypadek zakłada że drugie zobowiązanie z wartością y2 jako maską są wysyłane jako zmiana)Ponieważ podawanie informacji ktoacutere dane wejściowe należą do nadawcy nie jest pożądane podpis pierścieniowy zawierający wszystkie zobowiązania wejściowe Ci i = 1 hellip s hellip n (gdzie s stanowi sekretny indeks zobowiązania nadawcy) dodaje się odpowiedni klucz publiczny (dzięki czemu zobowiązania oraz klucze publiczne są parowane (Ci Pi) ale tylko takie ktoacutere mogą być wspoacutelnie wydatkowane) oraz odejmuje sumCout

Jest to podpis pierścieniowy ktoacutery może być złożony ponieważ znamy jeden z prywatnych kluczy (a mianowicie z + xrsquo zawierający z jak wyżej oraz xrsquoG = Ps) Tak naprawdę ponieważ wiemy że dla każdego i zaroacutewno klucze prywatne dla Pi jak i klucze prywatne dla Pi + Ciin - sumjCjout możemy złożyć podpis zgodnie z treścią rozdziału 22 Szczegoacuteły tej procedury są opisane w Definicji 41

Zgodnie z [11] ważne jest udowodnienie że kwoty wyjściowe [4] b1 hellip bn wszystkie mieszczą się w szeregu wartości dodatnich np (0 216) Można to osiągnąć zasadniczo w taki sam sposoacuteb jak w [11] kwestia ta jest bardziej szczegoacutełowo opisana w części 5Na koniec warto zauważyć że w powyższej dyskusji nie wspomniałem o właściwości związanej dołączaniem tagoacutew ktoacutera jest wykorzystywana w Monero oraz Cryptonote w celu zapobiegania podwoacutejnemu wydatkowaniu środkoacutew Dołączanie tagoacutew w tym momencie będzie skutkiem łączenia powyższego omoacutewienia z podpisami MLSAG o ktoacuterych mowa w Definicji 41

4 Ring CT dla protokołu Monero 41 Opis protokołuDefinicja 41 (Tagowalny pierścień CT z mnogimi danymi wejściowymi oraz kluczami jednorazowymi)

Niech stanowi zbioacuter adresoacutew oraz kluczy jednorazowychzobowiązań ktoacuterym odpowiadają sekretne klucze xj j = 1 hellip m

Znaleźć zbiory q + 1 i = 1 hellip q + 1 ktoacutere nie są połączone tagami w sensie [ 6 strona 6]

Należy określić zestaw adresoacutew wyjściowych (Qi Ciout) takich że

stanowią zobowiązania o wartości zero Niech

hellip

stanowi uogoacutelniony pierścień w ktoacuterym chcemy złożyć swoacutej podpis Należy zauważyć że ostatnia kolumna to pierścień Ring-CT w rozumieniu rozdziału 4

Obliczyć podpis MLSAG sum na R

[4] Ponieważ zobowiązania wejściowe mogą być potencjalnie odziedziczone z poprzednich transakcji wystarczy rozważyć kwoty wyjściowe

W takim przypadku zgodnie z teorematem A2 nie może być sygnatariuszem żadnych dodatkowych niezlinkowanych podpisoacutew pierścieniowych w danym nadzbiorze P wszystkich takich par P = (PC) po podpisaniu sum

Uwaga 42 Złożoność przestrzeni powyższego protokołu Warto zauważyć że rozmiar podpisu sum na R zgodnie z definicją 41 jest w rzeczywistości mniejszy dla m gt 1 niż bieżący podpis pierścieniowy transakcji opartej na protokole CryptoNote [16] ktoacutera zawiera mnogie dane wejściowe Dzieje się tak dzięki wprowadzeniu zmian w rozmiarze w [8] do każdej kolumny Należy także podkreślić że prawdopodobnie nie jest konieczne umieszczanie obrazu klucza zobowiązania związanego z wyżej wymienionym podpisem Kolejne optymalizacje rozmiaru są możliwe i można je wykonać w podobny sposoacuteb

42 Konwersja widocznych denominacji na zobowiązaniaPonieważ Monero obecnie wykorzystuje blockchainowe widoczne skalary w celu stworzenia reprezentacji kwot ważne jest aby istniała możliwość (i sposoacuteb) konwersji z kwot widocznych na zobowiązania przy jednoczesnym zachowaniu anonimowości Tak naprawdę wcale nie jest to trudne Mając daną parę (P a) gdzie P jest kluczem publicznym a a stanowi kwotę może ona być wykorzystana jako dane wejściowe transakcji jako (P aH) i transakcja ta musi być zweryfikowana przez weryfikatora pod kątem kwoty wejściowej i jej przemnożenia przez punkt maskujący H oraz czy uzyskana wartość rzeczywiście wynosi aH Zatem jako pierwszy krok kwoty wejściowe nie zostaną ukryte ale ukryte zostaną dane wyjściowe transakcji oraz wszelkie niezbędne relacje o ktoacuterych mowa w rozdziale 4 pozostają ważne Należy podkreślić że range proof nie jest konieczny dla tych danych wejściowych

Uwaga 43 Oczywistą zaletą tej metody jest konwersja z kwot widocznych na zobowiązania oraz to że kwota coinoacutew wygenerowanych w procesie wydobycia jest weryfikowalna bez konieczności udziału elementu zaufanego Jest to przewaga protokołu Ring CT nad systemami płatniczymi takimi jak [4] ktoacutere obejmują fazę ustawień strony zaufanej

43 Opłaty transakcyjnePonieważ system Monero jest silnie zdecentralizowany (tzn proof of work) konieczne jest wynagradzanie goacuternikoacutew i dokonywanie opłat za każdą transakcję Pomaga to podnieść bezpieczeństwo sieci i zapobiegać rozdęcia blockchainu Opłaty te muszą być realizowane w postaci niezamaskowanej tzn Jako bH a nie xG + bH oraz w odniesieniu do pewnej standardowej kwoty b w taki sposoacuteb że goacuternik będzie moacutegł zweryfikować że b ∙ H = bH i tym samym że jest dość środkoacutew na opłatę transakcyjną przy jednoczesnym zachowaniu roacutewnań związanych z H w taki sposoacuteb że zostaną zachowane niezbędne relacje o ktoacuterych mowa w Rozdziale 4

44 Ring MultisignatureWarto zauważyć że prosta wersja t z m z n ring-multisignature [mnogich podpisoacutew pierścieniowych] może być zrealizowana w oparciu o podpisy MLSAG Umożliwia to grupie m uczestnikoacutew zbudowanie multisignature takiego że t uczestnikoacutew z liczby z m musi złożyć podpis aby był on uznany za ważny dodatkowo jest on dwuznaczny w odniesieniu do sygnatariusza klucze m są uczestnikami mieszczącymi się w ogoacutelnej liczbie n kluczy

Liczba n uczestnikoacutew w multisignature stanowi wspoacutelny sekret xe oraz klucz publiczny Pe ktoacutere mają wspoacutelne obrazy kluczy multisig

Ij = xeH(PejPj)

z Pj ndash publicznym kluczem uczestnika Każdy uczestnik multisignature dokonuje wyboru dodatkowych kluczy publicznych n -

m w blockchainie oraz tworzy podpis MLSAG za pomocą pierwszego rzędu wszystkich kluczy n a drugi rząd ma dla każdego wpisu (elementu) klucz wspoacutelny Pe

Każdy sygnatariusz multisignature podaje początkowe Ij j = 1 hellip m w celu umożliwienia zaakceptowania klucza po przekazaniu podpisoacutew weryfikujących t w blockchainie z ktoacuterych każdy odpowiada jednemu obrazowi klucza Ij

Rozszerzony zapis ring-multisignature jest w fazie opracowania

5 Zagregowane schematy identyfikacji Schnorra (Aggregate Schnorr Range Proofs)W części [11] poufne transakcja bez podpisu pierścieniowego wykorzystuje pewien typ podpisu pierścieniowego oparty na [1] nazywany podpisem pierścienia boromejskiego (Borromean ring signature) i pomaga zidentyfikować przekłamania w wartości zobowiązań w pewnym przedziale W niniejszym artykule postaram się nakreślić alternatywną metodę zainspirowaną przez [7] ktoacutera pozwala na uzyskanie tych samych oszczędności w zakresie przestrzeni ale za to opatrzona jest nieco mniej skomplikowanym protokołem bezpieczeństwa Motywacja do tego typu działania jest następująca przypuśćmy że dana transakcja ma dane wejściowe zobowiązań roacutewne

Cin = ainG + 10H

oraz zobowiązania wyjściowe

Cout 1 = aout1G + 5H Cout2 = aout2G + 5H

Scenariusz ten zachowuje ważność gdyż istnieje możliwość złożenia podpisu dla Cin ndash Cout1 ndash Cout2 = (ain ndash aout1 ndash aout2)G

Nie mniej jednak warto podkreślić że (bez range proofs) będzie istniała możliwość alternatywnego ustawienia zobowiązań wyjściowych

Cout1 = aout1G- H Cout2 = aout2G + 11H

Ponieważ -1 jest bardzo dużą liczbą stanowiącą modulo porządkujące grupę krzywej tym samym zostały utworzone darmowe pieniądze Zatem konieczne jest wykazanie że Couti są zobowiązaniami w odniesieniu do wartości ktoacutere są pozytywne (dodatnie) i mieszczą się w ograniczonym przedziale [0 2n] dla niektoacuterych wartości n Aby tego dokonać należy rozłożyć każdą wartość wyjściową na elementy binarne

co pozwala obliczyć zobowiązania do bj ∙ 2j w taki sposoacuteb że

Na koniec wykorzystując sekretny klucz bj można obliczyć podpis pierścieniowy na

dla wszystkich j oraz zapewnia dla weryfikatoroacutew (w tym przypadku goacuternikoacutew)Jeżeli chodzi o oszczędności miejsca można albo wykorzystać boromejski podpis pierścieniowy (podobnie jak w [11]) albo połączyć wszystkie proste podpisy pierścieniowe bądź utworzyć pewien typ zagregowanego podpisu pierścieniowego zdefiniowanego w następujący sposoacuteb

501 Generowanie zagregowanego nielinkowanego podpisu pierścieniowego Schnorra (Aggregate Schnorr Non-linkable Ring Signature) (ASNL)

Niech stanowi zbioacuter kluczy j = 1hellip z jako sekretnym kluczem

Dla każdego j niech Irsquo = i + 1 mod 2 ustawić skalar losowy aj i obliczyć

Ustawić gdzie Hs to kryptograficzna funkcja haszująca zwracająca skalar po dokonaniu wyboru losowego obliczyć

Określić i obliczyć

Zwroacutecić dla wszystkich j i s =

502 Weryfikacja zagregowanego nielinkowalnego podpisu pierścieniowego Schnorra (ASNL)Zacznijmy od dla j = 1hellip n oraz s

Dla wszystkich j obliczyć oraz

Jeżeli to otrzymamy 0 dla ważnego podpisuW przeciwnym razie otrzymamy wartość zwrotną -1

Teoremat 51 Zagregowany nielinkowany podpis pierścieniowy Schnorra nie może być sfałszowany przy założeniu logarytmu dyskretnego

Dowoacuted Przedstawiam szkic dowodu w przypadku n = 2 Przypadek ogoacutelny ma zbliżony charakter Przypuśćmy że adwersarz A jest w stanie sfałszować podpis ASNL na

Przy pomijalnym prawdopodobieństwie znając najwyżej jedną z (przypuśćmy że bez straty ogoacutelnego charakteru założenia że A zna ) Dla każdego danego fałszu

rozwiązuję roacutewnanie logarytmu dyskretnego o niepomijalnym prawdopodobieństwie Po zastosowaniu algorytmu weryfikacji niech Zatem prawdziwe musi być roacutewnanie

Przypuśćmy że oraz a a b są znane A wtedy

ponieważ jest określone protokołem weryfikacji musi być zatem prawdą że A zna klucz

prywatny

=Jest to w sprzeczności z założeniem logarytmu dyskretnego dla danej grupy

51 Reprezentacja kwotKwoty w protokole Ring CT można przedstawiać w sposoacuteb zbliżony do tego ktoacutery przedstawiony został w [11] z drobną modyfikacją w celu dopasowania do systemu Monero Coiny CryptoNote organizują nominały coinoacutew w bazie indeksoacutew w taki sposoacuteb aby mogły być ułożone w porządku występowania jako dane wejściowe dla podpisoacutew pierścieniowych Ponieważ wszystkie wartości coinoacutew w CryptoNote są reprezentowane w postaci 64-bitowych niepodpisanych liczb całkowitych możemy wykorzystać range proof na przestrzeni całego rejestru w celu zakodowania kwoty wyjściowej przekazywanej odbiorcy Na szczęście to także umożliwia wzajemne miksowanie danych wyjściowych zatem wymagany jest tylko jeden indeks danych wyjściowych w porządku rejestracji Przedział weryfikacji (range proof) wynosi ok 5 kilobajtoacutew Podpisy pierścieniowe dla danych wejściowych stają się bardziej odporne na analizę ponieważ anonimowość jest bardzo rozszerzonaPodczas gdy obszary weryfikacji (range proofs) są duże wykorzystywanie układu haszującego ktoacutery dodaje przedrostek do transakcji (zaroacutewno indeksoacutew wejściowych jak i wyjściowych) i przechowuje szeroki zakres range proof wraz z podpisami umożliwia oddzielnie uzyskanie ogromnych oszczędności przestrzeni podczas synchronizacji (syncing) do punktu weryfikacji lub działanie jako węzeł SPV Podobnie do elementoacutew bocznych łańcucha (Sidechains Elements) [12] będziemy przechowywać H(H(prefiks)||H(podpisy)) w drzewie Merkla Następnie węzły syncing do zaufanego punktu weryfikacji muszą jedynie pobrać przedrostek i dodać wartość haszującą do podpisoacutew skutecznie redukując szerokość wiązki Ponieważ prefiks transakcji wykorzystuje wariant dla danych wyjściowych ktoacutere wymienia w swoich podpisach pierścieniowych oraz środkach zapisanych do jednego klucza publicznego stanowi on miniaturowe poroacutewnanie do danych podpisoacutew pierścieniowych w danych wyjściowych oraz range proofs

Następnie podpisy pierścieniowe mogą nawet być przycięte z bazy danych przez niektoacutere węzły w celu uzyskania dalszych zyskoacutew przestrzeni przechowując zastępczo jedynie względnie mały zbioacuter UTXO

511 Przekazywanie informacji o kwotach OdbiorcyObecnie mając dowolną kwotę wyjściową b = b020 + b121 + ∙∙∙ bn2n nadawca oblicza nową prywatnąpubliczną parę kluczy oraz związane wymieniane sekrety ECDH ss oraz udostępnia następujące informacje w swojej transakcji

gdzie ai to losowo wybrane liczby dla j = 0 hellipn Dane Klucz publiczny ECDH oraz a + ss mod l gdzie a = a0 + hellip + an

Następnie odbiorca Oblicza udostępniany sekret ss oraz oblicza a na podstawie a + ss mod l Oblicza C = sumCi oblicza C ndash aG = bH oraz oblicza b poroacutewnując uzyskane wartości do

wszystkich bH w danym przedziale [0 2n] (W praktyce będzie to szybkie 500 kilobajtowe wyszukanie w n = 12 podobnie jak w poprzednim rozdziale Gdyby jednak wartość 232 została wybrana jako goacuterna wartość graniczna podobnie jak w [11] wyszukiwanie stałoby się dużym obliczeniowo wysiłkiem)

6 WnioskiProtokoacuteł pierścieniowych transakcji poufnych (Ring Confidential Transactions) to bardzo silnie zdecentralizowana kryptowaluta (tzn nie ma w niej żadnej uprzywilejowanej strony) ktoacutera posiada proste do udowodnienia wartości szacunkowe zabezpieczeń dotyczące ukrywania kwot transferoacutew ich źroacutedeł oraz odbiorcoacutew Dodatkowo generowanie coinoacutew w oparciu o protokoacuteł Ring Confidential Transactions nie wymaga obecności czynnika zaufanego i proces jego weryfikacji jest całkowicie bezpiecznyTych pięć czynnikoacutew jest niezbędnych w przypadku kryptowalut zbliżonych do środkoacutew gotoacutewkowych takich jak MoneroBibliografia1 Masayuki Abe Miyako Ohkubo and Koutarou Suzuki 1-out-of-n signatures from a variety of keys Advances in CryptologyAsiacrypt 2002 pages 415ndash432 20022 Adam Back Bitcoins with homomorphic value (validatable but encrypted)httpsbitcointalkorgindexphptopic=3057910 2013 [Online accessed 1-May-2015]3 Adam Back Podpis pierścieniowy efficiency httpsbitcointalkorgindexphptopic=972541msg10619684msg10619684 2015 [Online accessed 1-May-2015]4 Eli Ben Sasson Alessandro Chiesa Christina Garman Matthew Green Ian Miers Eran Tromer and Madars Virza Zerocash Decentralized anonymous payments from bitcoin In Security and Privacy (SP) 2014 IEEE Symposium on pages 459ndash474 IEEE 20145 Evan Duffield and Kyle Hagan Darkcoin Peertopeer cryptocurrency with anonymous blockchain transactions and an improved proofofwork system 20146 Eiichiro Fujisaki and Koutarou Suzuki Traceable podpis pierścieniowy In Public Key CryptographyndashPKC 2007 pages 181ndash200 Springer 20077 Javier Herranz Aggregate signatures httpwwwiiiacsices~jherranzpapersNijmegen_seminar_aggregatepdf oct 20058 Joseph K Liu Victor K Wei and Duncan S Wong Linkable spontaneous anonymous group signature for ad hoc groups In Information Security and Privacy pages 325ndash335 Springer 20049 Adam Mackenzie Surae Noether and Monero Core Team Improving obfuscation in the cryptonote protocol httpslabgetmoneroorgpubsMRL-0004pdf January 201510 Greg Maxwell Coinjoin Bitcoin privacy for the real world august 2013 Bitcoin Forum httpsbitcointalkorgindexphptopic=2792490 2013 [Online accessed 1-July-2015]11 Greg Maxwell Confidential Transactions httpspeoplexiphorg~gregconfidential_valuestxt 2015 [Online accessed 1-June-2015]12 Greg Maxwell Elements project httpsgithubcomShenNoetherMiniNero 201513 Satoshi Nakamoto Bitcoin A peer-to-peer electronic cash system Consulted 1(2012)28 200814 Shen Noether Mininero httpsgithubcomShenNoetherMiniNero 201515 Ronald L Rivest Adi Shamir and Yael Tauman How to leak a secret In Advances in CryptologyASIACRYPT 2001 pages 552ndash565 Springer 200116 Nicolas van Saberhagen Cryptonote v 2 0 HYPERLINK https cryptonote org whitepaper pdf 2013

Załącznik A Załącznik Security ProofsA1 Brak możliwości sfałszowania MLSAG

Obliczenia przebiegają analogicznie do [8 Teoremat 1] Niech H1 oraz H2 będą losowo wybranymi oracle a SO stanowią podpisy oracle zwracające ważne podpisy MLSAG Załoacuteżmy że istnieje probabilistyczny wielomianowy adwersarz czasowy (PPT) A ktoacutery posiada zdolność sfałszowania MLSAG z listy wektoroacutew kluczy L przy prawdopodobieństwie ktoacuterego nie można pominąć

Gdzie Q1 stanowi wielomianowy parametr bezpieczeństwa k oraz gdzie (m σ) nie stanowi jednego z podpisoacutew zwracanych przez SO Załoacuteżmy że A nie wysyła więcej niż qH + nqS

(gdzie n oznacza liczbę kluczy w L) zapytań dotyczących podpisoacutew oracle H1H2 oraz SO odpowiednio Podpisy oracle H1 oraz H2 uważa się za niezależne i losowe oraz spoacutejne z danymi zapytaniami powtarzającymi się Podpis oracle SO może składać zapytanie H1 oraz H2 Mając wartość A wykaże że istnieje możliwość utworzenia adwersarza M w PPT ktoacutery będzie wykorzystywać A w celu znalezienia logarytmu dyskretnego jednego z kluczy w L

Jeżeli L stanowi zbioacuter kluczy wektoroacutew z ktoacuterych każdy będzie mieć wielkość r (tzn z kluczami publicznymi y1 hellip yr ) to wygenerowany fałszywy podpis

Wygenerowany przez A musi spełniać warunek

Gdzie i są obliczone w ramach mod n oraz są zdefiniowane zgodnie z Rozdziałem 22 Nowy adwersarz M może wykorzystać A w celu sfałszowania podpisoacutew wielomianową liczbę razy i zapisze każdy skrypt Turinga T niezależnie czy sfałszowanie było skuteczne czy nie

Lemma A1 [8 Lemma 1] Niech M wywołuje A w celu uzyskania transkrypcji T Jeżeli T jest skuteczne to M powraca do T do nagłoacutewka H i następnie re-symuluje A w celu uzyskania transkrypcji Trsquo Jeżeli Pr (T okaże się skuteczne) = ϵ to Pr (Trsquo jest skuteczne) = ϵ

Dowoacuted wynika wprost z przywołanego teorematu

Teoremat A2 Prawdopodobieństwo że adwersarz A sfałszuje podpis MLSAG można pominąć przy założeniu logarytmu dyskretnego

Dowoacuted Do przeprowadzenia dowodu będę stosować notację przedstawioną powyżej Podobnie jak w przypadku [8 teoremat 1] ponieważ prawdopodobieństwo odgadnięcia danych wyjściowych z losowego oracle jest znikome w związku z tym dla każdego skutecznego oszustwa A wprowadza transkrypcję uzupełniającą T a zatem mamy mT zapytań w przypadku zapytań do H1 odpowiadających liczbie n zapytań wykorzystywanych w celu weryfikacji podpisu W związku z tym niech Xi1 hellip Xim oznacza zapytania wykorzystywane w procesie weryfikacji fałszu ith oraz niech π oznacza indeks odpowiadający ostatniemu zapytaniu weryfikacyjnego dla danego oszustwa

(Intuicyjnie π odpowiada temu co może stanowić indeks sekretny fałszywego podpisu ponieważ odpowiada on ostatniemu wezwaniu ostatniemu wywołaniu losowego oracle dla danego odpisu)Proacuteba sfałszowania σ podjęta przez A stanowi fałsz (l π) jeżeli i1 = l oraz π jest zgodne z powyższym (zatem fałsz odpowiada zapytaniom l do l + π) Z założenia istnieje para (l π) taka że prawdopodobieństwo związanej transkrypcji T daje skutecznie wygenerowany fałszywy klucz ϵlπ (T) spełnia warunek

1

Teraz przeglądając T do wartości przed zapytaniem l-tym a następnie podejmując proacutebę sfałszowania za pomocą tego samego zbioru kluczy (oraz dopuszczając aby H1 obliczyło nowe rzuty monetami dla wszystkich kolejnych zapytań) z Lemmy A1 wynika że prawdopodobieństwo że Trsquo jest także skuteczne spełnia warunki

_Dlatego prawdopodobieństwo że zaroacutewno T jak i Trsquo odpowiadają weryfikacjom fałszywym σ i σ1 nie może zostać pominięte

Ponieważ nowe rzuty monetami zostały obliczone na podstawie danych wyjściowych losowych oracle H1 oznacza to że przy dużym prawdopodobieństwie istnieje wartość j taka

że oraz W związku z tym możemy rozwiązać klucz prywatny z indeksem π

ktoacutery jest sprzeczny z założeniami logarytmu dyskretnego

A2 Linkowalność MLSAG Teoremat A3 Linkowalność obrazu klucza (Key-Image Linkability) Prawdopodobieństwo że adwersarz a w PPT może utworzyć dwa podpisy weryfikujące (niepołączone w danym

ustawieniu σ σrsquo podpisane w odniesieniu do wektoroacutew kluczy oraz odpowiednio w taki

sposoacuteb że będzie istnieć klucz publiczny i w obu oraz może być pominięte

Dowoacuted Przypuśćmy że w przeciwieństwie do tego co zostało wcześniej powiedziane A utworzył dwa podpisy weryfikujące σ oraz σrsquo o oba są podpisami w odniesieniu do kluczowych wektoroacutew

oraz odpowiednio w taki sposoacuteb że istnieje klucz publiczny y zaroacutewno w jak i

Niech y występuje jako element j należący do a jrsquo jako element należący do rsquo Z teorematu A2 wynika z dużym prawdopodobieństwem że istnieją indeksy π oraz πrsquo dla kluczy publicznych σ oraz σrsquo odpowiednio takie że

oraz

z

oraz

Jeżeli uznamy że x oznacza klucz prywatny y y = xG to po rozwiązaniu powyższego dla Ij

oraz Ij0rsquo mamy następujące roacutewnania oraz podobnie Ijrsquo = xH (y) Tym samym dwa podpisy obejmują Ij = Ijrsquo i w związku z tym ponieważ zduplikowane obrazy kluczy są odrzucone jeden z nich nie może być wykorzystany do weryfikacji

A3 Anonimowość MLSAG W celu udowodnienia anonimowości powyższego protokołu w losowym modelu oracle przyjmijmy że H1 H2 to losowe oracle modelujące dyskretne funkcje haszujące Niech A to adwersarz anonimowości Buduję adwersarza M względem założenia problemu decyzyjnego Diffie Helmana (DDH) zgodnie z poniższym Założenie DDH stwierdza że mając daną krotność (G aG bG ϒG) prawdopodobieństwo ustalenia czy G = abG jest znikome

Teoremat A4 Protokoacuteł pierścieniowy CT jest dwuznaczny w odniesieniu do sygnatariusza przy założeniu problemu decyzyjnego Diffie-HelmanaDowoacuted (zbliżony do dowodu [8 Teoremat 2]) Załoacuteżmy że problem decyzyjny Diffie-Helmana jest trudny w cyklicznej grupie generowanej przez G i załoacuteżmy że istnieje adwersarz A w czasie PPT względem dwuznaczności sygnatariusza Tym samym mając listę L n wektoroacutew

kluczy publicznych o długości m oraz zbioacuter prywatnych kluczy t ważny podpis σ na L podpisany przez użytkownika w odniesieniu do wektora klucza y taki że

odpowiedni wektor klucza prywatnego wynosi spełnia to A może zdeterminować π z prawdopodobieństwem

Dla wybranych wielomianoacutew Q(k) Buduję adwersarza PPT M ktoacutery wykorzystuje krotność danych wejściowych (G aG bG ciG) gdzie I ϵ 0 1 jest losowo wybrany (a nie znany M a priori) c1 = ab oraz c0 jest losowym skalarem a dane wyjściowe i mają prawdopodobieństwo

Dla niektoacuterych wielomianoacutew Q2 (k)Należy rozważyć algorytm SIMNIZKP (zbliżony to tego ktoacutery został zdefiniowany w [6]) ktoacutery jako skalary wejściowe wykorzystuje wektor x klucza prywatnego zbioacuter wektoroacutew kluczy

publicznych indeks π oraz wiadomość m i ktoacutery działa w sposoacuteb następujący1 Wygenerować skalary losowe s1 hellip sm oraz skalar losowy cπ lt- H2 Dla j indeksującego określić

A dla pozostałych j

3 Obliczyć losowe dane wyjściowe na podstawie losowego oracle

4 Dla każdego i roboczego mod m obliczyć

Należy podkreślić że w ostatnim punkcie kiedy i = π - 1 to ci+1 jest już określone w celu utrzymania spoacutejności z losowymi danymi wyjściowymi oracleNależy podkreślić że niezależnie od tego czy jest rzeczywistym kluczem prywatnym odpowiadającym ze względu na to że spoacutejność jest zachowywana przez losowe wartości oracle w kolejnych wezwaniach powyższy podpis jest weryfikowany Jeżeli x jest rzeczywiście wektorem klucza prywatnego y to nie ma roacuteżnicy pomiędzy SIMNIZKP oraz rzeczywistym podpisemNa koniec mając krotność (G aG bG ciG) gdzie a b są losowo wybrany skalarami a c1 = ab c0 elementem losowym i ϵ 0 1 M zachodzi w poniższych krokach i pozwala rozwiązać problem decyzyjny Diffie Helmana za pomocą niepomijalnego prawdopodobieństwa M wychwytuje losowe ϒ lt-H z losowej wartości oracle oraz pobiera parę wektoroacutew klucza prywatnego publicznego (x y) a następnie oblicza s jako a = s + ϒx Teraz M wykonuje

SIMNIZKP za pomocą dowolnie wybranych wektoroacutew kluczy w taki sposoacuteb że w danej wiadomości m oraz Jeżeli prawdziwe jest że i = 1 to c = ab oraz logGaG = logbGcG = a

z uwagi na to że zakłada się iż A jest w stanie znaleźć π z prawdopodobieństwem ktoacuterego nie można pominąć to istnieje niepomijalne prawdopodobieństwo frac12 że A zwroacuteci 1 (i wtedy M zwroacuteci 1) Jeżeli i = 0 to A zwraca 1 wyłącznie z prawdopodobieństwem frac12 a zatem dla niektoacuterych niepomijanych prawdopodobieństw powyżej 1`2 M zwraca tę samą wartość co A i tym samym rozwiązuje problem decyzyjny Diffie-Helmana dla losowo wybranych skalaroacutew bez pomijalnego prawdopodobieństwa powyżej 12 co stanowi sprzeczność

Załącznik B Kod demo Ring CT W repozytorium w [14] zbudowałem prostą demonstrację protokołu poufnych transakcji pierścieniowych (Ring Confidential Transactions) wykorzystujących podpisy MLSAG w części 2 oraz podpisy ASNL w części 5

H_ct = RingCTgetHForCT()print(H H_ct)sr Pr = PaperWalletskpkGen() receivers private publicse pe ss = ecdhecdhgen(Pr) compute shared secret ssdigits = 14 in practice it will be 14print(inputs)Cia L1a s2a sa ska = RingCTgenRangeProof(10000 digits)print(outputs)Cib L1b s2b sb skb = RingCTgenRangeProof(7000 digits)Cic L1c s2c sc skc = RingCTgenRangeProof(3000 digits)print(verifying range proofs of outputs)RingCTverRangeProof(Cib L1b s2b sb)RingCTverRangeProof(Cic L1c s2c sc)x P1 = PaperWalletskpkGen()P2 = PaperWalletpkGen()C2 = PaperWalletpkGen()some random commitment grabbed from the blockchainind = 0Ca = RingCTsumCi(Cia)Cb = RingCTsumCi(Cib)Cc = RingCTsumCi(Cic)sk = [x MiniNerosc_sub_keys(ska MiniNerosc_add_keys(skb skc))]

pk = [[P1 P2] [MiniNerosubKeys(Ca MiniNeroaddKeys(Cb Cc)) MiniNerosubKeys(C2 MiniNeroaddKeys(Cb Cc)) ] ]II cc ssVal = MLSAGMLSAG_Sign(pk sk ind)print(Sig verified MLSAGMLSAG_Ver(pk II cc ssVal) )print(Finding received amount corresponding to Cib)RingCTComputeReceivedAmount(pe sr MiniNeroaddScalars(ss skb) Cib)print(Finding received amount corresponding to Cic)RingCTComputeReceivedAmount(pe sr MiniNeroaddScalars(ss skc) Cic)

Przykład transakcji z danymi wejściowymi 10 000 oraz wyjściowymi 3 000 i 7 000(rsquoHrsquo rsquo61fe7f0f5a607a33427d01dd1fded5ffa03fae2e9df9ebccf2e0a2f5bd77a204rsquo)inputs(rsquob b in binaryrsquo 10000 [0 0 0 0 1 0 0 0 1 1 1 0 0 1])Generating Aggregate Schnorr Non-linkable Podpis pierścieniowy outputs(rsquob b in binaryrsquo 7000 [0 0 0 1 1 0 1 0 1 1 0 1 1 0])Generating Aggregate Schnorr Non-linkable Podpis pierścieniowy (rsquob b in binaryrsquo 3000 [0 0 0 1 1 1 0 1 1 1 0 1 0 0])Generating Aggregate Schnorr Non-linkable Podpis pierścieniowy verifying range proofs of outputsVerifying Aggregate Schnorr Non-linkable Podpis pierścieniowy VerifiedVerifying Aggregate Schnorr Non-linkable Podpis pierścieniowy Verified(rsquoGenerating MLSAG sig of dimensions rsquo 2 rsquox rsquo 2)(rsquoverifying MLSAG sig of dimensions rsquo 2 rsquox rsquo 2)(rsquocrsquo[rsquo80a3cfd06dd2862307cd75c2a1566f20cd743dbb0b9feb22d79dcbecb9023f42rsquorsquoa9b7342ba7bf2f102505ca19dab734fde638916c0a29f5b30e49833ab51393earsquorsquo80a3cfd06dd2862307cd75c2a1566f20cd743dbb0b9feb22d79dcbecb9023f42rsquo])(rsquosig verifiesrsquo True)(rsquoSig verifiedrsquo True)Finding received amount corresponding to Cib(rsquoreceived rsquo 7000c Monero Research Lab Page 20 of 20rsquoa488ec68732fb551841c2c6dcc7ffac895d98ec7e9378275ed20ea12805fc18ersquo)Finding received amount corresponding to Cic(rsquoreceived rsquo3000rsquo1b46626858e130a0f3884c74c9fdeabc4d812c519103ea16a35a3f82a3d0ed6drsquo)

= xcG + aH - y1G - b1H - y2G - b2H= zG

A zatem powyższe roacutewnanie staje się zobowiązaniem do 0 przy sk = z oraz pk = zG a nie rzeczywistym roacutewnaniem o sumie zerowej Należy podkreślić że z nie jest wyliczalne dla coinoacutew źroacutedłowych xc chyba że znana jest zaroacutewno wartość y1 jak i y2 nie mniej jednak nawet to można w prosty sposoacuteb złagodzić poprzez uwzględnienie dodatkowych adresoacutew zmiany (zwykły przypadek zakłada że drugie zobowiązanie z wartością y2 jako maską są wysyłane jako zmiana)Ponieważ podawanie informacji ktoacutere dane wejściowe należą do nadawcy nie jest pożądane podpis pierścieniowy zawierający wszystkie zobowiązania wejściowe Ci i = 1 hellip s hellip n (gdzie s stanowi sekretny indeks zobowiązania nadawcy) dodaje się odpowiedni klucz publiczny (dzięki czemu zobowiązania oraz klucze publiczne są parowane (Ci Pi) ale tylko takie ktoacutere mogą być wspoacutelnie wydatkowane) oraz odejmuje sumCout

Jest to podpis pierścieniowy ktoacutery może być złożony ponieważ znamy jeden z prywatnych kluczy (a mianowicie z + xrsquo zawierający z jak wyżej oraz xrsquoG = Ps) Tak naprawdę ponieważ wiemy że dla każdego i zaroacutewno klucze prywatne dla Pi jak i klucze prywatne dla Pi + Ciin - sumjCjout możemy złożyć podpis zgodnie z treścią rozdziału 22 Szczegoacuteły tej procedury są opisane w Definicji 41

Zgodnie z [11] ważne jest udowodnienie że kwoty wyjściowe [4] b1 hellip bn wszystkie mieszczą się w szeregu wartości dodatnich np (0 216) Można to osiągnąć zasadniczo w taki sam sposoacuteb jak w [11] kwestia ta jest bardziej szczegoacutełowo opisana w części 5Na koniec warto zauważyć że w powyższej dyskusji nie wspomniałem o właściwości związanej dołączaniem tagoacutew ktoacutera jest wykorzystywana w Monero oraz Cryptonote w celu zapobiegania podwoacutejnemu wydatkowaniu środkoacutew Dołączanie tagoacutew w tym momencie będzie skutkiem łączenia powyższego omoacutewienia z podpisami MLSAG o ktoacuterych mowa w Definicji 41

4 Ring CT dla protokołu Monero 41 Opis protokołuDefinicja 41 (Tagowalny pierścień CT z mnogimi danymi wejściowymi oraz kluczami jednorazowymi)

Niech stanowi zbioacuter adresoacutew oraz kluczy jednorazowychzobowiązań ktoacuterym odpowiadają sekretne klucze xj j = 1 hellip m

Znaleźć zbiory q + 1 i = 1 hellip q + 1 ktoacutere nie są połączone tagami w sensie [ 6 strona 6]

Należy określić zestaw adresoacutew wyjściowych (Qi Ciout) takich że

stanowią zobowiązania o wartości zero Niech

hellip

stanowi uogoacutelniony pierścień w ktoacuterym chcemy złożyć swoacutej podpis Należy zauważyć że ostatnia kolumna to pierścień Ring-CT w rozumieniu rozdziału 4

Obliczyć podpis MLSAG sum na R

[4] Ponieważ zobowiązania wejściowe mogą być potencjalnie odziedziczone z poprzednich transakcji wystarczy rozważyć kwoty wyjściowe

W takim przypadku zgodnie z teorematem A2 nie może być sygnatariuszem żadnych dodatkowych niezlinkowanych podpisoacutew pierścieniowych w danym nadzbiorze P wszystkich takich par P = (PC) po podpisaniu sum

Uwaga 42 Złożoność przestrzeni powyższego protokołu Warto zauważyć że rozmiar podpisu sum na R zgodnie z definicją 41 jest w rzeczywistości mniejszy dla m gt 1 niż bieżący podpis pierścieniowy transakcji opartej na protokole CryptoNote [16] ktoacutera zawiera mnogie dane wejściowe Dzieje się tak dzięki wprowadzeniu zmian w rozmiarze w [8] do każdej kolumny Należy także podkreślić że prawdopodobnie nie jest konieczne umieszczanie obrazu klucza zobowiązania związanego z wyżej wymienionym podpisem Kolejne optymalizacje rozmiaru są możliwe i można je wykonać w podobny sposoacuteb

42 Konwersja widocznych denominacji na zobowiązaniaPonieważ Monero obecnie wykorzystuje blockchainowe widoczne skalary w celu stworzenia reprezentacji kwot ważne jest aby istniała możliwość (i sposoacuteb) konwersji z kwot widocznych na zobowiązania przy jednoczesnym zachowaniu anonimowości Tak naprawdę wcale nie jest to trudne Mając daną parę (P a) gdzie P jest kluczem publicznym a a stanowi kwotę może ona być wykorzystana jako dane wejściowe transakcji jako (P aH) i transakcja ta musi być zweryfikowana przez weryfikatora pod kątem kwoty wejściowej i jej przemnożenia przez punkt maskujący H oraz czy uzyskana wartość rzeczywiście wynosi aH Zatem jako pierwszy krok kwoty wejściowe nie zostaną ukryte ale ukryte zostaną dane wyjściowe transakcji oraz wszelkie niezbędne relacje o ktoacuterych mowa w rozdziale 4 pozostają ważne Należy podkreślić że range proof nie jest konieczny dla tych danych wejściowych

Uwaga 43 Oczywistą zaletą tej metody jest konwersja z kwot widocznych na zobowiązania oraz to że kwota coinoacutew wygenerowanych w procesie wydobycia jest weryfikowalna bez konieczności udziału elementu zaufanego Jest to przewaga protokołu Ring CT nad systemami płatniczymi takimi jak [4] ktoacutere obejmują fazę ustawień strony zaufanej

43 Opłaty transakcyjnePonieważ system Monero jest silnie zdecentralizowany (tzn proof of work) konieczne jest wynagradzanie goacuternikoacutew i dokonywanie opłat za każdą transakcję Pomaga to podnieść bezpieczeństwo sieci i zapobiegać rozdęcia blockchainu Opłaty te muszą być realizowane w postaci niezamaskowanej tzn Jako bH a nie xG + bH oraz w odniesieniu do pewnej standardowej kwoty b w taki sposoacuteb że goacuternik będzie moacutegł zweryfikować że b ∙ H = bH i tym samym że jest dość środkoacutew na opłatę transakcyjną przy jednoczesnym zachowaniu roacutewnań związanych z H w taki sposoacuteb że zostaną zachowane niezbędne relacje o ktoacuterych mowa w Rozdziale 4

44 Ring MultisignatureWarto zauważyć że prosta wersja t z m z n ring-multisignature [mnogich podpisoacutew pierścieniowych] może być zrealizowana w oparciu o podpisy MLSAG Umożliwia to grupie m uczestnikoacutew zbudowanie multisignature takiego że t uczestnikoacutew z liczby z m musi złożyć podpis aby był on uznany za ważny dodatkowo jest on dwuznaczny w odniesieniu do sygnatariusza klucze m są uczestnikami mieszczącymi się w ogoacutelnej liczbie n kluczy

Liczba n uczestnikoacutew w multisignature stanowi wspoacutelny sekret xe oraz klucz publiczny Pe ktoacutere mają wspoacutelne obrazy kluczy multisig

Ij = xeH(PejPj)

z Pj ndash publicznym kluczem uczestnika Każdy uczestnik multisignature dokonuje wyboru dodatkowych kluczy publicznych n -

m w blockchainie oraz tworzy podpis MLSAG za pomocą pierwszego rzędu wszystkich kluczy n a drugi rząd ma dla każdego wpisu (elementu) klucz wspoacutelny Pe

Każdy sygnatariusz multisignature podaje początkowe Ij j = 1 hellip m w celu umożliwienia zaakceptowania klucza po przekazaniu podpisoacutew weryfikujących t w blockchainie z ktoacuterych każdy odpowiada jednemu obrazowi klucza Ij

Rozszerzony zapis ring-multisignature jest w fazie opracowania

5 Zagregowane schematy identyfikacji Schnorra (Aggregate Schnorr Range Proofs)W części [11] poufne transakcja bez podpisu pierścieniowego wykorzystuje pewien typ podpisu pierścieniowego oparty na [1] nazywany podpisem pierścienia boromejskiego (Borromean ring signature) i pomaga zidentyfikować przekłamania w wartości zobowiązań w pewnym przedziale W niniejszym artykule postaram się nakreślić alternatywną metodę zainspirowaną przez [7] ktoacutera pozwala na uzyskanie tych samych oszczędności w zakresie przestrzeni ale za to opatrzona jest nieco mniej skomplikowanym protokołem bezpieczeństwa Motywacja do tego typu działania jest następująca przypuśćmy że dana transakcja ma dane wejściowe zobowiązań roacutewne

Cin = ainG + 10H

oraz zobowiązania wyjściowe

Cout 1 = aout1G + 5H Cout2 = aout2G + 5H

Scenariusz ten zachowuje ważność gdyż istnieje możliwość złożenia podpisu dla Cin ndash Cout1 ndash Cout2 = (ain ndash aout1 ndash aout2)G

Nie mniej jednak warto podkreślić że (bez range proofs) będzie istniała możliwość alternatywnego ustawienia zobowiązań wyjściowych

Cout1 = aout1G- H Cout2 = aout2G + 11H

Ponieważ -1 jest bardzo dużą liczbą stanowiącą modulo porządkujące grupę krzywej tym samym zostały utworzone darmowe pieniądze Zatem konieczne jest wykazanie że Couti są zobowiązaniami w odniesieniu do wartości ktoacutere są pozytywne (dodatnie) i mieszczą się w ograniczonym przedziale [0 2n] dla niektoacuterych wartości n Aby tego dokonać należy rozłożyć każdą wartość wyjściową na elementy binarne

co pozwala obliczyć zobowiązania do bj ∙ 2j w taki sposoacuteb że

Na koniec wykorzystując sekretny klucz bj można obliczyć podpis pierścieniowy na

dla wszystkich j oraz zapewnia dla weryfikatoroacutew (w tym przypadku goacuternikoacutew)Jeżeli chodzi o oszczędności miejsca można albo wykorzystać boromejski podpis pierścieniowy (podobnie jak w [11]) albo połączyć wszystkie proste podpisy pierścieniowe bądź utworzyć pewien typ zagregowanego podpisu pierścieniowego zdefiniowanego w następujący sposoacuteb

501 Generowanie zagregowanego nielinkowanego podpisu pierścieniowego Schnorra (Aggregate Schnorr Non-linkable Ring Signature) (ASNL)

Niech stanowi zbioacuter kluczy j = 1hellip z jako sekretnym kluczem

Dla każdego j niech Irsquo = i + 1 mod 2 ustawić skalar losowy aj i obliczyć

Ustawić gdzie Hs to kryptograficzna funkcja haszująca zwracająca skalar po dokonaniu wyboru losowego obliczyć

Określić i obliczyć

Zwroacutecić dla wszystkich j i s =

502 Weryfikacja zagregowanego nielinkowalnego podpisu pierścieniowego Schnorra (ASNL)Zacznijmy od dla j = 1hellip n oraz s

Dla wszystkich j obliczyć oraz

Jeżeli to otrzymamy 0 dla ważnego podpisuW przeciwnym razie otrzymamy wartość zwrotną -1

Teoremat 51 Zagregowany nielinkowany podpis pierścieniowy Schnorra nie może być sfałszowany przy założeniu logarytmu dyskretnego

Dowoacuted Przedstawiam szkic dowodu w przypadku n = 2 Przypadek ogoacutelny ma zbliżony charakter Przypuśćmy że adwersarz A jest w stanie sfałszować podpis ASNL na

Przy pomijalnym prawdopodobieństwie znając najwyżej jedną z (przypuśćmy że bez straty ogoacutelnego charakteru założenia że A zna ) Dla każdego danego fałszu

rozwiązuję roacutewnanie logarytmu dyskretnego o niepomijalnym prawdopodobieństwie Po zastosowaniu algorytmu weryfikacji niech Zatem prawdziwe musi być roacutewnanie

Przypuśćmy że oraz a a b są znane A wtedy

ponieważ jest określone protokołem weryfikacji musi być zatem prawdą że A zna klucz

prywatny

=Jest to w sprzeczności z założeniem logarytmu dyskretnego dla danej grupy

51 Reprezentacja kwotKwoty w protokole Ring CT można przedstawiać w sposoacuteb zbliżony do tego ktoacutery przedstawiony został w [11] z drobną modyfikacją w celu dopasowania do systemu Monero Coiny CryptoNote organizują nominały coinoacutew w bazie indeksoacutew w taki sposoacuteb aby mogły być ułożone w porządku występowania jako dane wejściowe dla podpisoacutew pierścieniowych Ponieważ wszystkie wartości coinoacutew w CryptoNote są reprezentowane w postaci 64-bitowych niepodpisanych liczb całkowitych możemy wykorzystać range proof na przestrzeni całego rejestru w celu zakodowania kwoty wyjściowej przekazywanej odbiorcy Na szczęście to także umożliwia wzajemne miksowanie danych wyjściowych zatem wymagany jest tylko jeden indeks danych wyjściowych w porządku rejestracji Przedział weryfikacji (range proof) wynosi ok 5 kilobajtoacutew Podpisy pierścieniowe dla danych wejściowych stają się bardziej odporne na analizę ponieważ anonimowość jest bardzo rozszerzonaPodczas gdy obszary weryfikacji (range proofs) są duże wykorzystywanie układu haszującego ktoacutery dodaje przedrostek do transakcji (zaroacutewno indeksoacutew wejściowych jak i wyjściowych) i przechowuje szeroki zakres range proof wraz z podpisami umożliwia oddzielnie uzyskanie ogromnych oszczędności przestrzeni podczas synchronizacji (syncing) do punktu weryfikacji lub działanie jako węzeł SPV Podobnie do elementoacutew bocznych łańcucha (Sidechains Elements) [12] będziemy przechowywać H(H(prefiks)||H(podpisy)) w drzewie Merkla Następnie węzły syncing do zaufanego punktu weryfikacji muszą jedynie pobrać przedrostek i dodać wartość haszującą do podpisoacutew skutecznie redukując szerokość wiązki Ponieważ prefiks transakcji wykorzystuje wariant dla danych wyjściowych ktoacutere wymienia w swoich podpisach pierścieniowych oraz środkach zapisanych do jednego klucza publicznego stanowi on miniaturowe poroacutewnanie do danych podpisoacutew pierścieniowych w danych wyjściowych oraz range proofs

Następnie podpisy pierścieniowe mogą nawet być przycięte z bazy danych przez niektoacutere węzły w celu uzyskania dalszych zyskoacutew przestrzeni przechowując zastępczo jedynie względnie mały zbioacuter UTXO

511 Przekazywanie informacji o kwotach OdbiorcyObecnie mając dowolną kwotę wyjściową b = b020 + b121 + ∙∙∙ bn2n nadawca oblicza nową prywatnąpubliczną parę kluczy oraz związane wymieniane sekrety ECDH ss oraz udostępnia następujące informacje w swojej transakcji

gdzie ai to losowo wybrane liczby dla j = 0 hellipn Dane Klucz publiczny ECDH oraz a + ss mod l gdzie a = a0 + hellip + an

Następnie odbiorca Oblicza udostępniany sekret ss oraz oblicza a na podstawie a + ss mod l Oblicza C = sumCi oblicza C ndash aG = bH oraz oblicza b poroacutewnując uzyskane wartości do

wszystkich bH w danym przedziale [0 2n] (W praktyce będzie to szybkie 500 kilobajtowe wyszukanie w n = 12 podobnie jak w poprzednim rozdziale Gdyby jednak wartość 232 została wybrana jako goacuterna wartość graniczna podobnie jak w [11] wyszukiwanie stałoby się dużym obliczeniowo wysiłkiem)

6 WnioskiProtokoacuteł pierścieniowych transakcji poufnych (Ring Confidential Transactions) to bardzo silnie zdecentralizowana kryptowaluta (tzn nie ma w niej żadnej uprzywilejowanej strony) ktoacutera posiada proste do udowodnienia wartości szacunkowe zabezpieczeń dotyczące ukrywania kwot transferoacutew ich źroacutedeł oraz odbiorcoacutew Dodatkowo generowanie coinoacutew w oparciu o protokoacuteł Ring Confidential Transactions nie wymaga obecności czynnika zaufanego i proces jego weryfikacji jest całkowicie bezpiecznyTych pięć czynnikoacutew jest niezbędnych w przypadku kryptowalut zbliżonych do środkoacutew gotoacutewkowych takich jak MoneroBibliografia1 Masayuki Abe Miyako Ohkubo and Koutarou Suzuki 1-out-of-n signatures from a variety of keys Advances in CryptologyAsiacrypt 2002 pages 415ndash432 20022 Adam Back Bitcoins with homomorphic value (validatable but encrypted)httpsbitcointalkorgindexphptopic=3057910 2013 [Online accessed 1-May-2015]3 Adam Back Podpis pierścieniowy efficiency httpsbitcointalkorgindexphptopic=972541msg10619684msg10619684 2015 [Online accessed 1-May-2015]4 Eli Ben Sasson Alessandro Chiesa Christina Garman Matthew Green Ian Miers Eran Tromer and Madars Virza Zerocash Decentralized anonymous payments from bitcoin In Security and Privacy (SP) 2014 IEEE Symposium on pages 459ndash474 IEEE 20145 Evan Duffield and Kyle Hagan Darkcoin Peertopeer cryptocurrency with anonymous blockchain transactions and an improved proofofwork system 20146 Eiichiro Fujisaki and Koutarou Suzuki Traceable podpis pierścieniowy In Public Key CryptographyndashPKC 2007 pages 181ndash200 Springer 20077 Javier Herranz Aggregate signatures httpwwwiiiacsices~jherranzpapersNijmegen_seminar_aggregatepdf oct 20058 Joseph K Liu Victor K Wei and Duncan S Wong Linkable spontaneous anonymous group signature for ad hoc groups In Information Security and Privacy pages 325ndash335 Springer 20049 Adam Mackenzie Surae Noether and Monero Core Team Improving obfuscation in the cryptonote protocol httpslabgetmoneroorgpubsMRL-0004pdf January 201510 Greg Maxwell Coinjoin Bitcoin privacy for the real world august 2013 Bitcoin Forum httpsbitcointalkorgindexphptopic=2792490 2013 [Online accessed 1-July-2015]11 Greg Maxwell Confidential Transactions httpspeoplexiphorg~gregconfidential_valuestxt 2015 [Online accessed 1-June-2015]12 Greg Maxwell Elements project httpsgithubcomShenNoetherMiniNero 201513 Satoshi Nakamoto Bitcoin A peer-to-peer electronic cash system Consulted 1(2012)28 200814 Shen Noether Mininero httpsgithubcomShenNoetherMiniNero 201515 Ronald L Rivest Adi Shamir and Yael Tauman How to leak a secret In Advances in CryptologyASIACRYPT 2001 pages 552ndash565 Springer 200116 Nicolas van Saberhagen Cryptonote v 2 0 HYPERLINK https cryptonote org whitepaper pdf 2013

Załącznik A Załącznik Security ProofsA1 Brak możliwości sfałszowania MLSAG

Obliczenia przebiegają analogicznie do [8 Teoremat 1] Niech H1 oraz H2 będą losowo wybranymi oracle a SO stanowią podpisy oracle zwracające ważne podpisy MLSAG Załoacuteżmy że istnieje probabilistyczny wielomianowy adwersarz czasowy (PPT) A ktoacutery posiada zdolność sfałszowania MLSAG z listy wektoroacutew kluczy L przy prawdopodobieństwie ktoacuterego nie można pominąć

Gdzie Q1 stanowi wielomianowy parametr bezpieczeństwa k oraz gdzie (m σ) nie stanowi jednego z podpisoacutew zwracanych przez SO Załoacuteżmy że A nie wysyła więcej niż qH + nqS

(gdzie n oznacza liczbę kluczy w L) zapytań dotyczących podpisoacutew oracle H1H2 oraz SO odpowiednio Podpisy oracle H1 oraz H2 uważa się za niezależne i losowe oraz spoacutejne z danymi zapytaniami powtarzającymi się Podpis oracle SO może składać zapytanie H1 oraz H2 Mając wartość A wykaże że istnieje możliwość utworzenia adwersarza M w PPT ktoacutery będzie wykorzystywać A w celu znalezienia logarytmu dyskretnego jednego z kluczy w L

Jeżeli L stanowi zbioacuter kluczy wektoroacutew z ktoacuterych każdy będzie mieć wielkość r (tzn z kluczami publicznymi y1 hellip yr ) to wygenerowany fałszywy podpis

Wygenerowany przez A musi spełniać warunek

Gdzie i są obliczone w ramach mod n oraz są zdefiniowane zgodnie z Rozdziałem 22 Nowy adwersarz M może wykorzystać A w celu sfałszowania podpisoacutew wielomianową liczbę razy i zapisze każdy skrypt Turinga T niezależnie czy sfałszowanie było skuteczne czy nie

Lemma A1 [8 Lemma 1] Niech M wywołuje A w celu uzyskania transkrypcji T Jeżeli T jest skuteczne to M powraca do T do nagłoacutewka H i następnie re-symuluje A w celu uzyskania transkrypcji Trsquo Jeżeli Pr (T okaże się skuteczne) = ϵ to Pr (Trsquo jest skuteczne) = ϵ

Dowoacuted wynika wprost z przywołanego teorematu

Teoremat A2 Prawdopodobieństwo że adwersarz A sfałszuje podpis MLSAG można pominąć przy założeniu logarytmu dyskretnego

Dowoacuted Do przeprowadzenia dowodu będę stosować notację przedstawioną powyżej Podobnie jak w przypadku [8 teoremat 1] ponieważ prawdopodobieństwo odgadnięcia danych wyjściowych z losowego oracle jest znikome w związku z tym dla każdego skutecznego oszustwa A wprowadza transkrypcję uzupełniającą T a zatem mamy mT zapytań w przypadku zapytań do H1 odpowiadających liczbie n zapytań wykorzystywanych w celu weryfikacji podpisu W związku z tym niech Xi1 hellip Xim oznacza zapytania wykorzystywane w procesie weryfikacji fałszu ith oraz niech π oznacza indeks odpowiadający ostatniemu zapytaniu weryfikacyjnego dla danego oszustwa

(Intuicyjnie π odpowiada temu co może stanowić indeks sekretny fałszywego podpisu ponieważ odpowiada on ostatniemu wezwaniu ostatniemu wywołaniu losowego oracle dla danego odpisu)Proacuteba sfałszowania σ podjęta przez A stanowi fałsz (l π) jeżeli i1 = l oraz π jest zgodne z powyższym (zatem fałsz odpowiada zapytaniom l do l + π) Z założenia istnieje para (l π) taka że prawdopodobieństwo związanej transkrypcji T daje skutecznie wygenerowany fałszywy klucz ϵlπ (T) spełnia warunek

1

Teraz przeglądając T do wartości przed zapytaniem l-tym a następnie podejmując proacutebę sfałszowania za pomocą tego samego zbioru kluczy (oraz dopuszczając aby H1 obliczyło nowe rzuty monetami dla wszystkich kolejnych zapytań) z Lemmy A1 wynika że prawdopodobieństwo że Trsquo jest także skuteczne spełnia warunki

_Dlatego prawdopodobieństwo że zaroacutewno T jak i Trsquo odpowiadają weryfikacjom fałszywym σ i σ1 nie może zostać pominięte

Ponieważ nowe rzuty monetami zostały obliczone na podstawie danych wyjściowych losowych oracle H1 oznacza to że przy dużym prawdopodobieństwie istnieje wartość j taka

że oraz W związku z tym możemy rozwiązać klucz prywatny z indeksem π

ktoacutery jest sprzeczny z założeniami logarytmu dyskretnego

A2 Linkowalność MLSAG Teoremat A3 Linkowalność obrazu klucza (Key-Image Linkability) Prawdopodobieństwo że adwersarz a w PPT może utworzyć dwa podpisy weryfikujące (niepołączone w danym

ustawieniu σ σrsquo podpisane w odniesieniu do wektoroacutew kluczy oraz odpowiednio w taki

sposoacuteb że będzie istnieć klucz publiczny i w obu oraz może być pominięte

Dowoacuted Przypuśćmy że w przeciwieństwie do tego co zostało wcześniej powiedziane A utworzył dwa podpisy weryfikujące σ oraz σrsquo o oba są podpisami w odniesieniu do kluczowych wektoroacutew

oraz odpowiednio w taki sposoacuteb że istnieje klucz publiczny y zaroacutewno w jak i

Niech y występuje jako element j należący do a jrsquo jako element należący do rsquo Z teorematu A2 wynika z dużym prawdopodobieństwem że istnieją indeksy π oraz πrsquo dla kluczy publicznych σ oraz σrsquo odpowiednio takie że

oraz

z

oraz

Jeżeli uznamy że x oznacza klucz prywatny y y = xG to po rozwiązaniu powyższego dla Ij

oraz Ij0rsquo mamy następujące roacutewnania oraz podobnie Ijrsquo = xH (y) Tym samym dwa podpisy obejmują Ij = Ijrsquo i w związku z tym ponieważ zduplikowane obrazy kluczy są odrzucone jeden z nich nie może być wykorzystany do weryfikacji

A3 Anonimowość MLSAG W celu udowodnienia anonimowości powyższego protokołu w losowym modelu oracle przyjmijmy że H1 H2 to losowe oracle modelujące dyskretne funkcje haszujące Niech A to adwersarz anonimowości Buduję adwersarza M względem założenia problemu decyzyjnego Diffie Helmana (DDH) zgodnie z poniższym Założenie DDH stwierdza że mając daną krotność (G aG bG ϒG) prawdopodobieństwo ustalenia czy G = abG jest znikome

Teoremat A4 Protokoacuteł pierścieniowy CT jest dwuznaczny w odniesieniu do sygnatariusza przy założeniu problemu decyzyjnego Diffie-HelmanaDowoacuted (zbliżony do dowodu [8 Teoremat 2]) Załoacuteżmy że problem decyzyjny Diffie-Helmana jest trudny w cyklicznej grupie generowanej przez G i załoacuteżmy że istnieje adwersarz A w czasie PPT względem dwuznaczności sygnatariusza Tym samym mając listę L n wektoroacutew

kluczy publicznych o długości m oraz zbioacuter prywatnych kluczy t ważny podpis σ na L podpisany przez użytkownika w odniesieniu do wektora klucza y taki że

odpowiedni wektor klucza prywatnego wynosi spełnia to A może zdeterminować π z prawdopodobieństwem

Dla wybranych wielomianoacutew Q(k) Buduję adwersarza PPT M ktoacutery wykorzystuje krotność danych wejściowych (G aG bG ciG) gdzie I ϵ 0 1 jest losowo wybrany (a nie znany M a priori) c1 = ab oraz c0 jest losowym skalarem a dane wyjściowe i mają prawdopodobieństwo

Dla niektoacuterych wielomianoacutew Q2 (k)Należy rozważyć algorytm SIMNIZKP (zbliżony to tego ktoacutery został zdefiniowany w [6]) ktoacutery jako skalary wejściowe wykorzystuje wektor x klucza prywatnego zbioacuter wektoroacutew kluczy

publicznych indeks π oraz wiadomość m i ktoacutery działa w sposoacuteb następujący1 Wygenerować skalary losowe s1 hellip sm oraz skalar losowy cπ lt- H2 Dla j indeksującego określić

A dla pozostałych j

3 Obliczyć losowe dane wyjściowe na podstawie losowego oracle

4 Dla każdego i roboczego mod m obliczyć

Należy podkreślić że w ostatnim punkcie kiedy i = π - 1 to ci+1 jest już określone w celu utrzymania spoacutejności z losowymi danymi wyjściowymi oracleNależy podkreślić że niezależnie od tego czy jest rzeczywistym kluczem prywatnym odpowiadającym ze względu na to że spoacutejność jest zachowywana przez losowe wartości oracle w kolejnych wezwaniach powyższy podpis jest weryfikowany Jeżeli x jest rzeczywiście wektorem klucza prywatnego y to nie ma roacuteżnicy pomiędzy SIMNIZKP oraz rzeczywistym podpisemNa koniec mając krotność (G aG bG ciG) gdzie a b są losowo wybrany skalarami a c1 = ab c0 elementem losowym i ϵ 0 1 M zachodzi w poniższych krokach i pozwala rozwiązać problem decyzyjny Diffie Helmana za pomocą niepomijalnego prawdopodobieństwa M wychwytuje losowe ϒ lt-H z losowej wartości oracle oraz pobiera parę wektoroacutew klucza prywatnego publicznego (x y) a następnie oblicza s jako a = s + ϒx Teraz M wykonuje

SIMNIZKP za pomocą dowolnie wybranych wektoroacutew kluczy w taki sposoacuteb że w danej wiadomości m oraz Jeżeli prawdziwe jest że i = 1 to c = ab oraz logGaG = logbGcG = a

z uwagi na to że zakłada się iż A jest w stanie znaleźć π z prawdopodobieństwem ktoacuterego nie można pominąć to istnieje niepomijalne prawdopodobieństwo frac12 że A zwroacuteci 1 (i wtedy M zwroacuteci 1) Jeżeli i = 0 to A zwraca 1 wyłącznie z prawdopodobieństwem frac12 a zatem dla niektoacuterych niepomijanych prawdopodobieństw powyżej 1`2 M zwraca tę samą wartość co A i tym samym rozwiązuje problem decyzyjny Diffie-Helmana dla losowo wybranych skalaroacutew bez pomijalnego prawdopodobieństwa powyżej 12 co stanowi sprzeczność

Załącznik B Kod demo Ring CT W repozytorium w [14] zbudowałem prostą demonstrację protokołu poufnych transakcji pierścieniowych (Ring Confidential Transactions) wykorzystujących podpisy MLSAG w części 2 oraz podpisy ASNL w części 5

H_ct = RingCTgetHForCT()print(H H_ct)sr Pr = PaperWalletskpkGen() receivers private publicse pe ss = ecdhecdhgen(Pr) compute shared secret ssdigits = 14 in practice it will be 14print(inputs)Cia L1a s2a sa ska = RingCTgenRangeProof(10000 digits)print(outputs)Cib L1b s2b sb skb = RingCTgenRangeProof(7000 digits)Cic L1c s2c sc skc = RingCTgenRangeProof(3000 digits)print(verifying range proofs of outputs)RingCTverRangeProof(Cib L1b s2b sb)RingCTverRangeProof(Cic L1c s2c sc)x P1 = PaperWalletskpkGen()P2 = PaperWalletpkGen()C2 = PaperWalletpkGen()some random commitment grabbed from the blockchainind = 0Ca = RingCTsumCi(Cia)Cb = RingCTsumCi(Cib)Cc = RingCTsumCi(Cic)sk = [x MiniNerosc_sub_keys(ska MiniNerosc_add_keys(skb skc))]

pk = [[P1 P2] [MiniNerosubKeys(Ca MiniNeroaddKeys(Cb Cc)) MiniNerosubKeys(C2 MiniNeroaddKeys(Cb Cc)) ] ]II cc ssVal = MLSAGMLSAG_Sign(pk sk ind)print(Sig verified MLSAGMLSAG_Ver(pk II cc ssVal) )print(Finding received amount corresponding to Cib)RingCTComputeReceivedAmount(pe sr MiniNeroaddScalars(ss skb) Cib)print(Finding received amount corresponding to Cic)RingCTComputeReceivedAmount(pe sr MiniNeroaddScalars(ss skc) Cic)

Przykład transakcji z danymi wejściowymi 10 000 oraz wyjściowymi 3 000 i 7 000(rsquoHrsquo rsquo61fe7f0f5a607a33427d01dd1fded5ffa03fae2e9df9ebccf2e0a2f5bd77a204rsquo)inputs(rsquob b in binaryrsquo 10000 [0 0 0 0 1 0 0 0 1 1 1 0 0 1])Generating Aggregate Schnorr Non-linkable Podpis pierścieniowy outputs(rsquob b in binaryrsquo 7000 [0 0 0 1 1 0 1 0 1 1 0 1 1 0])Generating Aggregate Schnorr Non-linkable Podpis pierścieniowy (rsquob b in binaryrsquo 3000 [0 0 0 1 1 1 0 1 1 1 0 1 0 0])Generating Aggregate Schnorr Non-linkable Podpis pierścieniowy verifying range proofs of outputsVerifying Aggregate Schnorr Non-linkable Podpis pierścieniowy VerifiedVerifying Aggregate Schnorr Non-linkable Podpis pierścieniowy Verified(rsquoGenerating MLSAG sig of dimensions rsquo 2 rsquox rsquo 2)(rsquoverifying MLSAG sig of dimensions rsquo 2 rsquox rsquo 2)(rsquocrsquo[rsquo80a3cfd06dd2862307cd75c2a1566f20cd743dbb0b9feb22d79dcbecb9023f42rsquorsquoa9b7342ba7bf2f102505ca19dab734fde638916c0a29f5b30e49833ab51393earsquorsquo80a3cfd06dd2862307cd75c2a1566f20cd743dbb0b9feb22d79dcbecb9023f42rsquo])(rsquosig verifiesrsquo True)(rsquoSig verifiedrsquo True)Finding received amount corresponding to Cib(rsquoreceived rsquo 7000c Monero Research Lab Page 20 of 20rsquoa488ec68732fb551841c2c6dcc7ffac895d98ec7e9378275ed20ea12805fc18ersquo)Finding received amount corresponding to Cic(rsquoreceived rsquo3000rsquo1b46626858e130a0f3884c74c9fdeabc4d812c519103ea16a35a3f82a3d0ed6drsquo)

hellip

stanowi uogoacutelniony pierścień w ktoacuterym chcemy złożyć swoacutej podpis Należy zauważyć że ostatnia kolumna to pierścień Ring-CT w rozumieniu rozdziału 4

Obliczyć podpis MLSAG sum na R

[4] Ponieważ zobowiązania wejściowe mogą być potencjalnie odziedziczone z poprzednich transakcji wystarczy rozważyć kwoty wyjściowe

W takim przypadku zgodnie z teorematem A2 nie może być sygnatariuszem żadnych dodatkowych niezlinkowanych podpisoacutew pierścieniowych w danym nadzbiorze P wszystkich takich par P = (PC) po podpisaniu sum

Uwaga 42 Złożoność przestrzeni powyższego protokołu Warto zauważyć że rozmiar podpisu sum na R zgodnie z definicją 41 jest w rzeczywistości mniejszy dla m gt 1 niż bieżący podpis pierścieniowy transakcji opartej na protokole CryptoNote [16] ktoacutera zawiera mnogie dane wejściowe Dzieje się tak dzięki wprowadzeniu zmian w rozmiarze w [8] do każdej kolumny Należy także podkreślić że prawdopodobnie nie jest konieczne umieszczanie obrazu klucza zobowiązania związanego z wyżej wymienionym podpisem Kolejne optymalizacje rozmiaru są możliwe i można je wykonać w podobny sposoacuteb

42 Konwersja widocznych denominacji na zobowiązaniaPonieważ Monero obecnie wykorzystuje blockchainowe widoczne skalary w celu stworzenia reprezentacji kwot ważne jest aby istniała możliwość (i sposoacuteb) konwersji z kwot widocznych na zobowiązania przy jednoczesnym zachowaniu anonimowości Tak naprawdę wcale nie jest to trudne Mając daną parę (P a) gdzie P jest kluczem publicznym a a stanowi kwotę może ona być wykorzystana jako dane wejściowe transakcji jako (P aH) i transakcja ta musi być zweryfikowana przez weryfikatora pod kątem kwoty wejściowej i jej przemnożenia przez punkt maskujący H oraz czy uzyskana wartość rzeczywiście wynosi aH Zatem jako pierwszy krok kwoty wejściowe nie zostaną ukryte ale ukryte zostaną dane wyjściowe transakcji oraz wszelkie niezbędne relacje o ktoacuterych mowa w rozdziale 4 pozostają ważne Należy podkreślić że range proof nie jest konieczny dla tych danych wejściowych

Uwaga 43 Oczywistą zaletą tej metody jest konwersja z kwot widocznych na zobowiązania oraz to że kwota coinoacutew wygenerowanych w procesie wydobycia jest weryfikowalna bez konieczności udziału elementu zaufanego Jest to przewaga protokołu Ring CT nad systemami płatniczymi takimi jak [4] ktoacutere obejmują fazę ustawień strony zaufanej

43 Opłaty transakcyjnePonieważ system Monero jest silnie zdecentralizowany (tzn proof of work) konieczne jest wynagradzanie goacuternikoacutew i dokonywanie opłat za każdą transakcję Pomaga to podnieść bezpieczeństwo sieci i zapobiegać rozdęcia blockchainu Opłaty te muszą być realizowane w postaci niezamaskowanej tzn Jako bH a nie xG + bH oraz w odniesieniu do pewnej standardowej kwoty b w taki sposoacuteb że goacuternik będzie moacutegł zweryfikować że b ∙ H = bH i tym samym że jest dość środkoacutew na opłatę transakcyjną przy jednoczesnym zachowaniu roacutewnań związanych z H w taki sposoacuteb że zostaną zachowane niezbędne relacje o ktoacuterych mowa w Rozdziale 4

44 Ring MultisignatureWarto zauważyć że prosta wersja t z m z n ring-multisignature [mnogich podpisoacutew pierścieniowych] może być zrealizowana w oparciu o podpisy MLSAG Umożliwia to grupie m uczestnikoacutew zbudowanie multisignature takiego że t uczestnikoacutew z liczby z m musi złożyć podpis aby był on uznany za ważny dodatkowo jest on dwuznaczny w odniesieniu do sygnatariusza klucze m są uczestnikami mieszczącymi się w ogoacutelnej liczbie n kluczy

Liczba n uczestnikoacutew w multisignature stanowi wspoacutelny sekret xe oraz klucz publiczny Pe ktoacutere mają wspoacutelne obrazy kluczy multisig

Ij = xeH(PejPj)

z Pj ndash publicznym kluczem uczestnika Każdy uczestnik multisignature dokonuje wyboru dodatkowych kluczy publicznych n -

m w blockchainie oraz tworzy podpis MLSAG za pomocą pierwszego rzędu wszystkich kluczy n a drugi rząd ma dla każdego wpisu (elementu) klucz wspoacutelny Pe

Każdy sygnatariusz multisignature podaje początkowe Ij j = 1 hellip m w celu umożliwienia zaakceptowania klucza po przekazaniu podpisoacutew weryfikujących t w blockchainie z ktoacuterych każdy odpowiada jednemu obrazowi klucza Ij

Rozszerzony zapis ring-multisignature jest w fazie opracowania

5 Zagregowane schematy identyfikacji Schnorra (Aggregate Schnorr Range Proofs)W części [11] poufne transakcja bez podpisu pierścieniowego wykorzystuje pewien typ podpisu pierścieniowego oparty na [1] nazywany podpisem pierścienia boromejskiego (Borromean ring signature) i pomaga zidentyfikować przekłamania w wartości zobowiązań w pewnym przedziale W niniejszym artykule postaram się nakreślić alternatywną metodę zainspirowaną przez [7] ktoacutera pozwala na uzyskanie tych samych oszczędności w zakresie przestrzeni ale za to opatrzona jest nieco mniej skomplikowanym protokołem bezpieczeństwa Motywacja do tego typu działania jest następująca przypuśćmy że dana transakcja ma dane wejściowe zobowiązań roacutewne

Cin = ainG + 10H

oraz zobowiązania wyjściowe

Cout 1 = aout1G + 5H Cout2 = aout2G + 5H

Scenariusz ten zachowuje ważność gdyż istnieje możliwość złożenia podpisu dla Cin ndash Cout1 ndash Cout2 = (ain ndash aout1 ndash aout2)G

Nie mniej jednak warto podkreślić że (bez range proofs) będzie istniała możliwość alternatywnego ustawienia zobowiązań wyjściowych

Cout1 = aout1G- H Cout2 = aout2G + 11H

Ponieważ -1 jest bardzo dużą liczbą stanowiącą modulo porządkujące grupę krzywej tym samym zostały utworzone darmowe pieniądze Zatem konieczne jest wykazanie że Couti są zobowiązaniami w odniesieniu do wartości ktoacutere są pozytywne (dodatnie) i mieszczą się w ograniczonym przedziale [0 2n] dla niektoacuterych wartości n Aby tego dokonać należy rozłożyć każdą wartość wyjściową na elementy binarne

co pozwala obliczyć zobowiązania do bj ∙ 2j w taki sposoacuteb że

Na koniec wykorzystując sekretny klucz bj można obliczyć podpis pierścieniowy na

dla wszystkich j oraz zapewnia dla weryfikatoroacutew (w tym przypadku goacuternikoacutew)Jeżeli chodzi o oszczędności miejsca można albo wykorzystać boromejski podpis pierścieniowy (podobnie jak w [11]) albo połączyć wszystkie proste podpisy pierścieniowe bądź utworzyć pewien typ zagregowanego podpisu pierścieniowego zdefiniowanego w następujący sposoacuteb

501 Generowanie zagregowanego nielinkowanego podpisu pierścieniowego Schnorra (Aggregate Schnorr Non-linkable Ring Signature) (ASNL)

Niech stanowi zbioacuter kluczy j = 1hellip z jako sekretnym kluczem

Dla każdego j niech Irsquo = i + 1 mod 2 ustawić skalar losowy aj i obliczyć

Ustawić gdzie Hs to kryptograficzna funkcja haszująca zwracająca skalar po dokonaniu wyboru losowego obliczyć

Określić i obliczyć

Zwroacutecić dla wszystkich j i s =

502 Weryfikacja zagregowanego nielinkowalnego podpisu pierścieniowego Schnorra (ASNL)Zacznijmy od dla j = 1hellip n oraz s

Dla wszystkich j obliczyć oraz

Jeżeli to otrzymamy 0 dla ważnego podpisuW przeciwnym razie otrzymamy wartość zwrotną -1

Teoremat 51 Zagregowany nielinkowany podpis pierścieniowy Schnorra nie może być sfałszowany przy założeniu logarytmu dyskretnego

Dowoacuted Przedstawiam szkic dowodu w przypadku n = 2 Przypadek ogoacutelny ma zbliżony charakter Przypuśćmy że adwersarz A jest w stanie sfałszować podpis ASNL na

Przy pomijalnym prawdopodobieństwie znając najwyżej jedną z (przypuśćmy że bez straty ogoacutelnego charakteru założenia że A zna ) Dla każdego danego fałszu

rozwiązuję roacutewnanie logarytmu dyskretnego o niepomijalnym prawdopodobieństwie Po zastosowaniu algorytmu weryfikacji niech Zatem prawdziwe musi być roacutewnanie

Przypuśćmy że oraz a a b są znane A wtedy

ponieważ jest określone protokołem weryfikacji musi być zatem prawdą że A zna klucz

prywatny

=Jest to w sprzeczności z założeniem logarytmu dyskretnego dla danej grupy

51 Reprezentacja kwotKwoty w protokole Ring CT można przedstawiać w sposoacuteb zbliżony do tego ktoacutery przedstawiony został w [11] z drobną modyfikacją w celu dopasowania do systemu Monero Coiny CryptoNote organizują nominały coinoacutew w bazie indeksoacutew w taki sposoacuteb aby mogły być ułożone w porządku występowania jako dane wejściowe dla podpisoacutew pierścieniowych Ponieważ wszystkie wartości coinoacutew w CryptoNote są reprezentowane w postaci 64-bitowych niepodpisanych liczb całkowitych możemy wykorzystać range proof na przestrzeni całego rejestru w celu zakodowania kwoty wyjściowej przekazywanej odbiorcy Na szczęście to także umożliwia wzajemne miksowanie danych wyjściowych zatem wymagany jest tylko jeden indeks danych wyjściowych w porządku rejestracji Przedział weryfikacji (range proof) wynosi ok 5 kilobajtoacutew Podpisy pierścieniowe dla danych wejściowych stają się bardziej odporne na analizę ponieważ anonimowość jest bardzo rozszerzonaPodczas gdy obszary weryfikacji (range proofs) są duże wykorzystywanie układu haszującego ktoacutery dodaje przedrostek do transakcji (zaroacutewno indeksoacutew wejściowych jak i wyjściowych) i przechowuje szeroki zakres range proof wraz z podpisami umożliwia oddzielnie uzyskanie ogromnych oszczędności przestrzeni podczas synchronizacji (syncing) do punktu weryfikacji lub działanie jako węzeł SPV Podobnie do elementoacutew bocznych łańcucha (Sidechains Elements) [12] będziemy przechowywać H(H(prefiks)||H(podpisy)) w drzewie Merkla Następnie węzły syncing do zaufanego punktu weryfikacji muszą jedynie pobrać przedrostek i dodać wartość haszującą do podpisoacutew skutecznie redukując szerokość wiązki Ponieważ prefiks transakcji wykorzystuje wariant dla danych wyjściowych ktoacutere wymienia w swoich podpisach pierścieniowych oraz środkach zapisanych do jednego klucza publicznego stanowi on miniaturowe poroacutewnanie do danych podpisoacutew pierścieniowych w danych wyjściowych oraz range proofs

Następnie podpisy pierścieniowe mogą nawet być przycięte z bazy danych przez niektoacutere węzły w celu uzyskania dalszych zyskoacutew przestrzeni przechowując zastępczo jedynie względnie mały zbioacuter UTXO

511 Przekazywanie informacji o kwotach OdbiorcyObecnie mając dowolną kwotę wyjściową b = b020 + b121 + ∙∙∙ bn2n nadawca oblicza nową prywatnąpubliczną parę kluczy oraz związane wymieniane sekrety ECDH ss oraz udostępnia następujące informacje w swojej transakcji

gdzie ai to losowo wybrane liczby dla j = 0 hellipn Dane Klucz publiczny ECDH oraz a + ss mod l gdzie a = a0 + hellip + an

Następnie odbiorca Oblicza udostępniany sekret ss oraz oblicza a na podstawie a + ss mod l Oblicza C = sumCi oblicza C ndash aG = bH oraz oblicza b poroacutewnując uzyskane wartości do

wszystkich bH w danym przedziale [0 2n] (W praktyce będzie to szybkie 500 kilobajtowe wyszukanie w n = 12 podobnie jak w poprzednim rozdziale Gdyby jednak wartość 232 została wybrana jako goacuterna wartość graniczna podobnie jak w [11] wyszukiwanie stałoby się dużym obliczeniowo wysiłkiem)

6 WnioskiProtokoacuteł pierścieniowych transakcji poufnych (Ring Confidential Transactions) to bardzo silnie zdecentralizowana kryptowaluta (tzn nie ma w niej żadnej uprzywilejowanej strony) ktoacutera posiada proste do udowodnienia wartości szacunkowe zabezpieczeń dotyczące ukrywania kwot transferoacutew ich źroacutedeł oraz odbiorcoacutew Dodatkowo generowanie coinoacutew w oparciu o protokoacuteł Ring Confidential Transactions nie wymaga obecności czynnika zaufanego i proces jego weryfikacji jest całkowicie bezpiecznyTych pięć czynnikoacutew jest niezbędnych w przypadku kryptowalut zbliżonych do środkoacutew gotoacutewkowych takich jak MoneroBibliografia1 Masayuki Abe Miyako Ohkubo and Koutarou Suzuki 1-out-of-n signatures from a variety of keys Advances in CryptologyAsiacrypt 2002 pages 415ndash432 20022 Adam Back Bitcoins with homomorphic value (validatable but encrypted)httpsbitcointalkorgindexphptopic=3057910 2013 [Online accessed 1-May-2015]3 Adam Back Podpis pierścieniowy efficiency httpsbitcointalkorgindexphptopic=972541msg10619684msg10619684 2015 [Online accessed 1-May-2015]4 Eli Ben Sasson Alessandro Chiesa Christina Garman Matthew Green Ian Miers Eran Tromer and Madars Virza Zerocash Decentralized anonymous payments from bitcoin In Security and Privacy (SP) 2014 IEEE Symposium on pages 459ndash474 IEEE 20145 Evan Duffield and Kyle Hagan Darkcoin Peertopeer cryptocurrency with anonymous blockchain transactions and an improved proofofwork system 20146 Eiichiro Fujisaki and Koutarou Suzuki Traceable podpis pierścieniowy In Public Key CryptographyndashPKC 2007 pages 181ndash200 Springer 20077 Javier Herranz Aggregate signatures httpwwwiiiacsices~jherranzpapersNijmegen_seminar_aggregatepdf oct 20058 Joseph K Liu Victor K Wei and Duncan S Wong Linkable spontaneous anonymous group signature for ad hoc groups In Information Security and Privacy pages 325ndash335 Springer 20049 Adam Mackenzie Surae Noether and Monero Core Team Improving obfuscation in the cryptonote protocol httpslabgetmoneroorgpubsMRL-0004pdf January 201510 Greg Maxwell Coinjoin Bitcoin privacy for the real world august 2013 Bitcoin Forum httpsbitcointalkorgindexphptopic=2792490 2013 [Online accessed 1-July-2015]11 Greg Maxwell Confidential Transactions httpspeoplexiphorg~gregconfidential_valuestxt 2015 [Online accessed 1-June-2015]12 Greg Maxwell Elements project httpsgithubcomShenNoetherMiniNero 201513 Satoshi Nakamoto Bitcoin A peer-to-peer electronic cash system Consulted 1(2012)28 200814 Shen Noether Mininero httpsgithubcomShenNoetherMiniNero 201515 Ronald L Rivest Adi Shamir and Yael Tauman How to leak a secret In Advances in CryptologyASIACRYPT 2001 pages 552ndash565 Springer 200116 Nicolas van Saberhagen Cryptonote v 2 0 HYPERLINK https cryptonote org whitepaper pdf 2013

Załącznik A Załącznik Security ProofsA1 Brak możliwości sfałszowania MLSAG

Obliczenia przebiegają analogicznie do [8 Teoremat 1] Niech H1 oraz H2 będą losowo wybranymi oracle a SO stanowią podpisy oracle zwracające ważne podpisy MLSAG Załoacuteżmy że istnieje probabilistyczny wielomianowy adwersarz czasowy (PPT) A ktoacutery posiada zdolność sfałszowania MLSAG z listy wektoroacutew kluczy L przy prawdopodobieństwie ktoacuterego nie można pominąć

Gdzie Q1 stanowi wielomianowy parametr bezpieczeństwa k oraz gdzie (m σ) nie stanowi jednego z podpisoacutew zwracanych przez SO Załoacuteżmy że A nie wysyła więcej niż qH + nqS

(gdzie n oznacza liczbę kluczy w L) zapytań dotyczących podpisoacutew oracle H1H2 oraz SO odpowiednio Podpisy oracle H1 oraz H2 uważa się za niezależne i losowe oraz spoacutejne z danymi zapytaniami powtarzającymi się Podpis oracle SO może składać zapytanie H1 oraz H2 Mając wartość A wykaże że istnieje możliwość utworzenia adwersarza M w PPT ktoacutery będzie wykorzystywać A w celu znalezienia logarytmu dyskretnego jednego z kluczy w L

Jeżeli L stanowi zbioacuter kluczy wektoroacutew z ktoacuterych każdy będzie mieć wielkość r (tzn z kluczami publicznymi y1 hellip yr ) to wygenerowany fałszywy podpis

Wygenerowany przez A musi spełniać warunek

Gdzie i są obliczone w ramach mod n oraz są zdefiniowane zgodnie z Rozdziałem 22 Nowy adwersarz M może wykorzystać A w celu sfałszowania podpisoacutew wielomianową liczbę razy i zapisze każdy skrypt Turinga T niezależnie czy sfałszowanie było skuteczne czy nie

Lemma A1 [8 Lemma 1] Niech M wywołuje A w celu uzyskania transkrypcji T Jeżeli T jest skuteczne to M powraca do T do nagłoacutewka H i następnie re-symuluje A w celu uzyskania transkrypcji Trsquo Jeżeli Pr (T okaże się skuteczne) = ϵ to Pr (Trsquo jest skuteczne) = ϵ

Dowoacuted wynika wprost z przywołanego teorematu

Teoremat A2 Prawdopodobieństwo że adwersarz A sfałszuje podpis MLSAG można pominąć przy założeniu logarytmu dyskretnego

Dowoacuted Do przeprowadzenia dowodu będę stosować notację przedstawioną powyżej Podobnie jak w przypadku [8 teoremat 1] ponieważ prawdopodobieństwo odgadnięcia danych wyjściowych z losowego oracle jest znikome w związku z tym dla każdego skutecznego oszustwa A wprowadza transkrypcję uzupełniającą T a zatem mamy mT zapytań w przypadku zapytań do H1 odpowiadających liczbie n zapytań wykorzystywanych w celu weryfikacji podpisu W związku z tym niech Xi1 hellip Xim oznacza zapytania wykorzystywane w procesie weryfikacji fałszu ith oraz niech π oznacza indeks odpowiadający ostatniemu zapytaniu weryfikacyjnego dla danego oszustwa

(Intuicyjnie π odpowiada temu co może stanowić indeks sekretny fałszywego podpisu ponieważ odpowiada on ostatniemu wezwaniu ostatniemu wywołaniu losowego oracle dla danego odpisu)Proacuteba sfałszowania σ podjęta przez A stanowi fałsz (l π) jeżeli i1 = l oraz π jest zgodne z powyższym (zatem fałsz odpowiada zapytaniom l do l + π) Z założenia istnieje para (l π) taka że prawdopodobieństwo związanej transkrypcji T daje skutecznie wygenerowany fałszywy klucz ϵlπ (T) spełnia warunek

1

Teraz przeglądając T do wartości przed zapytaniem l-tym a następnie podejmując proacutebę sfałszowania za pomocą tego samego zbioru kluczy (oraz dopuszczając aby H1 obliczyło nowe rzuty monetami dla wszystkich kolejnych zapytań) z Lemmy A1 wynika że prawdopodobieństwo że Trsquo jest także skuteczne spełnia warunki

_Dlatego prawdopodobieństwo że zaroacutewno T jak i Trsquo odpowiadają weryfikacjom fałszywym σ i σ1 nie może zostać pominięte

Ponieważ nowe rzuty monetami zostały obliczone na podstawie danych wyjściowych losowych oracle H1 oznacza to że przy dużym prawdopodobieństwie istnieje wartość j taka

że oraz W związku z tym możemy rozwiązać klucz prywatny z indeksem π

ktoacutery jest sprzeczny z założeniami logarytmu dyskretnego

A2 Linkowalność MLSAG Teoremat A3 Linkowalność obrazu klucza (Key-Image Linkability) Prawdopodobieństwo że adwersarz a w PPT może utworzyć dwa podpisy weryfikujące (niepołączone w danym

ustawieniu σ σrsquo podpisane w odniesieniu do wektoroacutew kluczy oraz odpowiednio w taki

sposoacuteb że będzie istnieć klucz publiczny i w obu oraz może być pominięte

Dowoacuted Przypuśćmy że w przeciwieństwie do tego co zostało wcześniej powiedziane A utworzył dwa podpisy weryfikujące σ oraz σrsquo o oba są podpisami w odniesieniu do kluczowych wektoroacutew

oraz odpowiednio w taki sposoacuteb że istnieje klucz publiczny y zaroacutewno w jak i

Niech y występuje jako element j należący do a jrsquo jako element należący do rsquo Z teorematu A2 wynika z dużym prawdopodobieństwem że istnieją indeksy π oraz πrsquo dla kluczy publicznych σ oraz σrsquo odpowiednio takie że

oraz

z

oraz

Jeżeli uznamy że x oznacza klucz prywatny y y = xG to po rozwiązaniu powyższego dla Ij

oraz Ij0rsquo mamy następujące roacutewnania oraz podobnie Ijrsquo = xH (y) Tym samym dwa podpisy obejmują Ij = Ijrsquo i w związku z tym ponieważ zduplikowane obrazy kluczy są odrzucone jeden z nich nie może być wykorzystany do weryfikacji

A3 Anonimowość MLSAG W celu udowodnienia anonimowości powyższego protokołu w losowym modelu oracle przyjmijmy że H1 H2 to losowe oracle modelujące dyskretne funkcje haszujące Niech A to adwersarz anonimowości Buduję adwersarza M względem założenia problemu decyzyjnego Diffie Helmana (DDH) zgodnie z poniższym Założenie DDH stwierdza że mając daną krotność (G aG bG ϒG) prawdopodobieństwo ustalenia czy G = abG jest znikome

Teoremat A4 Protokoacuteł pierścieniowy CT jest dwuznaczny w odniesieniu do sygnatariusza przy założeniu problemu decyzyjnego Diffie-HelmanaDowoacuted (zbliżony do dowodu [8 Teoremat 2]) Załoacuteżmy że problem decyzyjny Diffie-Helmana jest trudny w cyklicznej grupie generowanej przez G i załoacuteżmy że istnieje adwersarz A w czasie PPT względem dwuznaczności sygnatariusza Tym samym mając listę L n wektoroacutew

kluczy publicznych o długości m oraz zbioacuter prywatnych kluczy t ważny podpis σ na L podpisany przez użytkownika w odniesieniu do wektora klucza y taki że

odpowiedni wektor klucza prywatnego wynosi spełnia to A może zdeterminować π z prawdopodobieństwem

Dla wybranych wielomianoacutew Q(k) Buduję adwersarza PPT M ktoacutery wykorzystuje krotność danych wejściowych (G aG bG ciG) gdzie I ϵ 0 1 jest losowo wybrany (a nie znany M a priori) c1 = ab oraz c0 jest losowym skalarem a dane wyjściowe i mają prawdopodobieństwo

Dla niektoacuterych wielomianoacutew Q2 (k)Należy rozważyć algorytm SIMNIZKP (zbliżony to tego ktoacutery został zdefiniowany w [6]) ktoacutery jako skalary wejściowe wykorzystuje wektor x klucza prywatnego zbioacuter wektoroacutew kluczy

publicznych indeks π oraz wiadomość m i ktoacutery działa w sposoacuteb następujący1 Wygenerować skalary losowe s1 hellip sm oraz skalar losowy cπ lt- H2 Dla j indeksującego określić

A dla pozostałych j

3 Obliczyć losowe dane wyjściowe na podstawie losowego oracle

4 Dla każdego i roboczego mod m obliczyć

Należy podkreślić że w ostatnim punkcie kiedy i = π - 1 to ci+1 jest już określone w celu utrzymania spoacutejności z losowymi danymi wyjściowymi oracleNależy podkreślić że niezależnie od tego czy jest rzeczywistym kluczem prywatnym odpowiadającym ze względu na to że spoacutejność jest zachowywana przez losowe wartości oracle w kolejnych wezwaniach powyższy podpis jest weryfikowany Jeżeli x jest rzeczywiście wektorem klucza prywatnego y to nie ma roacuteżnicy pomiędzy SIMNIZKP oraz rzeczywistym podpisemNa koniec mając krotność (G aG bG ciG) gdzie a b są losowo wybrany skalarami a c1 = ab c0 elementem losowym i ϵ 0 1 M zachodzi w poniższych krokach i pozwala rozwiązać problem decyzyjny Diffie Helmana za pomocą niepomijalnego prawdopodobieństwa M wychwytuje losowe ϒ lt-H z losowej wartości oracle oraz pobiera parę wektoroacutew klucza prywatnego publicznego (x y) a następnie oblicza s jako a = s + ϒx Teraz M wykonuje

SIMNIZKP za pomocą dowolnie wybranych wektoroacutew kluczy w taki sposoacuteb że w danej wiadomości m oraz Jeżeli prawdziwe jest że i = 1 to c = ab oraz logGaG = logbGcG = a

z uwagi na to że zakłada się iż A jest w stanie znaleźć π z prawdopodobieństwem ktoacuterego nie można pominąć to istnieje niepomijalne prawdopodobieństwo frac12 że A zwroacuteci 1 (i wtedy M zwroacuteci 1) Jeżeli i = 0 to A zwraca 1 wyłącznie z prawdopodobieństwem frac12 a zatem dla niektoacuterych niepomijanych prawdopodobieństw powyżej 1`2 M zwraca tę samą wartość co A i tym samym rozwiązuje problem decyzyjny Diffie-Helmana dla losowo wybranych skalaroacutew bez pomijalnego prawdopodobieństwa powyżej 12 co stanowi sprzeczność

Załącznik B Kod demo Ring CT W repozytorium w [14] zbudowałem prostą demonstrację protokołu poufnych transakcji pierścieniowych (Ring Confidential Transactions) wykorzystujących podpisy MLSAG w części 2 oraz podpisy ASNL w części 5

H_ct = RingCTgetHForCT()print(H H_ct)sr Pr = PaperWalletskpkGen() receivers private publicse pe ss = ecdhecdhgen(Pr) compute shared secret ssdigits = 14 in practice it will be 14print(inputs)Cia L1a s2a sa ska = RingCTgenRangeProof(10000 digits)print(outputs)Cib L1b s2b sb skb = RingCTgenRangeProof(7000 digits)Cic L1c s2c sc skc = RingCTgenRangeProof(3000 digits)print(verifying range proofs of outputs)RingCTverRangeProof(Cib L1b s2b sb)RingCTverRangeProof(Cic L1c s2c sc)x P1 = PaperWalletskpkGen()P2 = PaperWalletpkGen()C2 = PaperWalletpkGen()some random commitment grabbed from the blockchainind = 0Ca = RingCTsumCi(Cia)Cb = RingCTsumCi(Cib)Cc = RingCTsumCi(Cic)sk = [x MiniNerosc_sub_keys(ska MiniNerosc_add_keys(skb skc))]

pk = [[P1 P2] [MiniNerosubKeys(Ca MiniNeroaddKeys(Cb Cc)) MiniNerosubKeys(C2 MiniNeroaddKeys(Cb Cc)) ] ]II cc ssVal = MLSAGMLSAG_Sign(pk sk ind)print(Sig verified MLSAGMLSAG_Ver(pk II cc ssVal) )print(Finding received amount corresponding to Cib)RingCTComputeReceivedAmount(pe sr MiniNeroaddScalars(ss skb) Cib)print(Finding received amount corresponding to Cic)RingCTComputeReceivedAmount(pe sr MiniNeroaddScalars(ss skc) Cic)

Przykład transakcji z danymi wejściowymi 10 000 oraz wyjściowymi 3 000 i 7 000(rsquoHrsquo rsquo61fe7f0f5a607a33427d01dd1fded5ffa03fae2e9df9ebccf2e0a2f5bd77a204rsquo)inputs(rsquob b in binaryrsquo 10000 [0 0 0 0 1 0 0 0 1 1 1 0 0 1])Generating Aggregate Schnorr Non-linkable Podpis pierścieniowy outputs(rsquob b in binaryrsquo 7000 [0 0 0 1 1 0 1 0 1 1 0 1 1 0])Generating Aggregate Schnorr Non-linkable Podpis pierścieniowy (rsquob b in binaryrsquo 3000 [0 0 0 1 1 1 0 1 1 1 0 1 0 0])Generating Aggregate Schnorr Non-linkable Podpis pierścieniowy verifying range proofs of outputsVerifying Aggregate Schnorr Non-linkable Podpis pierścieniowy VerifiedVerifying Aggregate Schnorr Non-linkable Podpis pierścieniowy Verified(rsquoGenerating MLSAG sig of dimensions rsquo 2 rsquox rsquo 2)(rsquoverifying MLSAG sig of dimensions rsquo 2 rsquox rsquo 2)(rsquocrsquo[rsquo80a3cfd06dd2862307cd75c2a1566f20cd743dbb0b9feb22d79dcbecb9023f42rsquorsquoa9b7342ba7bf2f102505ca19dab734fde638916c0a29f5b30e49833ab51393earsquorsquo80a3cfd06dd2862307cd75c2a1566f20cd743dbb0b9feb22d79dcbecb9023f42rsquo])(rsquosig verifiesrsquo True)(rsquoSig verifiedrsquo True)Finding received amount corresponding to Cib(rsquoreceived rsquo 7000c Monero Research Lab Page 20 of 20rsquoa488ec68732fb551841c2c6dcc7ffac895d98ec7e9378275ed20ea12805fc18ersquo)Finding received amount corresponding to Cic(rsquoreceived rsquo3000rsquo1b46626858e130a0f3884c74c9fdeabc4d812c519103ea16a35a3f82a3d0ed6drsquo)

44 Ring MultisignatureWarto zauważyć że prosta wersja t z m z n ring-multisignature [mnogich podpisoacutew pierścieniowych] może być zrealizowana w oparciu o podpisy MLSAG Umożliwia to grupie m uczestnikoacutew zbudowanie multisignature takiego że t uczestnikoacutew z liczby z m musi złożyć podpis aby był on uznany za ważny dodatkowo jest on dwuznaczny w odniesieniu do sygnatariusza klucze m są uczestnikami mieszczącymi się w ogoacutelnej liczbie n kluczy

Liczba n uczestnikoacutew w multisignature stanowi wspoacutelny sekret xe oraz klucz publiczny Pe ktoacutere mają wspoacutelne obrazy kluczy multisig

Ij = xeH(PejPj)

z Pj ndash publicznym kluczem uczestnika Każdy uczestnik multisignature dokonuje wyboru dodatkowych kluczy publicznych n -

m w blockchainie oraz tworzy podpis MLSAG za pomocą pierwszego rzędu wszystkich kluczy n a drugi rząd ma dla każdego wpisu (elementu) klucz wspoacutelny Pe

Każdy sygnatariusz multisignature podaje początkowe Ij j = 1 hellip m w celu umożliwienia zaakceptowania klucza po przekazaniu podpisoacutew weryfikujących t w blockchainie z ktoacuterych każdy odpowiada jednemu obrazowi klucza Ij

Rozszerzony zapis ring-multisignature jest w fazie opracowania

5 Zagregowane schematy identyfikacji Schnorra (Aggregate Schnorr Range Proofs)W części [11] poufne transakcja bez podpisu pierścieniowego wykorzystuje pewien typ podpisu pierścieniowego oparty na [1] nazywany podpisem pierścienia boromejskiego (Borromean ring signature) i pomaga zidentyfikować przekłamania w wartości zobowiązań w pewnym przedziale W niniejszym artykule postaram się nakreślić alternatywną metodę zainspirowaną przez [7] ktoacutera pozwala na uzyskanie tych samych oszczędności w zakresie przestrzeni ale za to opatrzona jest nieco mniej skomplikowanym protokołem bezpieczeństwa Motywacja do tego typu działania jest następująca przypuśćmy że dana transakcja ma dane wejściowe zobowiązań roacutewne

Cin = ainG + 10H

oraz zobowiązania wyjściowe

Cout 1 = aout1G + 5H Cout2 = aout2G + 5H

Scenariusz ten zachowuje ważność gdyż istnieje możliwość złożenia podpisu dla Cin ndash Cout1 ndash Cout2 = (ain ndash aout1 ndash aout2)G

Nie mniej jednak warto podkreślić że (bez range proofs) będzie istniała możliwość alternatywnego ustawienia zobowiązań wyjściowych

Cout1 = aout1G- H Cout2 = aout2G + 11H

Ponieważ -1 jest bardzo dużą liczbą stanowiącą modulo porządkujące grupę krzywej tym samym zostały utworzone darmowe pieniądze Zatem konieczne jest wykazanie że Couti są zobowiązaniami w odniesieniu do wartości ktoacutere są pozytywne (dodatnie) i mieszczą się w ograniczonym przedziale [0 2n] dla niektoacuterych wartości n Aby tego dokonać należy rozłożyć każdą wartość wyjściową na elementy binarne

co pozwala obliczyć zobowiązania do bj ∙ 2j w taki sposoacuteb że

Na koniec wykorzystując sekretny klucz bj można obliczyć podpis pierścieniowy na

dla wszystkich j oraz zapewnia dla weryfikatoroacutew (w tym przypadku goacuternikoacutew)Jeżeli chodzi o oszczędności miejsca można albo wykorzystać boromejski podpis pierścieniowy (podobnie jak w [11]) albo połączyć wszystkie proste podpisy pierścieniowe bądź utworzyć pewien typ zagregowanego podpisu pierścieniowego zdefiniowanego w następujący sposoacuteb

501 Generowanie zagregowanego nielinkowanego podpisu pierścieniowego Schnorra (Aggregate Schnorr Non-linkable Ring Signature) (ASNL)

Niech stanowi zbioacuter kluczy j = 1hellip z jako sekretnym kluczem

Dla każdego j niech Irsquo = i + 1 mod 2 ustawić skalar losowy aj i obliczyć

Ustawić gdzie Hs to kryptograficzna funkcja haszująca zwracająca skalar po dokonaniu wyboru losowego obliczyć

Określić i obliczyć

Zwroacutecić dla wszystkich j i s =

502 Weryfikacja zagregowanego nielinkowalnego podpisu pierścieniowego Schnorra (ASNL)Zacznijmy od dla j = 1hellip n oraz s

Dla wszystkich j obliczyć oraz

Jeżeli to otrzymamy 0 dla ważnego podpisuW przeciwnym razie otrzymamy wartość zwrotną -1

Teoremat 51 Zagregowany nielinkowany podpis pierścieniowy Schnorra nie może być sfałszowany przy założeniu logarytmu dyskretnego

Dowoacuted Przedstawiam szkic dowodu w przypadku n = 2 Przypadek ogoacutelny ma zbliżony charakter Przypuśćmy że adwersarz A jest w stanie sfałszować podpis ASNL na

Przy pomijalnym prawdopodobieństwie znając najwyżej jedną z (przypuśćmy że bez straty ogoacutelnego charakteru założenia że A zna ) Dla każdego danego fałszu

rozwiązuję roacutewnanie logarytmu dyskretnego o niepomijalnym prawdopodobieństwie Po zastosowaniu algorytmu weryfikacji niech Zatem prawdziwe musi być roacutewnanie

Przypuśćmy że oraz a a b są znane A wtedy

ponieważ jest określone protokołem weryfikacji musi być zatem prawdą że A zna klucz

prywatny

=Jest to w sprzeczności z założeniem logarytmu dyskretnego dla danej grupy

51 Reprezentacja kwotKwoty w protokole Ring CT można przedstawiać w sposoacuteb zbliżony do tego ktoacutery przedstawiony został w [11] z drobną modyfikacją w celu dopasowania do systemu Monero Coiny CryptoNote organizują nominały coinoacutew w bazie indeksoacutew w taki sposoacuteb aby mogły być ułożone w porządku występowania jako dane wejściowe dla podpisoacutew pierścieniowych Ponieważ wszystkie wartości coinoacutew w CryptoNote są reprezentowane w postaci 64-bitowych niepodpisanych liczb całkowitych możemy wykorzystać range proof na przestrzeni całego rejestru w celu zakodowania kwoty wyjściowej przekazywanej odbiorcy Na szczęście to także umożliwia wzajemne miksowanie danych wyjściowych zatem wymagany jest tylko jeden indeks danych wyjściowych w porządku rejestracji Przedział weryfikacji (range proof) wynosi ok 5 kilobajtoacutew Podpisy pierścieniowe dla danych wejściowych stają się bardziej odporne na analizę ponieważ anonimowość jest bardzo rozszerzonaPodczas gdy obszary weryfikacji (range proofs) są duże wykorzystywanie układu haszującego ktoacutery dodaje przedrostek do transakcji (zaroacutewno indeksoacutew wejściowych jak i wyjściowych) i przechowuje szeroki zakres range proof wraz z podpisami umożliwia oddzielnie uzyskanie ogromnych oszczędności przestrzeni podczas synchronizacji (syncing) do punktu weryfikacji lub działanie jako węzeł SPV Podobnie do elementoacutew bocznych łańcucha (Sidechains Elements) [12] będziemy przechowywać H(H(prefiks)||H(podpisy)) w drzewie Merkla Następnie węzły syncing do zaufanego punktu weryfikacji muszą jedynie pobrać przedrostek i dodać wartość haszującą do podpisoacutew skutecznie redukując szerokość wiązki Ponieważ prefiks transakcji wykorzystuje wariant dla danych wyjściowych ktoacutere wymienia w swoich podpisach pierścieniowych oraz środkach zapisanych do jednego klucza publicznego stanowi on miniaturowe poroacutewnanie do danych podpisoacutew pierścieniowych w danych wyjściowych oraz range proofs

Następnie podpisy pierścieniowe mogą nawet być przycięte z bazy danych przez niektoacutere węzły w celu uzyskania dalszych zyskoacutew przestrzeni przechowując zastępczo jedynie względnie mały zbioacuter UTXO

511 Przekazywanie informacji o kwotach OdbiorcyObecnie mając dowolną kwotę wyjściową b = b020 + b121 + ∙∙∙ bn2n nadawca oblicza nową prywatnąpubliczną parę kluczy oraz związane wymieniane sekrety ECDH ss oraz udostępnia następujące informacje w swojej transakcji

gdzie ai to losowo wybrane liczby dla j = 0 hellipn Dane Klucz publiczny ECDH oraz a + ss mod l gdzie a = a0 + hellip + an

Następnie odbiorca Oblicza udostępniany sekret ss oraz oblicza a na podstawie a + ss mod l Oblicza C = sumCi oblicza C ndash aG = bH oraz oblicza b poroacutewnując uzyskane wartości do

wszystkich bH w danym przedziale [0 2n] (W praktyce będzie to szybkie 500 kilobajtowe wyszukanie w n = 12 podobnie jak w poprzednim rozdziale Gdyby jednak wartość 232 została wybrana jako goacuterna wartość graniczna podobnie jak w [11] wyszukiwanie stałoby się dużym obliczeniowo wysiłkiem)

6 WnioskiProtokoacuteł pierścieniowych transakcji poufnych (Ring Confidential Transactions) to bardzo silnie zdecentralizowana kryptowaluta (tzn nie ma w niej żadnej uprzywilejowanej strony) ktoacutera posiada proste do udowodnienia wartości szacunkowe zabezpieczeń dotyczące ukrywania kwot transferoacutew ich źroacutedeł oraz odbiorcoacutew Dodatkowo generowanie coinoacutew w oparciu o protokoacuteł Ring Confidential Transactions nie wymaga obecności czynnika zaufanego i proces jego weryfikacji jest całkowicie bezpiecznyTych pięć czynnikoacutew jest niezbędnych w przypadku kryptowalut zbliżonych do środkoacutew gotoacutewkowych takich jak MoneroBibliografia1 Masayuki Abe Miyako Ohkubo and Koutarou Suzuki 1-out-of-n signatures from a variety of keys Advances in CryptologyAsiacrypt 2002 pages 415ndash432 20022 Adam Back Bitcoins with homomorphic value (validatable but encrypted)httpsbitcointalkorgindexphptopic=3057910 2013 [Online accessed 1-May-2015]3 Adam Back Podpis pierścieniowy efficiency httpsbitcointalkorgindexphptopic=972541msg10619684msg10619684 2015 [Online accessed 1-May-2015]4 Eli Ben Sasson Alessandro Chiesa Christina Garman Matthew Green Ian Miers Eran Tromer and Madars Virza Zerocash Decentralized anonymous payments from bitcoin In Security and Privacy (SP) 2014 IEEE Symposium on pages 459ndash474 IEEE 20145 Evan Duffield and Kyle Hagan Darkcoin Peertopeer cryptocurrency with anonymous blockchain transactions and an improved proofofwork system 20146 Eiichiro Fujisaki and Koutarou Suzuki Traceable podpis pierścieniowy In Public Key CryptographyndashPKC 2007 pages 181ndash200 Springer 20077 Javier Herranz Aggregate signatures httpwwwiiiacsices~jherranzpapersNijmegen_seminar_aggregatepdf oct 20058 Joseph K Liu Victor K Wei and Duncan S Wong Linkable spontaneous anonymous group signature for ad hoc groups In Information Security and Privacy pages 325ndash335 Springer 20049 Adam Mackenzie Surae Noether and Monero Core Team Improving obfuscation in the cryptonote protocol httpslabgetmoneroorgpubsMRL-0004pdf January 201510 Greg Maxwell Coinjoin Bitcoin privacy for the real world august 2013 Bitcoin Forum httpsbitcointalkorgindexphptopic=2792490 2013 [Online accessed 1-July-2015]11 Greg Maxwell Confidential Transactions httpspeoplexiphorg~gregconfidential_valuestxt 2015 [Online accessed 1-June-2015]12 Greg Maxwell Elements project httpsgithubcomShenNoetherMiniNero 201513 Satoshi Nakamoto Bitcoin A peer-to-peer electronic cash system Consulted 1(2012)28 200814 Shen Noether Mininero httpsgithubcomShenNoetherMiniNero 201515 Ronald L Rivest Adi Shamir and Yael Tauman How to leak a secret In Advances in CryptologyASIACRYPT 2001 pages 552ndash565 Springer 200116 Nicolas van Saberhagen Cryptonote v 2 0 HYPERLINK https cryptonote org whitepaper pdf 2013

Załącznik A Załącznik Security ProofsA1 Brak możliwości sfałszowania MLSAG

Obliczenia przebiegają analogicznie do [8 Teoremat 1] Niech H1 oraz H2 będą losowo wybranymi oracle a SO stanowią podpisy oracle zwracające ważne podpisy MLSAG Załoacuteżmy że istnieje probabilistyczny wielomianowy adwersarz czasowy (PPT) A ktoacutery posiada zdolność sfałszowania MLSAG z listy wektoroacutew kluczy L przy prawdopodobieństwie ktoacuterego nie można pominąć

Gdzie Q1 stanowi wielomianowy parametr bezpieczeństwa k oraz gdzie (m σ) nie stanowi jednego z podpisoacutew zwracanych przez SO Załoacuteżmy że A nie wysyła więcej niż qH + nqS

(gdzie n oznacza liczbę kluczy w L) zapytań dotyczących podpisoacutew oracle H1H2 oraz SO odpowiednio Podpisy oracle H1 oraz H2 uważa się za niezależne i losowe oraz spoacutejne z danymi zapytaniami powtarzającymi się Podpis oracle SO może składać zapytanie H1 oraz H2 Mając wartość A wykaże że istnieje możliwość utworzenia adwersarza M w PPT ktoacutery będzie wykorzystywać A w celu znalezienia logarytmu dyskretnego jednego z kluczy w L

Jeżeli L stanowi zbioacuter kluczy wektoroacutew z ktoacuterych każdy będzie mieć wielkość r (tzn z kluczami publicznymi y1 hellip yr ) to wygenerowany fałszywy podpis

Wygenerowany przez A musi spełniać warunek

Gdzie i są obliczone w ramach mod n oraz są zdefiniowane zgodnie z Rozdziałem 22 Nowy adwersarz M może wykorzystać A w celu sfałszowania podpisoacutew wielomianową liczbę razy i zapisze każdy skrypt Turinga T niezależnie czy sfałszowanie było skuteczne czy nie

Lemma A1 [8 Lemma 1] Niech M wywołuje A w celu uzyskania transkrypcji T Jeżeli T jest skuteczne to M powraca do T do nagłoacutewka H i następnie re-symuluje A w celu uzyskania transkrypcji Trsquo Jeżeli Pr (T okaże się skuteczne) = ϵ to Pr (Trsquo jest skuteczne) = ϵ

Dowoacuted wynika wprost z przywołanego teorematu

Teoremat A2 Prawdopodobieństwo że adwersarz A sfałszuje podpis MLSAG można pominąć przy założeniu logarytmu dyskretnego

Dowoacuted Do przeprowadzenia dowodu będę stosować notację przedstawioną powyżej Podobnie jak w przypadku [8 teoremat 1] ponieważ prawdopodobieństwo odgadnięcia danych wyjściowych z losowego oracle jest znikome w związku z tym dla każdego skutecznego oszustwa A wprowadza transkrypcję uzupełniającą T a zatem mamy mT zapytań w przypadku zapytań do H1 odpowiadających liczbie n zapytań wykorzystywanych w celu weryfikacji podpisu W związku z tym niech Xi1 hellip Xim oznacza zapytania wykorzystywane w procesie weryfikacji fałszu ith oraz niech π oznacza indeks odpowiadający ostatniemu zapytaniu weryfikacyjnego dla danego oszustwa

(Intuicyjnie π odpowiada temu co może stanowić indeks sekretny fałszywego podpisu ponieważ odpowiada on ostatniemu wezwaniu ostatniemu wywołaniu losowego oracle dla danego odpisu)Proacuteba sfałszowania σ podjęta przez A stanowi fałsz (l π) jeżeli i1 = l oraz π jest zgodne z powyższym (zatem fałsz odpowiada zapytaniom l do l + π) Z założenia istnieje para (l π) taka że prawdopodobieństwo związanej transkrypcji T daje skutecznie wygenerowany fałszywy klucz ϵlπ (T) spełnia warunek

1

Teraz przeglądając T do wartości przed zapytaniem l-tym a następnie podejmując proacutebę sfałszowania za pomocą tego samego zbioru kluczy (oraz dopuszczając aby H1 obliczyło nowe rzuty monetami dla wszystkich kolejnych zapytań) z Lemmy A1 wynika że prawdopodobieństwo że Trsquo jest także skuteczne spełnia warunki

_Dlatego prawdopodobieństwo że zaroacutewno T jak i Trsquo odpowiadają weryfikacjom fałszywym σ i σ1 nie może zostać pominięte

Ponieważ nowe rzuty monetami zostały obliczone na podstawie danych wyjściowych losowych oracle H1 oznacza to że przy dużym prawdopodobieństwie istnieje wartość j taka

że oraz W związku z tym możemy rozwiązać klucz prywatny z indeksem π

ktoacutery jest sprzeczny z założeniami logarytmu dyskretnego

A2 Linkowalność MLSAG Teoremat A3 Linkowalność obrazu klucza (Key-Image Linkability) Prawdopodobieństwo że adwersarz a w PPT może utworzyć dwa podpisy weryfikujące (niepołączone w danym

ustawieniu σ σrsquo podpisane w odniesieniu do wektoroacutew kluczy oraz odpowiednio w taki

sposoacuteb że będzie istnieć klucz publiczny i w obu oraz może być pominięte

Dowoacuted Przypuśćmy że w przeciwieństwie do tego co zostało wcześniej powiedziane A utworzył dwa podpisy weryfikujące σ oraz σrsquo o oba są podpisami w odniesieniu do kluczowych wektoroacutew

oraz odpowiednio w taki sposoacuteb że istnieje klucz publiczny y zaroacutewno w jak i

Niech y występuje jako element j należący do a jrsquo jako element należący do rsquo Z teorematu A2 wynika z dużym prawdopodobieństwem że istnieją indeksy π oraz πrsquo dla kluczy publicznych σ oraz σrsquo odpowiednio takie że

oraz

z

oraz

Jeżeli uznamy że x oznacza klucz prywatny y y = xG to po rozwiązaniu powyższego dla Ij

oraz Ij0rsquo mamy następujące roacutewnania oraz podobnie Ijrsquo = xH (y) Tym samym dwa podpisy obejmują Ij = Ijrsquo i w związku z tym ponieważ zduplikowane obrazy kluczy są odrzucone jeden z nich nie może być wykorzystany do weryfikacji

A3 Anonimowość MLSAG W celu udowodnienia anonimowości powyższego protokołu w losowym modelu oracle przyjmijmy że H1 H2 to losowe oracle modelujące dyskretne funkcje haszujące Niech A to adwersarz anonimowości Buduję adwersarza M względem założenia problemu decyzyjnego Diffie Helmana (DDH) zgodnie z poniższym Założenie DDH stwierdza że mając daną krotność (G aG bG ϒG) prawdopodobieństwo ustalenia czy G = abG jest znikome

Teoremat A4 Protokoacuteł pierścieniowy CT jest dwuznaczny w odniesieniu do sygnatariusza przy założeniu problemu decyzyjnego Diffie-HelmanaDowoacuted (zbliżony do dowodu [8 Teoremat 2]) Załoacuteżmy że problem decyzyjny Diffie-Helmana jest trudny w cyklicznej grupie generowanej przez G i załoacuteżmy że istnieje adwersarz A w czasie PPT względem dwuznaczności sygnatariusza Tym samym mając listę L n wektoroacutew

kluczy publicznych o długości m oraz zbioacuter prywatnych kluczy t ważny podpis σ na L podpisany przez użytkownika w odniesieniu do wektora klucza y taki że

odpowiedni wektor klucza prywatnego wynosi spełnia to A może zdeterminować π z prawdopodobieństwem

Dla wybranych wielomianoacutew Q(k) Buduję adwersarza PPT M ktoacutery wykorzystuje krotność danych wejściowych (G aG bG ciG) gdzie I ϵ 0 1 jest losowo wybrany (a nie znany M a priori) c1 = ab oraz c0 jest losowym skalarem a dane wyjściowe i mają prawdopodobieństwo

Dla niektoacuterych wielomianoacutew Q2 (k)Należy rozważyć algorytm SIMNIZKP (zbliżony to tego ktoacutery został zdefiniowany w [6]) ktoacutery jako skalary wejściowe wykorzystuje wektor x klucza prywatnego zbioacuter wektoroacutew kluczy

publicznych indeks π oraz wiadomość m i ktoacutery działa w sposoacuteb następujący1 Wygenerować skalary losowe s1 hellip sm oraz skalar losowy cπ lt- H2 Dla j indeksującego określić

A dla pozostałych j

3 Obliczyć losowe dane wyjściowe na podstawie losowego oracle

4 Dla każdego i roboczego mod m obliczyć

Należy podkreślić że w ostatnim punkcie kiedy i = π - 1 to ci+1 jest już określone w celu utrzymania spoacutejności z losowymi danymi wyjściowymi oracleNależy podkreślić że niezależnie od tego czy jest rzeczywistym kluczem prywatnym odpowiadającym ze względu na to że spoacutejność jest zachowywana przez losowe wartości oracle w kolejnych wezwaniach powyższy podpis jest weryfikowany Jeżeli x jest rzeczywiście wektorem klucza prywatnego y to nie ma roacuteżnicy pomiędzy SIMNIZKP oraz rzeczywistym podpisemNa koniec mając krotność (G aG bG ciG) gdzie a b są losowo wybrany skalarami a c1 = ab c0 elementem losowym i ϵ 0 1 M zachodzi w poniższych krokach i pozwala rozwiązać problem decyzyjny Diffie Helmana za pomocą niepomijalnego prawdopodobieństwa M wychwytuje losowe ϒ lt-H z losowej wartości oracle oraz pobiera parę wektoroacutew klucza prywatnego publicznego (x y) a następnie oblicza s jako a = s + ϒx Teraz M wykonuje

SIMNIZKP za pomocą dowolnie wybranych wektoroacutew kluczy w taki sposoacuteb że w danej wiadomości m oraz Jeżeli prawdziwe jest że i = 1 to c = ab oraz logGaG = logbGcG = a

z uwagi na to że zakłada się iż A jest w stanie znaleźć π z prawdopodobieństwem ktoacuterego nie można pominąć to istnieje niepomijalne prawdopodobieństwo frac12 że A zwroacuteci 1 (i wtedy M zwroacuteci 1) Jeżeli i = 0 to A zwraca 1 wyłącznie z prawdopodobieństwem frac12 a zatem dla niektoacuterych niepomijanych prawdopodobieństw powyżej 1`2 M zwraca tę samą wartość co A i tym samym rozwiązuje problem decyzyjny Diffie-Helmana dla losowo wybranych skalaroacutew bez pomijalnego prawdopodobieństwa powyżej 12 co stanowi sprzeczność

Załącznik B Kod demo Ring CT W repozytorium w [14] zbudowałem prostą demonstrację protokołu poufnych transakcji pierścieniowych (Ring Confidential Transactions) wykorzystujących podpisy MLSAG w części 2 oraz podpisy ASNL w części 5

H_ct = RingCTgetHForCT()print(H H_ct)sr Pr = PaperWalletskpkGen() receivers private publicse pe ss = ecdhecdhgen(Pr) compute shared secret ssdigits = 14 in practice it will be 14print(inputs)Cia L1a s2a sa ska = RingCTgenRangeProof(10000 digits)print(outputs)Cib L1b s2b sb skb = RingCTgenRangeProof(7000 digits)Cic L1c s2c sc skc = RingCTgenRangeProof(3000 digits)print(verifying range proofs of outputs)RingCTverRangeProof(Cib L1b s2b sb)RingCTverRangeProof(Cic L1c s2c sc)x P1 = PaperWalletskpkGen()P2 = PaperWalletpkGen()C2 = PaperWalletpkGen()some random commitment grabbed from the blockchainind = 0Ca = RingCTsumCi(Cia)Cb = RingCTsumCi(Cib)Cc = RingCTsumCi(Cic)sk = [x MiniNerosc_sub_keys(ska MiniNerosc_add_keys(skb skc))]

pk = [[P1 P2] [MiniNerosubKeys(Ca MiniNeroaddKeys(Cb Cc)) MiniNerosubKeys(C2 MiniNeroaddKeys(Cb Cc)) ] ]II cc ssVal = MLSAGMLSAG_Sign(pk sk ind)print(Sig verified MLSAGMLSAG_Ver(pk II cc ssVal) )print(Finding received amount corresponding to Cib)RingCTComputeReceivedAmount(pe sr MiniNeroaddScalars(ss skb) Cib)print(Finding received amount corresponding to Cic)RingCTComputeReceivedAmount(pe sr MiniNeroaddScalars(ss skc) Cic)

Przykład transakcji z danymi wejściowymi 10 000 oraz wyjściowymi 3 000 i 7 000(rsquoHrsquo rsquo61fe7f0f5a607a33427d01dd1fded5ffa03fae2e9df9ebccf2e0a2f5bd77a204rsquo)inputs(rsquob b in binaryrsquo 10000 [0 0 0 0 1 0 0 0 1 1 1 0 0 1])Generating Aggregate Schnorr Non-linkable Podpis pierścieniowy outputs(rsquob b in binaryrsquo 7000 [0 0 0 1 1 0 1 0 1 1 0 1 1 0])Generating Aggregate Schnorr Non-linkable Podpis pierścieniowy (rsquob b in binaryrsquo 3000 [0 0 0 1 1 1 0 1 1 1 0 1 0 0])Generating Aggregate Schnorr Non-linkable Podpis pierścieniowy verifying range proofs of outputsVerifying Aggregate Schnorr Non-linkable Podpis pierścieniowy VerifiedVerifying Aggregate Schnorr Non-linkable Podpis pierścieniowy Verified(rsquoGenerating MLSAG sig of dimensions rsquo 2 rsquox rsquo 2)(rsquoverifying MLSAG sig of dimensions rsquo 2 rsquox rsquo 2)(rsquocrsquo[rsquo80a3cfd06dd2862307cd75c2a1566f20cd743dbb0b9feb22d79dcbecb9023f42rsquorsquoa9b7342ba7bf2f102505ca19dab734fde638916c0a29f5b30e49833ab51393earsquorsquo80a3cfd06dd2862307cd75c2a1566f20cd743dbb0b9feb22d79dcbecb9023f42rsquo])(rsquosig verifiesrsquo True)(rsquoSig verifiedrsquo True)Finding received amount corresponding to Cib(rsquoreceived rsquo 7000c Monero Research Lab Page 20 of 20rsquoa488ec68732fb551841c2c6dcc7ffac895d98ec7e9378275ed20ea12805fc18ersquo)Finding received amount corresponding to Cic(rsquoreceived rsquo3000rsquo1b46626858e130a0f3884c74c9fdeabc4d812c519103ea16a35a3f82a3d0ed6drsquo)

co pozwala obliczyć zobowiązania do bj ∙ 2j w taki sposoacuteb że

Na koniec wykorzystując sekretny klucz bj można obliczyć podpis pierścieniowy na

dla wszystkich j oraz zapewnia dla weryfikatoroacutew (w tym przypadku goacuternikoacutew)Jeżeli chodzi o oszczędności miejsca można albo wykorzystać boromejski podpis pierścieniowy (podobnie jak w [11]) albo połączyć wszystkie proste podpisy pierścieniowe bądź utworzyć pewien typ zagregowanego podpisu pierścieniowego zdefiniowanego w następujący sposoacuteb

501 Generowanie zagregowanego nielinkowanego podpisu pierścieniowego Schnorra (Aggregate Schnorr Non-linkable Ring Signature) (ASNL)

Niech stanowi zbioacuter kluczy j = 1hellip z jako sekretnym kluczem

Dla każdego j niech Irsquo = i + 1 mod 2 ustawić skalar losowy aj i obliczyć

Ustawić gdzie Hs to kryptograficzna funkcja haszująca zwracająca skalar po dokonaniu wyboru losowego obliczyć

Określić i obliczyć

Zwroacutecić dla wszystkich j i s =

502 Weryfikacja zagregowanego nielinkowalnego podpisu pierścieniowego Schnorra (ASNL)Zacznijmy od dla j = 1hellip n oraz s

Dla wszystkich j obliczyć oraz

Jeżeli to otrzymamy 0 dla ważnego podpisuW przeciwnym razie otrzymamy wartość zwrotną -1

Teoremat 51 Zagregowany nielinkowany podpis pierścieniowy Schnorra nie może być sfałszowany przy założeniu logarytmu dyskretnego

Dowoacuted Przedstawiam szkic dowodu w przypadku n = 2 Przypadek ogoacutelny ma zbliżony charakter Przypuśćmy że adwersarz A jest w stanie sfałszować podpis ASNL na

Przy pomijalnym prawdopodobieństwie znając najwyżej jedną z (przypuśćmy że bez straty ogoacutelnego charakteru założenia że A zna ) Dla każdego danego fałszu

rozwiązuję roacutewnanie logarytmu dyskretnego o niepomijalnym prawdopodobieństwie Po zastosowaniu algorytmu weryfikacji niech Zatem prawdziwe musi być roacutewnanie

Przypuśćmy że oraz a a b są znane A wtedy

ponieważ jest określone protokołem weryfikacji musi być zatem prawdą że A zna klucz

prywatny

=Jest to w sprzeczności z założeniem logarytmu dyskretnego dla danej grupy

51 Reprezentacja kwotKwoty w protokole Ring CT można przedstawiać w sposoacuteb zbliżony do tego ktoacutery przedstawiony został w [11] z drobną modyfikacją w celu dopasowania do systemu Monero Coiny CryptoNote organizują nominały coinoacutew w bazie indeksoacutew w taki sposoacuteb aby mogły być ułożone w porządku występowania jako dane wejściowe dla podpisoacutew pierścieniowych Ponieważ wszystkie wartości coinoacutew w CryptoNote są reprezentowane w postaci 64-bitowych niepodpisanych liczb całkowitych możemy wykorzystać range proof na przestrzeni całego rejestru w celu zakodowania kwoty wyjściowej przekazywanej odbiorcy Na szczęście to także umożliwia wzajemne miksowanie danych wyjściowych zatem wymagany jest tylko jeden indeks danych wyjściowych w porządku rejestracji Przedział weryfikacji (range proof) wynosi ok 5 kilobajtoacutew Podpisy pierścieniowe dla danych wejściowych stają się bardziej odporne na analizę ponieważ anonimowość jest bardzo rozszerzonaPodczas gdy obszary weryfikacji (range proofs) są duże wykorzystywanie układu haszującego ktoacutery dodaje przedrostek do transakcji (zaroacutewno indeksoacutew wejściowych jak i wyjściowych) i przechowuje szeroki zakres range proof wraz z podpisami umożliwia oddzielnie uzyskanie ogromnych oszczędności przestrzeni podczas synchronizacji (syncing) do punktu weryfikacji lub działanie jako węzeł SPV Podobnie do elementoacutew bocznych łańcucha (Sidechains Elements) [12] będziemy przechowywać H(H(prefiks)||H(podpisy)) w drzewie Merkla Następnie węzły syncing do zaufanego punktu weryfikacji muszą jedynie pobrać przedrostek i dodać wartość haszującą do podpisoacutew skutecznie redukując szerokość wiązki Ponieważ prefiks transakcji wykorzystuje wariant dla danych wyjściowych ktoacutere wymienia w swoich podpisach pierścieniowych oraz środkach zapisanych do jednego klucza publicznego stanowi on miniaturowe poroacutewnanie do danych podpisoacutew pierścieniowych w danych wyjściowych oraz range proofs

Następnie podpisy pierścieniowe mogą nawet być przycięte z bazy danych przez niektoacutere węzły w celu uzyskania dalszych zyskoacutew przestrzeni przechowując zastępczo jedynie względnie mały zbioacuter UTXO

511 Przekazywanie informacji o kwotach OdbiorcyObecnie mając dowolną kwotę wyjściową b = b020 + b121 + ∙∙∙ bn2n nadawca oblicza nową prywatnąpubliczną parę kluczy oraz związane wymieniane sekrety ECDH ss oraz udostępnia następujące informacje w swojej transakcji

gdzie ai to losowo wybrane liczby dla j = 0 hellipn Dane Klucz publiczny ECDH oraz a + ss mod l gdzie a = a0 + hellip + an

Następnie odbiorca Oblicza udostępniany sekret ss oraz oblicza a na podstawie a + ss mod l Oblicza C = sumCi oblicza C ndash aG = bH oraz oblicza b poroacutewnując uzyskane wartości do

wszystkich bH w danym przedziale [0 2n] (W praktyce będzie to szybkie 500 kilobajtowe wyszukanie w n = 12 podobnie jak w poprzednim rozdziale Gdyby jednak wartość 232 została wybrana jako goacuterna wartość graniczna podobnie jak w [11] wyszukiwanie stałoby się dużym obliczeniowo wysiłkiem)

6 WnioskiProtokoacuteł pierścieniowych transakcji poufnych (Ring Confidential Transactions) to bardzo silnie zdecentralizowana kryptowaluta (tzn nie ma w niej żadnej uprzywilejowanej strony) ktoacutera posiada proste do udowodnienia wartości szacunkowe zabezpieczeń dotyczące ukrywania kwot transferoacutew ich źroacutedeł oraz odbiorcoacutew Dodatkowo generowanie coinoacutew w oparciu o protokoacuteł Ring Confidential Transactions nie wymaga obecności czynnika zaufanego i proces jego weryfikacji jest całkowicie bezpiecznyTych pięć czynnikoacutew jest niezbędnych w przypadku kryptowalut zbliżonych do środkoacutew gotoacutewkowych takich jak MoneroBibliografia1 Masayuki Abe Miyako Ohkubo and Koutarou Suzuki 1-out-of-n signatures from a variety of keys Advances in CryptologyAsiacrypt 2002 pages 415ndash432 20022 Adam Back Bitcoins with homomorphic value (validatable but encrypted)httpsbitcointalkorgindexphptopic=3057910 2013 [Online accessed 1-May-2015]3 Adam Back Podpis pierścieniowy efficiency httpsbitcointalkorgindexphptopic=972541msg10619684msg10619684 2015 [Online accessed 1-May-2015]4 Eli Ben Sasson Alessandro Chiesa Christina Garman Matthew Green Ian Miers Eran Tromer and Madars Virza Zerocash Decentralized anonymous payments from bitcoin In Security and Privacy (SP) 2014 IEEE Symposium on pages 459ndash474 IEEE 20145 Evan Duffield and Kyle Hagan Darkcoin Peertopeer cryptocurrency with anonymous blockchain transactions and an improved proofofwork system 20146 Eiichiro Fujisaki and Koutarou Suzuki Traceable podpis pierścieniowy In Public Key CryptographyndashPKC 2007 pages 181ndash200 Springer 20077 Javier Herranz Aggregate signatures httpwwwiiiacsices~jherranzpapersNijmegen_seminar_aggregatepdf oct 20058 Joseph K Liu Victor K Wei and Duncan S Wong Linkable spontaneous anonymous group signature for ad hoc groups In Information Security and Privacy pages 325ndash335 Springer 20049 Adam Mackenzie Surae Noether and Monero Core Team Improving obfuscation in the cryptonote protocol httpslabgetmoneroorgpubsMRL-0004pdf January 201510 Greg Maxwell Coinjoin Bitcoin privacy for the real world august 2013 Bitcoin Forum httpsbitcointalkorgindexphptopic=2792490 2013 [Online accessed 1-July-2015]11 Greg Maxwell Confidential Transactions httpspeoplexiphorg~gregconfidential_valuestxt 2015 [Online accessed 1-June-2015]12 Greg Maxwell Elements project httpsgithubcomShenNoetherMiniNero 201513 Satoshi Nakamoto Bitcoin A peer-to-peer electronic cash system Consulted 1(2012)28 200814 Shen Noether Mininero httpsgithubcomShenNoetherMiniNero 201515 Ronald L Rivest Adi Shamir and Yael Tauman How to leak a secret In Advances in CryptologyASIACRYPT 2001 pages 552ndash565 Springer 200116 Nicolas van Saberhagen Cryptonote v 2 0 HYPERLINK https cryptonote org whitepaper pdf 2013

Załącznik A Załącznik Security ProofsA1 Brak możliwości sfałszowania MLSAG

Obliczenia przebiegają analogicznie do [8 Teoremat 1] Niech H1 oraz H2 będą losowo wybranymi oracle a SO stanowią podpisy oracle zwracające ważne podpisy MLSAG Załoacuteżmy że istnieje probabilistyczny wielomianowy adwersarz czasowy (PPT) A ktoacutery posiada zdolność sfałszowania MLSAG z listy wektoroacutew kluczy L przy prawdopodobieństwie ktoacuterego nie można pominąć

Gdzie Q1 stanowi wielomianowy parametr bezpieczeństwa k oraz gdzie (m σ) nie stanowi jednego z podpisoacutew zwracanych przez SO Załoacuteżmy że A nie wysyła więcej niż qH + nqS

(gdzie n oznacza liczbę kluczy w L) zapytań dotyczących podpisoacutew oracle H1H2 oraz SO odpowiednio Podpisy oracle H1 oraz H2 uważa się za niezależne i losowe oraz spoacutejne z danymi zapytaniami powtarzającymi się Podpis oracle SO może składać zapytanie H1 oraz H2 Mając wartość A wykaże że istnieje możliwość utworzenia adwersarza M w PPT ktoacutery będzie wykorzystywać A w celu znalezienia logarytmu dyskretnego jednego z kluczy w L

Jeżeli L stanowi zbioacuter kluczy wektoroacutew z ktoacuterych każdy będzie mieć wielkość r (tzn z kluczami publicznymi y1 hellip yr ) to wygenerowany fałszywy podpis

Wygenerowany przez A musi spełniać warunek

Gdzie i są obliczone w ramach mod n oraz są zdefiniowane zgodnie z Rozdziałem 22 Nowy adwersarz M może wykorzystać A w celu sfałszowania podpisoacutew wielomianową liczbę razy i zapisze każdy skrypt Turinga T niezależnie czy sfałszowanie było skuteczne czy nie

Lemma A1 [8 Lemma 1] Niech M wywołuje A w celu uzyskania transkrypcji T Jeżeli T jest skuteczne to M powraca do T do nagłoacutewka H i następnie re-symuluje A w celu uzyskania transkrypcji Trsquo Jeżeli Pr (T okaże się skuteczne) = ϵ to Pr (Trsquo jest skuteczne) = ϵ

Dowoacuted wynika wprost z przywołanego teorematu

Teoremat A2 Prawdopodobieństwo że adwersarz A sfałszuje podpis MLSAG można pominąć przy założeniu logarytmu dyskretnego

Dowoacuted Do przeprowadzenia dowodu będę stosować notację przedstawioną powyżej Podobnie jak w przypadku [8 teoremat 1] ponieważ prawdopodobieństwo odgadnięcia danych wyjściowych z losowego oracle jest znikome w związku z tym dla każdego skutecznego oszustwa A wprowadza transkrypcję uzupełniającą T a zatem mamy mT zapytań w przypadku zapytań do H1 odpowiadających liczbie n zapytań wykorzystywanych w celu weryfikacji podpisu W związku z tym niech Xi1 hellip Xim oznacza zapytania wykorzystywane w procesie weryfikacji fałszu ith oraz niech π oznacza indeks odpowiadający ostatniemu zapytaniu weryfikacyjnego dla danego oszustwa

(Intuicyjnie π odpowiada temu co może stanowić indeks sekretny fałszywego podpisu ponieważ odpowiada on ostatniemu wezwaniu ostatniemu wywołaniu losowego oracle dla danego odpisu)Proacuteba sfałszowania σ podjęta przez A stanowi fałsz (l π) jeżeli i1 = l oraz π jest zgodne z powyższym (zatem fałsz odpowiada zapytaniom l do l + π) Z założenia istnieje para (l π) taka że prawdopodobieństwo związanej transkrypcji T daje skutecznie wygenerowany fałszywy klucz ϵlπ (T) spełnia warunek

1

Teraz przeglądając T do wartości przed zapytaniem l-tym a następnie podejmując proacutebę sfałszowania za pomocą tego samego zbioru kluczy (oraz dopuszczając aby H1 obliczyło nowe rzuty monetami dla wszystkich kolejnych zapytań) z Lemmy A1 wynika że prawdopodobieństwo że Trsquo jest także skuteczne spełnia warunki

_Dlatego prawdopodobieństwo że zaroacutewno T jak i Trsquo odpowiadają weryfikacjom fałszywym σ i σ1 nie może zostać pominięte

Ponieważ nowe rzuty monetami zostały obliczone na podstawie danych wyjściowych losowych oracle H1 oznacza to że przy dużym prawdopodobieństwie istnieje wartość j taka

że oraz W związku z tym możemy rozwiązać klucz prywatny z indeksem π

ktoacutery jest sprzeczny z założeniami logarytmu dyskretnego

A2 Linkowalność MLSAG Teoremat A3 Linkowalność obrazu klucza (Key-Image Linkability) Prawdopodobieństwo że adwersarz a w PPT może utworzyć dwa podpisy weryfikujące (niepołączone w danym

ustawieniu σ σrsquo podpisane w odniesieniu do wektoroacutew kluczy oraz odpowiednio w taki

sposoacuteb że będzie istnieć klucz publiczny i w obu oraz może być pominięte

Dowoacuted Przypuśćmy że w przeciwieństwie do tego co zostało wcześniej powiedziane A utworzył dwa podpisy weryfikujące σ oraz σrsquo o oba są podpisami w odniesieniu do kluczowych wektoroacutew

oraz odpowiednio w taki sposoacuteb że istnieje klucz publiczny y zaroacutewno w jak i

Niech y występuje jako element j należący do a jrsquo jako element należący do rsquo Z teorematu A2 wynika z dużym prawdopodobieństwem że istnieją indeksy π oraz πrsquo dla kluczy publicznych σ oraz σrsquo odpowiednio takie że

oraz

z

oraz

Jeżeli uznamy że x oznacza klucz prywatny y y = xG to po rozwiązaniu powyższego dla Ij

oraz Ij0rsquo mamy następujące roacutewnania oraz podobnie Ijrsquo = xH (y) Tym samym dwa podpisy obejmują Ij = Ijrsquo i w związku z tym ponieważ zduplikowane obrazy kluczy są odrzucone jeden z nich nie może być wykorzystany do weryfikacji

A3 Anonimowość MLSAG W celu udowodnienia anonimowości powyższego protokołu w losowym modelu oracle przyjmijmy że H1 H2 to losowe oracle modelujące dyskretne funkcje haszujące Niech A to adwersarz anonimowości Buduję adwersarza M względem założenia problemu decyzyjnego Diffie Helmana (DDH) zgodnie z poniższym Założenie DDH stwierdza że mając daną krotność (G aG bG ϒG) prawdopodobieństwo ustalenia czy G = abG jest znikome

Teoremat A4 Protokoacuteł pierścieniowy CT jest dwuznaczny w odniesieniu do sygnatariusza przy założeniu problemu decyzyjnego Diffie-HelmanaDowoacuted (zbliżony do dowodu [8 Teoremat 2]) Załoacuteżmy że problem decyzyjny Diffie-Helmana jest trudny w cyklicznej grupie generowanej przez G i załoacuteżmy że istnieje adwersarz A w czasie PPT względem dwuznaczności sygnatariusza Tym samym mając listę L n wektoroacutew

kluczy publicznych o długości m oraz zbioacuter prywatnych kluczy t ważny podpis σ na L podpisany przez użytkownika w odniesieniu do wektora klucza y taki że

odpowiedni wektor klucza prywatnego wynosi spełnia to A może zdeterminować π z prawdopodobieństwem

Dla wybranych wielomianoacutew Q(k) Buduję adwersarza PPT M ktoacutery wykorzystuje krotność danych wejściowych (G aG bG ciG) gdzie I ϵ 0 1 jest losowo wybrany (a nie znany M a priori) c1 = ab oraz c0 jest losowym skalarem a dane wyjściowe i mają prawdopodobieństwo

Dla niektoacuterych wielomianoacutew Q2 (k)Należy rozważyć algorytm SIMNIZKP (zbliżony to tego ktoacutery został zdefiniowany w [6]) ktoacutery jako skalary wejściowe wykorzystuje wektor x klucza prywatnego zbioacuter wektoroacutew kluczy

publicznych indeks π oraz wiadomość m i ktoacutery działa w sposoacuteb następujący1 Wygenerować skalary losowe s1 hellip sm oraz skalar losowy cπ lt- H2 Dla j indeksującego określić

A dla pozostałych j

3 Obliczyć losowe dane wyjściowe na podstawie losowego oracle

4 Dla każdego i roboczego mod m obliczyć

Należy podkreślić że w ostatnim punkcie kiedy i = π - 1 to ci+1 jest już określone w celu utrzymania spoacutejności z losowymi danymi wyjściowymi oracleNależy podkreślić że niezależnie od tego czy jest rzeczywistym kluczem prywatnym odpowiadającym ze względu na to że spoacutejność jest zachowywana przez losowe wartości oracle w kolejnych wezwaniach powyższy podpis jest weryfikowany Jeżeli x jest rzeczywiście wektorem klucza prywatnego y to nie ma roacuteżnicy pomiędzy SIMNIZKP oraz rzeczywistym podpisemNa koniec mając krotność (G aG bG ciG) gdzie a b są losowo wybrany skalarami a c1 = ab c0 elementem losowym i ϵ 0 1 M zachodzi w poniższych krokach i pozwala rozwiązać problem decyzyjny Diffie Helmana za pomocą niepomijalnego prawdopodobieństwa M wychwytuje losowe ϒ lt-H z losowej wartości oracle oraz pobiera parę wektoroacutew klucza prywatnego publicznego (x y) a następnie oblicza s jako a = s + ϒx Teraz M wykonuje

SIMNIZKP za pomocą dowolnie wybranych wektoroacutew kluczy w taki sposoacuteb że w danej wiadomości m oraz Jeżeli prawdziwe jest że i = 1 to c = ab oraz logGaG = logbGcG = a

z uwagi na to że zakłada się iż A jest w stanie znaleźć π z prawdopodobieństwem ktoacuterego nie można pominąć to istnieje niepomijalne prawdopodobieństwo frac12 że A zwroacuteci 1 (i wtedy M zwroacuteci 1) Jeżeli i = 0 to A zwraca 1 wyłącznie z prawdopodobieństwem frac12 a zatem dla niektoacuterych niepomijanych prawdopodobieństw powyżej 1`2 M zwraca tę samą wartość co A i tym samym rozwiązuje problem decyzyjny Diffie-Helmana dla losowo wybranych skalaroacutew bez pomijalnego prawdopodobieństwa powyżej 12 co stanowi sprzeczność

Załącznik B Kod demo Ring CT W repozytorium w [14] zbudowałem prostą demonstrację protokołu poufnych transakcji pierścieniowych (Ring Confidential Transactions) wykorzystujących podpisy MLSAG w części 2 oraz podpisy ASNL w części 5

H_ct = RingCTgetHForCT()print(H H_ct)sr Pr = PaperWalletskpkGen() receivers private publicse pe ss = ecdhecdhgen(Pr) compute shared secret ssdigits = 14 in practice it will be 14print(inputs)Cia L1a s2a sa ska = RingCTgenRangeProof(10000 digits)print(outputs)Cib L1b s2b sb skb = RingCTgenRangeProof(7000 digits)Cic L1c s2c sc skc = RingCTgenRangeProof(3000 digits)print(verifying range proofs of outputs)RingCTverRangeProof(Cib L1b s2b sb)RingCTverRangeProof(Cic L1c s2c sc)x P1 = PaperWalletskpkGen()P2 = PaperWalletpkGen()C2 = PaperWalletpkGen()some random commitment grabbed from the blockchainind = 0Ca = RingCTsumCi(Cia)Cb = RingCTsumCi(Cib)Cc = RingCTsumCi(Cic)sk = [x MiniNerosc_sub_keys(ska MiniNerosc_add_keys(skb skc))]

pk = [[P1 P2] [MiniNerosubKeys(Ca MiniNeroaddKeys(Cb Cc)) MiniNerosubKeys(C2 MiniNeroaddKeys(Cb Cc)) ] ]II cc ssVal = MLSAGMLSAG_Sign(pk sk ind)print(Sig verified MLSAGMLSAG_Ver(pk II cc ssVal) )print(Finding received amount corresponding to Cib)RingCTComputeReceivedAmount(pe sr MiniNeroaddScalars(ss skb) Cib)print(Finding received amount corresponding to Cic)RingCTComputeReceivedAmount(pe sr MiniNeroaddScalars(ss skc) Cic)

Przykład transakcji z danymi wejściowymi 10 000 oraz wyjściowymi 3 000 i 7 000(rsquoHrsquo rsquo61fe7f0f5a607a33427d01dd1fded5ffa03fae2e9df9ebccf2e0a2f5bd77a204rsquo)inputs(rsquob b in binaryrsquo 10000 [0 0 0 0 1 0 0 0 1 1 1 0 0 1])Generating Aggregate Schnorr Non-linkable Podpis pierścieniowy outputs(rsquob b in binaryrsquo 7000 [0 0 0 1 1 0 1 0 1 1 0 1 1 0])Generating Aggregate Schnorr Non-linkable Podpis pierścieniowy (rsquob b in binaryrsquo 3000 [0 0 0 1 1 1 0 1 1 1 0 1 0 0])Generating Aggregate Schnorr Non-linkable Podpis pierścieniowy verifying range proofs of outputsVerifying Aggregate Schnorr Non-linkable Podpis pierścieniowy VerifiedVerifying Aggregate Schnorr Non-linkable Podpis pierścieniowy Verified(rsquoGenerating MLSAG sig of dimensions rsquo 2 rsquox rsquo 2)(rsquoverifying MLSAG sig of dimensions rsquo 2 rsquox rsquo 2)(rsquocrsquo[rsquo80a3cfd06dd2862307cd75c2a1566f20cd743dbb0b9feb22d79dcbecb9023f42rsquorsquoa9b7342ba7bf2f102505ca19dab734fde638916c0a29f5b30e49833ab51393earsquorsquo80a3cfd06dd2862307cd75c2a1566f20cd743dbb0b9feb22d79dcbecb9023f42rsquo])(rsquosig verifiesrsquo True)(rsquoSig verifiedrsquo True)Finding received amount corresponding to Cib(rsquoreceived rsquo 7000c Monero Research Lab Page 20 of 20rsquoa488ec68732fb551841c2c6dcc7ffac895d98ec7e9378275ed20ea12805fc18ersquo)Finding received amount corresponding to Cic(rsquoreceived rsquo3000rsquo1b46626858e130a0f3884c74c9fdeabc4d812c519103ea16a35a3f82a3d0ed6drsquo)

Dowoacuted Przedstawiam szkic dowodu w przypadku n = 2 Przypadek ogoacutelny ma zbliżony charakter Przypuśćmy że adwersarz A jest w stanie sfałszować podpis ASNL na

Przy pomijalnym prawdopodobieństwie znając najwyżej jedną z (przypuśćmy że bez straty ogoacutelnego charakteru założenia że A zna ) Dla każdego danego fałszu

rozwiązuję roacutewnanie logarytmu dyskretnego o niepomijalnym prawdopodobieństwie Po zastosowaniu algorytmu weryfikacji niech Zatem prawdziwe musi być roacutewnanie

Przypuśćmy że oraz a a b są znane A wtedy

ponieważ jest określone protokołem weryfikacji musi być zatem prawdą że A zna klucz

prywatny

=Jest to w sprzeczności z założeniem logarytmu dyskretnego dla danej grupy

51 Reprezentacja kwotKwoty w protokole Ring CT można przedstawiać w sposoacuteb zbliżony do tego ktoacutery przedstawiony został w [11] z drobną modyfikacją w celu dopasowania do systemu Monero Coiny CryptoNote organizują nominały coinoacutew w bazie indeksoacutew w taki sposoacuteb aby mogły być ułożone w porządku występowania jako dane wejściowe dla podpisoacutew pierścieniowych Ponieważ wszystkie wartości coinoacutew w CryptoNote są reprezentowane w postaci 64-bitowych niepodpisanych liczb całkowitych możemy wykorzystać range proof na przestrzeni całego rejestru w celu zakodowania kwoty wyjściowej przekazywanej odbiorcy Na szczęście to także umożliwia wzajemne miksowanie danych wyjściowych zatem wymagany jest tylko jeden indeks danych wyjściowych w porządku rejestracji Przedział weryfikacji (range proof) wynosi ok 5 kilobajtoacutew Podpisy pierścieniowe dla danych wejściowych stają się bardziej odporne na analizę ponieważ anonimowość jest bardzo rozszerzonaPodczas gdy obszary weryfikacji (range proofs) są duże wykorzystywanie układu haszującego ktoacutery dodaje przedrostek do transakcji (zaroacutewno indeksoacutew wejściowych jak i wyjściowych) i przechowuje szeroki zakres range proof wraz z podpisami umożliwia oddzielnie uzyskanie ogromnych oszczędności przestrzeni podczas synchronizacji (syncing) do punktu weryfikacji lub działanie jako węzeł SPV Podobnie do elementoacutew bocznych łańcucha (Sidechains Elements) [12] będziemy przechowywać H(H(prefiks)||H(podpisy)) w drzewie Merkla Następnie węzły syncing do zaufanego punktu weryfikacji muszą jedynie pobrać przedrostek i dodać wartość haszującą do podpisoacutew skutecznie redukując szerokość wiązki Ponieważ prefiks transakcji wykorzystuje wariant dla danych wyjściowych ktoacutere wymienia w swoich podpisach pierścieniowych oraz środkach zapisanych do jednego klucza publicznego stanowi on miniaturowe poroacutewnanie do danych podpisoacutew pierścieniowych w danych wyjściowych oraz range proofs

Następnie podpisy pierścieniowe mogą nawet być przycięte z bazy danych przez niektoacutere węzły w celu uzyskania dalszych zyskoacutew przestrzeni przechowując zastępczo jedynie względnie mały zbioacuter UTXO

511 Przekazywanie informacji o kwotach OdbiorcyObecnie mając dowolną kwotę wyjściową b = b020 + b121 + ∙∙∙ bn2n nadawca oblicza nową prywatnąpubliczną parę kluczy oraz związane wymieniane sekrety ECDH ss oraz udostępnia następujące informacje w swojej transakcji

gdzie ai to losowo wybrane liczby dla j = 0 hellipn Dane Klucz publiczny ECDH oraz a + ss mod l gdzie a = a0 + hellip + an

Następnie odbiorca Oblicza udostępniany sekret ss oraz oblicza a na podstawie a + ss mod l Oblicza C = sumCi oblicza C ndash aG = bH oraz oblicza b poroacutewnując uzyskane wartości do

wszystkich bH w danym przedziale [0 2n] (W praktyce będzie to szybkie 500 kilobajtowe wyszukanie w n = 12 podobnie jak w poprzednim rozdziale Gdyby jednak wartość 232 została wybrana jako goacuterna wartość graniczna podobnie jak w [11] wyszukiwanie stałoby się dużym obliczeniowo wysiłkiem)

6 WnioskiProtokoacuteł pierścieniowych transakcji poufnych (Ring Confidential Transactions) to bardzo silnie zdecentralizowana kryptowaluta (tzn nie ma w niej żadnej uprzywilejowanej strony) ktoacutera posiada proste do udowodnienia wartości szacunkowe zabezpieczeń dotyczące ukrywania kwot transferoacutew ich źroacutedeł oraz odbiorcoacutew Dodatkowo generowanie coinoacutew w oparciu o protokoacuteł Ring Confidential Transactions nie wymaga obecności czynnika zaufanego i proces jego weryfikacji jest całkowicie bezpiecznyTych pięć czynnikoacutew jest niezbędnych w przypadku kryptowalut zbliżonych do środkoacutew gotoacutewkowych takich jak MoneroBibliografia1 Masayuki Abe Miyako Ohkubo and Koutarou Suzuki 1-out-of-n signatures from a variety of keys Advances in CryptologyAsiacrypt 2002 pages 415ndash432 20022 Adam Back Bitcoins with homomorphic value (validatable but encrypted)httpsbitcointalkorgindexphptopic=3057910 2013 [Online accessed 1-May-2015]3 Adam Back Podpis pierścieniowy efficiency httpsbitcointalkorgindexphptopic=972541msg10619684msg10619684 2015 [Online accessed 1-May-2015]4 Eli Ben Sasson Alessandro Chiesa Christina Garman Matthew Green Ian Miers Eran Tromer and Madars Virza Zerocash Decentralized anonymous payments from bitcoin In Security and Privacy (SP) 2014 IEEE Symposium on pages 459ndash474 IEEE 20145 Evan Duffield and Kyle Hagan Darkcoin Peertopeer cryptocurrency with anonymous blockchain transactions and an improved proofofwork system 20146 Eiichiro Fujisaki and Koutarou Suzuki Traceable podpis pierścieniowy In Public Key CryptographyndashPKC 2007 pages 181ndash200 Springer 20077 Javier Herranz Aggregate signatures httpwwwiiiacsices~jherranzpapersNijmegen_seminar_aggregatepdf oct 20058 Joseph K Liu Victor K Wei and Duncan S Wong Linkable spontaneous anonymous group signature for ad hoc groups In Information Security and Privacy pages 325ndash335 Springer 20049 Adam Mackenzie Surae Noether and Monero Core Team Improving obfuscation in the cryptonote protocol httpslabgetmoneroorgpubsMRL-0004pdf January 201510 Greg Maxwell Coinjoin Bitcoin privacy for the real world august 2013 Bitcoin Forum httpsbitcointalkorgindexphptopic=2792490 2013 [Online accessed 1-July-2015]11 Greg Maxwell Confidential Transactions httpspeoplexiphorg~gregconfidential_valuestxt 2015 [Online accessed 1-June-2015]12 Greg Maxwell Elements project httpsgithubcomShenNoetherMiniNero 201513 Satoshi Nakamoto Bitcoin A peer-to-peer electronic cash system Consulted 1(2012)28 200814 Shen Noether Mininero httpsgithubcomShenNoetherMiniNero 201515 Ronald L Rivest Adi Shamir and Yael Tauman How to leak a secret In Advances in CryptologyASIACRYPT 2001 pages 552ndash565 Springer 200116 Nicolas van Saberhagen Cryptonote v 2 0 HYPERLINK https cryptonote org whitepaper pdf 2013

Załącznik A Załącznik Security ProofsA1 Brak możliwości sfałszowania MLSAG

Obliczenia przebiegają analogicznie do [8 Teoremat 1] Niech H1 oraz H2 będą losowo wybranymi oracle a SO stanowią podpisy oracle zwracające ważne podpisy MLSAG Załoacuteżmy że istnieje probabilistyczny wielomianowy adwersarz czasowy (PPT) A ktoacutery posiada zdolność sfałszowania MLSAG z listy wektoroacutew kluczy L przy prawdopodobieństwie ktoacuterego nie można pominąć

Gdzie Q1 stanowi wielomianowy parametr bezpieczeństwa k oraz gdzie (m σ) nie stanowi jednego z podpisoacutew zwracanych przez SO Załoacuteżmy że A nie wysyła więcej niż qH + nqS

(gdzie n oznacza liczbę kluczy w L) zapytań dotyczących podpisoacutew oracle H1H2 oraz SO odpowiednio Podpisy oracle H1 oraz H2 uważa się za niezależne i losowe oraz spoacutejne z danymi zapytaniami powtarzającymi się Podpis oracle SO może składać zapytanie H1 oraz H2 Mając wartość A wykaże że istnieje możliwość utworzenia adwersarza M w PPT ktoacutery będzie wykorzystywać A w celu znalezienia logarytmu dyskretnego jednego z kluczy w L

Jeżeli L stanowi zbioacuter kluczy wektoroacutew z ktoacuterych każdy będzie mieć wielkość r (tzn z kluczami publicznymi y1 hellip yr ) to wygenerowany fałszywy podpis

Wygenerowany przez A musi spełniać warunek

Gdzie i są obliczone w ramach mod n oraz są zdefiniowane zgodnie z Rozdziałem 22 Nowy adwersarz M może wykorzystać A w celu sfałszowania podpisoacutew wielomianową liczbę razy i zapisze każdy skrypt Turinga T niezależnie czy sfałszowanie było skuteczne czy nie

Lemma A1 [8 Lemma 1] Niech M wywołuje A w celu uzyskania transkrypcji T Jeżeli T jest skuteczne to M powraca do T do nagłoacutewka H i następnie re-symuluje A w celu uzyskania transkrypcji Trsquo Jeżeli Pr (T okaże się skuteczne) = ϵ to Pr (Trsquo jest skuteczne) = ϵ

Dowoacuted wynika wprost z przywołanego teorematu

Teoremat A2 Prawdopodobieństwo że adwersarz A sfałszuje podpis MLSAG można pominąć przy założeniu logarytmu dyskretnego

Dowoacuted Do przeprowadzenia dowodu będę stosować notację przedstawioną powyżej Podobnie jak w przypadku [8 teoremat 1] ponieważ prawdopodobieństwo odgadnięcia danych wyjściowych z losowego oracle jest znikome w związku z tym dla każdego skutecznego oszustwa A wprowadza transkrypcję uzupełniającą T a zatem mamy mT zapytań w przypadku zapytań do H1 odpowiadających liczbie n zapytań wykorzystywanych w celu weryfikacji podpisu W związku z tym niech Xi1 hellip Xim oznacza zapytania wykorzystywane w procesie weryfikacji fałszu ith oraz niech π oznacza indeks odpowiadający ostatniemu zapytaniu weryfikacyjnego dla danego oszustwa

(Intuicyjnie π odpowiada temu co może stanowić indeks sekretny fałszywego podpisu ponieważ odpowiada on ostatniemu wezwaniu ostatniemu wywołaniu losowego oracle dla danego odpisu)Proacuteba sfałszowania σ podjęta przez A stanowi fałsz (l π) jeżeli i1 = l oraz π jest zgodne z powyższym (zatem fałsz odpowiada zapytaniom l do l + π) Z założenia istnieje para (l π) taka że prawdopodobieństwo związanej transkrypcji T daje skutecznie wygenerowany fałszywy klucz ϵlπ (T) spełnia warunek

1

Teraz przeglądając T do wartości przed zapytaniem l-tym a następnie podejmując proacutebę sfałszowania za pomocą tego samego zbioru kluczy (oraz dopuszczając aby H1 obliczyło nowe rzuty monetami dla wszystkich kolejnych zapytań) z Lemmy A1 wynika że prawdopodobieństwo że Trsquo jest także skuteczne spełnia warunki

_Dlatego prawdopodobieństwo że zaroacutewno T jak i Trsquo odpowiadają weryfikacjom fałszywym σ i σ1 nie może zostać pominięte

Ponieważ nowe rzuty monetami zostały obliczone na podstawie danych wyjściowych losowych oracle H1 oznacza to że przy dużym prawdopodobieństwie istnieje wartość j taka

że oraz W związku z tym możemy rozwiązać klucz prywatny z indeksem π

ktoacutery jest sprzeczny z założeniami logarytmu dyskretnego

A2 Linkowalność MLSAG Teoremat A3 Linkowalność obrazu klucza (Key-Image Linkability) Prawdopodobieństwo że adwersarz a w PPT może utworzyć dwa podpisy weryfikujące (niepołączone w danym

ustawieniu σ σrsquo podpisane w odniesieniu do wektoroacutew kluczy oraz odpowiednio w taki

sposoacuteb że będzie istnieć klucz publiczny i w obu oraz może być pominięte

Dowoacuted Przypuśćmy że w przeciwieństwie do tego co zostało wcześniej powiedziane A utworzył dwa podpisy weryfikujące σ oraz σrsquo o oba są podpisami w odniesieniu do kluczowych wektoroacutew

oraz odpowiednio w taki sposoacuteb że istnieje klucz publiczny y zaroacutewno w jak i

Niech y występuje jako element j należący do a jrsquo jako element należący do rsquo Z teorematu A2 wynika z dużym prawdopodobieństwem że istnieją indeksy π oraz πrsquo dla kluczy publicznych σ oraz σrsquo odpowiednio takie że

oraz

z

oraz

Jeżeli uznamy że x oznacza klucz prywatny y y = xG to po rozwiązaniu powyższego dla Ij

oraz Ij0rsquo mamy następujące roacutewnania oraz podobnie Ijrsquo = xH (y) Tym samym dwa podpisy obejmują Ij = Ijrsquo i w związku z tym ponieważ zduplikowane obrazy kluczy są odrzucone jeden z nich nie może być wykorzystany do weryfikacji

A3 Anonimowość MLSAG W celu udowodnienia anonimowości powyższego protokołu w losowym modelu oracle przyjmijmy że H1 H2 to losowe oracle modelujące dyskretne funkcje haszujące Niech A to adwersarz anonimowości Buduję adwersarza M względem założenia problemu decyzyjnego Diffie Helmana (DDH) zgodnie z poniższym Założenie DDH stwierdza że mając daną krotność (G aG bG ϒG) prawdopodobieństwo ustalenia czy G = abG jest znikome

Teoremat A4 Protokoacuteł pierścieniowy CT jest dwuznaczny w odniesieniu do sygnatariusza przy założeniu problemu decyzyjnego Diffie-HelmanaDowoacuted (zbliżony do dowodu [8 Teoremat 2]) Załoacuteżmy że problem decyzyjny Diffie-Helmana jest trudny w cyklicznej grupie generowanej przez G i załoacuteżmy że istnieje adwersarz A w czasie PPT względem dwuznaczności sygnatariusza Tym samym mając listę L n wektoroacutew

kluczy publicznych o długości m oraz zbioacuter prywatnych kluczy t ważny podpis σ na L podpisany przez użytkownika w odniesieniu do wektora klucza y taki że

odpowiedni wektor klucza prywatnego wynosi spełnia to A może zdeterminować π z prawdopodobieństwem

Dla wybranych wielomianoacutew Q(k) Buduję adwersarza PPT M ktoacutery wykorzystuje krotność danych wejściowych (G aG bG ciG) gdzie I ϵ 0 1 jest losowo wybrany (a nie znany M a priori) c1 = ab oraz c0 jest losowym skalarem a dane wyjściowe i mają prawdopodobieństwo

Dla niektoacuterych wielomianoacutew Q2 (k)Należy rozważyć algorytm SIMNIZKP (zbliżony to tego ktoacutery został zdefiniowany w [6]) ktoacutery jako skalary wejściowe wykorzystuje wektor x klucza prywatnego zbioacuter wektoroacutew kluczy

publicznych indeks π oraz wiadomość m i ktoacutery działa w sposoacuteb następujący1 Wygenerować skalary losowe s1 hellip sm oraz skalar losowy cπ lt- H2 Dla j indeksującego określić

A dla pozostałych j

3 Obliczyć losowe dane wyjściowe na podstawie losowego oracle

4 Dla każdego i roboczego mod m obliczyć

Należy podkreślić że w ostatnim punkcie kiedy i = π - 1 to ci+1 jest już określone w celu utrzymania spoacutejności z losowymi danymi wyjściowymi oracleNależy podkreślić że niezależnie od tego czy jest rzeczywistym kluczem prywatnym odpowiadającym ze względu na to że spoacutejność jest zachowywana przez losowe wartości oracle w kolejnych wezwaniach powyższy podpis jest weryfikowany Jeżeli x jest rzeczywiście wektorem klucza prywatnego y to nie ma roacuteżnicy pomiędzy SIMNIZKP oraz rzeczywistym podpisemNa koniec mając krotność (G aG bG ciG) gdzie a b są losowo wybrany skalarami a c1 = ab c0 elementem losowym i ϵ 0 1 M zachodzi w poniższych krokach i pozwala rozwiązać problem decyzyjny Diffie Helmana za pomocą niepomijalnego prawdopodobieństwa M wychwytuje losowe ϒ lt-H z losowej wartości oracle oraz pobiera parę wektoroacutew klucza prywatnego publicznego (x y) a następnie oblicza s jako a = s + ϒx Teraz M wykonuje

SIMNIZKP za pomocą dowolnie wybranych wektoroacutew kluczy w taki sposoacuteb że w danej wiadomości m oraz Jeżeli prawdziwe jest że i = 1 to c = ab oraz logGaG = logbGcG = a

z uwagi na to że zakłada się iż A jest w stanie znaleźć π z prawdopodobieństwem ktoacuterego nie można pominąć to istnieje niepomijalne prawdopodobieństwo frac12 że A zwroacuteci 1 (i wtedy M zwroacuteci 1) Jeżeli i = 0 to A zwraca 1 wyłącznie z prawdopodobieństwem frac12 a zatem dla niektoacuterych niepomijanych prawdopodobieństw powyżej 1`2 M zwraca tę samą wartość co A i tym samym rozwiązuje problem decyzyjny Diffie-Helmana dla losowo wybranych skalaroacutew bez pomijalnego prawdopodobieństwa powyżej 12 co stanowi sprzeczność

Załącznik B Kod demo Ring CT W repozytorium w [14] zbudowałem prostą demonstrację protokołu poufnych transakcji pierścieniowych (Ring Confidential Transactions) wykorzystujących podpisy MLSAG w części 2 oraz podpisy ASNL w części 5

H_ct = RingCTgetHForCT()print(H H_ct)sr Pr = PaperWalletskpkGen() receivers private publicse pe ss = ecdhecdhgen(Pr) compute shared secret ssdigits = 14 in practice it will be 14print(inputs)Cia L1a s2a sa ska = RingCTgenRangeProof(10000 digits)print(outputs)Cib L1b s2b sb skb = RingCTgenRangeProof(7000 digits)Cic L1c s2c sc skc = RingCTgenRangeProof(3000 digits)print(verifying range proofs of outputs)RingCTverRangeProof(Cib L1b s2b sb)RingCTverRangeProof(Cic L1c s2c sc)x P1 = PaperWalletskpkGen()P2 = PaperWalletpkGen()C2 = PaperWalletpkGen()some random commitment grabbed from the blockchainind = 0Ca = RingCTsumCi(Cia)Cb = RingCTsumCi(Cib)Cc = RingCTsumCi(Cic)sk = [x MiniNerosc_sub_keys(ska MiniNerosc_add_keys(skb skc))]

pk = [[P1 P2] [MiniNerosubKeys(Ca MiniNeroaddKeys(Cb Cc)) MiniNerosubKeys(C2 MiniNeroaddKeys(Cb Cc)) ] ]II cc ssVal = MLSAGMLSAG_Sign(pk sk ind)print(Sig verified MLSAGMLSAG_Ver(pk II cc ssVal) )print(Finding received amount corresponding to Cib)RingCTComputeReceivedAmount(pe sr MiniNeroaddScalars(ss skb) Cib)print(Finding received amount corresponding to Cic)RingCTComputeReceivedAmount(pe sr MiniNeroaddScalars(ss skc) Cic)

Przykład transakcji z danymi wejściowymi 10 000 oraz wyjściowymi 3 000 i 7 000(rsquoHrsquo rsquo61fe7f0f5a607a33427d01dd1fded5ffa03fae2e9df9ebccf2e0a2f5bd77a204rsquo)inputs(rsquob b in binaryrsquo 10000 [0 0 0 0 1 0 0 0 1 1 1 0 0 1])Generating Aggregate Schnorr Non-linkable Podpis pierścieniowy outputs(rsquob b in binaryrsquo 7000 [0 0 0 1 1 0 1 0 1 1 0 1 1 0])Generating Aggregate Schnorr Non-linkable Podpis pierścieniowy (rsquob b in binaryrsquo 3000 [0 0 0 1 1 1 0 1 1 1 0 1 0 0])Generating Aggregate Schnorr Non-linkable Podpis pierścieniowy verifying range proofs of outputsVerifying Aggregate Schnorr Non-linkable Podpis pierścieniowy VerifiedVerifying Aggregate Schnorr Non-linkable Podpis pierścieniowy Verified(rsquoGenerating MLSAG sig of dimensions rsquo 2 rsquox rsquo 2)(rsquoverifying MLSAG sig of dimensions rsquo 2 rsquox rsquo 2)(rsquocrsquo[rsquo80a3cfd06dd2862307cd75c2a1566f20cd743dbb0b9feb22d79dcbecb9023f42rsquorsquoa9b7342ba7bf2f102505ca19dab734fde638916c0a29f5b30e49833ab51393earsquorsquo80a3cfd06dd2862307cd75c2a1566f20cd743dbb0b9feb22d79dcbecb9023f42rsquo])(rsquosig verifiesrsquo True)(rsquoSig verifiedrsquo True)Finding received amount corresponding to Cib(rsquoreceived rsquo 7000c Monero Research Lab Page 20 of 20rsquoa488ec68732fb551841c2c6dcc7ffac895d98ec7e9378275ed20ea12805fc18ersquo)Finding received amount corresponding to Cic(rsquoreceived rsquo3000rsquo1b46626858e130a0f3884c74c9fdeabc4d812c519103ea16a35a3f82a3d0ed6drsquo)

Następnie podpisy pierścieniowe mogą nawet być przycięte z bazy danych przez niektoacutere węzły w celu uzyskania dalszych zyskoacutew przestrzeni przechowując zastępczo jedynie względnie mały zbioacuter UTXO

511 Przekazywanie informacji o kwotach OdbiorcyObecnie mając dowolną kwotę wyjściową b = b020 + b121 + ∙∙∙ bn2n nadawca oblicza nową prywatnąpubliczną parę kluczy oraz związane wymieniane sekrety ECDH ss oraz udostępnia następujące informacje w swojej transakcji

gdzie ai to losowo wybrane liczby dla j = 0 hellipn Dane Klucz publiczny ECDH oraz a + ss mod l gdzie a = a0 + hellip + an

Następnie odbiorca Oblicza udostępniany sekret ss oraz oblicza a na podstawie a + ss mod l Oblicza C = sumCi oblicza C ndash aG = bH oraz oblicza b poroacutewnując uzyskane wartości do

wszystkich bH w danym przedziale [0 2n] (W praktyce będzie to szybkie 500 kilobajtowe wyszukanie w n = 12 podobnie jak w poprzednim rozdziale Gdyby jednak wartość 232 została wybrana jako goacuterna wartość graniczna podobnie jak w [11] wyszukiwanie stałoby się dużym obliczeniowo wysiłkiem)

6 WnioskiProtokoacuteł pierścieniowych transakcji poufnych (Ring Confidential Transactions) to bardzo silnie zdecentralizowana kryptowaluta (tzn nie ma w niej żadnej uprzywilejowanej strony) ktoacutera posiada proste do udowodnienia wartości szacunkowe zabezpieczeń dotyczące ukrywania kwot transferoacutew ich źroacutedeł oraz odbiorcoacutew Dodatkowo generowanie coinoacutew w oparciu o protokoacuteł Ring Confidential Transactions nie wymaga obecności czynnika zaufanego i proces jego weryfikacji jest całkowicie bezpiecznyTych pięć czynnikoacutew jest niezbędnych w przypadku kryptowalut zbliżonych do środkoacutew gotoacutewkowych takich jak MoneroBibliografia1 Masayuki Abe Miyako Ohkubo and Koutarou Suzuki 1-out-of-n signatures from a variety of keys Advances in CryptologyAsiacrypt 2002 pages 415ndash432 20022 Adam Back Bitcoins with homomorphic value (validatable but encrypted)httpsbitcointalkorgindexphptopic=3057910 2013 [Online accessed 1-May-2015]3 Adam Back Podpis pierścieniowy efficiency httpsbitcointalkorgindexphptopic=972541msg10619684msg10619684 2015 [Online accessed 1-May-2015]4 Eli Ben Sasson Alessandro Chiesa Christina Garman Matthew Green Ian Miers Eran Tromer and Madars Virza Zerocash Decentralized anonymous payments from bitcoin In Security and Privacy (SP) 2014 IEEE Symposium on pages 459ndash474 IEEE 20145 Evan Duffield and Kyle Hagan Darkcoin Peertopeer cryptocurrency with anonymous blockchain transactions and an improved proofofwork system 20146 Eiichiro Fujisaki and Koutarou Suzuki Traceable podpis pierścieniowy In Public Key CryptographyndashPKC 2007 pages 181ndash200 Springer 20077 Javier Herranz Aggregate signatures httpwwwiiiacsices~jherranzpapersNijmegen_seminar_aggregatepdf oct 20058 Joseph K Liu Victor K Wei and Duncan S Wong Linkable spontaneous anonymous group signature for ad hoc groups In Information Security and Privacy pages 325ndash335 Springer 20049 Adam Mackenzie Surae Noether and Monero Core Team Improving obfuscation in the cryptonote protocol httpslabgetmoneroorgpubsMRL-0004pdf January 201510 Greg Maxwell Coinjoin Bitcoin privacy for the real world august 2013 Bitcoin Forum httpsbitcointalkorgindexphptopic=2792490 2013 [Online accessed 1-July-2015]11 Greg Maxwell Confidential Transactions httpspeoplexiphorg~gregconfidential_valuestxt 2015 [Online accessed 1-June-2015]12 Greg Maxwell Elements project httpsgithubcomShenNoetherMiniNero 201513 Satoshi Nakamoto Bitcoin A peer-to-peer electronic cash system Consulted 1(2012)28 200814 Shen Noether Mininero httpsgithubcomShenNoetherMiniNero 201515 Ronald L Rivest Adi Shamir and Yael Tauman How to leak a secret In Advances in CryptologyASIACRYPT 2001 pages 552ndash565 Springer 200116 Nicolas van Saberhagen Cryptonote v 2 0 HYPERLINK https cryptonote org whitepaper pdf 2013

Załącznik A Załącznik Security ProofsA1 Brak możliwości sfałszowania MLSAG

Obliczenia przebiegają analogicznie do [8 Teoremat 1] Niech H1 oraz H2 będą losowo wybranymi oracle a SO stanowią podpisy oracle zwracające ważne podpisy MLSAG Załoacuteżmy że istnieje probabilistyczny wielomianowy adwersarz czasowy (PPT) A ktoacutery posiada zdolność sfałszowania MLSAG z listy wektoroacutew kluczy L przy prawdopodobieństwie ktoacuterego nie można pominąć

Gdzie Q1 stanowi wielomianowy parametr bezpieczeństwa k oraz gdzie (m σ) nie stanowi jednego z podpisoacutew zwracanych przez SO Załoacuteżmy że A nie wysyła więcej niż qH + nqS

(gdzie n oznacza liczbę kluczy w L) zapytań dotyczących podpisoacutew oracle H1H2 oraz SO odpowiednio Podpisy oracle H1 oraz H2 uważa się za niezależne i losowe oraz spoacutejne z danymi zapytaniami powtarzającymi się Podpis oracle SO może składać zapytanie H1 oraz H2 Mając wartość A wykaże że istnieje możliwość utworzenia adwersarza M w PPT ktoacutery będzie wykorzystywać A w celu znalezienia logarytmu dyskretnego jednego z kluczy w L

Jeżeli L stanowi zbioacuter kluczy wektoroacutew z ktoacuterych każdy będzie mieć wielkość r (tzn z kluczami publicznymi y1 hellip yr ) to wygenerowany fałszywy podpis

Wygenerowany przez A musi spełniać warunek

Gdzie i są obliczone w ramach mod n oraz są zdefiniowane zgodnie z Rozdziałem 22 Nowy adwersarz M może wykorzystać A w celu sfałszowania podpisoacutew wielomianową liczbę razy i zapisze każdy skrypt Turinga T niezależnie czy sfałszowanie było skuteczne czy nie

Lemma A1 [8 Lemma 1] Niech M wywołuje A w celu uzyskania transkrypcji T Jeżeli T jest skuteczne to M powraca do T do nagłoacutewka H i następnie re-symuluje A w celu uzyskania transkrypcji Trsquo Jeżeli Pr (T okaże się skuteczne) = ϵ to Pr (Trsquo jest skuteczne) = ϵ

Dowoacuted wynika wprost z przywołanego teorematu

Teoremat A2 Prawdopodobieństwo że adwersarz A sfałszuje podpis MLSAG można pominąć przy założeniu logarytmu dyskretnego

Dowoacuted Do przeprowadzenia dowodu będę stosować notację przedstawioną powyżej Podobnie jak w przypadku [8 teoremat 1] ponieważ prawdopodobieństwo odgadnięcia danych wyjściowych z losowego oracle jest znikome w związku z tym dla każdego skutecznego oszustwa A wprowadza transkrypcję uzupełniającą T a zatem mamy mT zapytań w przypadku zapytań do H1 odpowiadających liczbie n zapytań wykorzystywanych w celu weryfikacji podpisu W związku z tym niech Xi1 hellip Xim oznacza zapytania wykorzystywane w procesie weryfikacji fałszu ith oraz niech π oznacza indeks odpowiadający ostatniemu zapytaniu weryfikacyjnego dla danego oszustwa

(Intuicyjnie π odpowiada temu co może stanowić indeks sekretny fałszywego podpisu ponieważ odpowiada on ostatniemu wezwaniu ostatniemu wywołaniu losowego oracle dla danego odpisu)Proacuteba sfałszowania σ podjęta przez A stanowi fałsz (l π) jeżeli i1 = l oraz π jest zgodne z powyższym (zatem fałsz odpowiada zapytaniom l do l + π) Z założenia istnieje para (l π) taka że prawdopodobieństwo związanej transkrypcji T daje skutecznie wygenerowany fałszywy klucz ϵlπ (T) spełnia warunek

1

Teraz przeglądając T do wartości przed zapytaniem l-tym a następnie podejmując proacutebę sfałszowania za pomocą tego samego zbioru kluczy (oraz dopuszczając aby H1 obliczyło nowe rzuty monetami dla wszystkich kolejnych zapytań) z Lemmy A1 wynika że prawdopodobieństwo że Trsquo jest także skuteczne spełnia warunki

_Dlatego prawdopodobieństwo że zaroacutewno T jak i Trsquo odpowiadają weryfikacjom fałszywym σ i σ1 nie może zostać pominięte

Ponieważ nowe rzuty monetami zostały obliczone na podstawie danych wyjściowych losowych oracle H1 oznacza to że przy dużym prawdopodobieństwie istnieje wartość j taka

że oraz W związku z tym możemy rozwiązać klucz prywatny z indeksem π

ktoacutery jest sprzeczny z założeniami logarytmu dyskretnego

A2 Linkowalność MLSAG Teoremat A3 Linkowalność obrazu klucza (Key-Image Linkability) Prawdopodobieństwo że adwersarz a w PPT może utworzyć dwa podpisy weryfikujące (niepołączone w danym

ustawieniu σ σrsquo podpisane w odniesieniu do wektoroacutew kluczy oraz odpowiednio w taki

sposoacuteb że będzie istnieć klucz publiczny i w obu oraz może być pominięte

Dowoacuted Przypuśćmy że w przeciwieństwie do tego co zostało wcześniej powiedziane A utworzył dwa podpisy weryfikujące σ oraz σrsquo o oba są podpisami w odniesieniu do kluczowych wektoroacutew

oraz odpowiednio w taki sposoacuteb że istnieje klucz publiczny y zaroacutewno w jak i

Niech y występuje jako element j należący do a jrsquo jako element należący do rsquo Z teorematu A2 wynika z dużym prawdopodobieństwem że istnieją indeksy π oraz πrsquo dla kluczy publicznych σ oraz σrsquo odpowiednio takie że

oraz

z

oraz

Jeżeli uznamy że x oznacza klucz prywatny y y = xG to po rozwiązaniu powyższego dla Ij

oraz Ij0rsquo mamy następujące roacutewnania oraz podobnie Ijrsquo = xH (y) Tym samym dwa podpisy obejmują Ij = Ijrsquo i w związku z tym ponieważ zduplikowane obrazy kluczy są odrzucone jeden z nich nie może być wykorzystany do weryfikacji

A3 Anonimowość MLSAG W celu udowodnienia anonimowości powyższego protokołu w losowym modelu oracle przyjmijmy że H1 H2 to losowe oracle modelujące dyskretne funkcje haszujące Niech A to adwersarz anonimowości Buduję adwersarza M względem założenia problemu decyzyjnego Diffie Helmana (DDH) zgodnie z poniższym Założenie DDH stwierdza że mając daną krotność (G aG bG ϒG) prawdopodobieństwo ustalenia czy G = abG jest znikome

Teoremat A4 Protokoacuteł pierścieniowy CT jest dwuznaczny w odniesieniu do sygnatariusza przy założeniu problemu decyzyjnego Diffie-HelmanaDowoacuted (zbliżony do dowodu [8 Teoremat 2]) Załoacuteżmy że problem decyzyjny Diffie-Helmana jest trudny w cyklicznej grupie generowanej przez G i załoacuteżmy że istnieje adwersarz A w czasie PPT względem dwuznaczności sygnatariusza Tym samym mając listę L n wektoroacutew

kluczy publicznych o długości m oraz zbioacuter prywatnych kluczy t ważny podpis σ na L podpisany przez użytkownika w odniesieniu do wektora klucza y taki że

odpowiedni wektor klucza prywatnego wynosi spełnia to A może zdeterminować π z prawdopodobieństwem

Dla wybranych wielomianoacutew Q(k) Buduję adwersarza PPT M ktoacutery wykorzystuje krotność danych wejściowych (G aG bG ciG) gdzie I ϵ 0 1 jest losowo wybrany (a nie znany M a priori) c1 = ab oraz c0 jest losowym skalarem a dane wyjściowe i mają prawdopodobieństwo

Dla niektoacuterych wielomianoacutew Q2 (k)Należy rozważyć algorytm SIMNIZKP (zbliżony to tego ktoacutery został zdefiniowany w [6]) ktoacutery jako skalary wejściowe wykorzystuje wektor x klucza prywatnego zbioacuter wektoroacutew kluczy

publicznych indeks π oraz wiadomość m i ktoacutery działa w sposoacuteb następujący1 Wygenerować skalary losowe s1 hellip sm oraz skalar losowy cπ lt- H2 Dla j indeksującego określić

A dla pozostałych j

3 Obliczyć losowe dane wyjściowe na podstawie losowego oracle

4 Dla każdego i roboczego mod m obliczyć

Należy podkreślić że w ostatnim punkcie kiedy i = π - 1 to ci+1 jest już określone w celu utrzymania spoacutejności z losowymi danymi wyjściowymi oracleNależy podkreślić że niezależnie od tego czy jest rzeczywistym kluczem prywatnym odpowiadającym ze względu na to że spoacutejność jest zachowywana przez losowe wartości oracle w kolejnych wezwaniach powyższy podpis jest weryfikowany Jeżeli x jest rzeczywiście wektorem klucza prywatnego y to nie ma roacuteżnicy pomiędzy SIMNIZKP oraz rzeczywistym podpisemNa koniec mając krotność (G aG bG ciG) gdzie a b są losowo wybrany skalarami a c1 = ab c0 elementem losowym i ϵ 0 1 M zachodzi w poniższych krokach i pozwala rozwiązać problem decyzyjny Diffie Helmana za pomocą niepomijalnego prawdopodobieństwa M wychwytuje losowe ϒ lt-H z losowej wartości oracle oraz pobiera parę wektoroacutew klucza prywatnego publicznego (x y) a następnie oblicza s jako a = s + ϒx Teraz M wykonuje

SIMNIZKP za pomocą dowolnie wybranych wektoroacutew kluczy w taki sposoacuteb że w danej wiadomości m oraz Jeżeli prawdziwe jest że i = 1 to c = ab oraz logGaG = logbGcG = a

z uwagi na to że zakłada się iż A jest w stanie znaleźć π z prawdopodobieństwem ktoacuterego nie można pominąć to istnieje niepomijalne prawdopodobieństwo frac12 że A zwroacuteci 1 (i wtedy M zwroacuteci 1) Jeżeli i = 0 to A zwraca 1 wyłącznie z prawdopodobieństwem frac12 a zatem dla niektoacuterych niepomijanych prawdopodobieństw powyżej 1`2 M zwraca tę samą wartość co A i tym samym rozwiązuje problem decyzyjny Diffie-Helmana dla losowo wybranych skalaroacutew bez pomijalnego prawdopodobieństwa powyżej 12 co stanowi sprzeczność

Załącznik B Kod demo Ring CT W repozytorium w [14] zbudowałem prostą demonstrację protokołu poufnych transakcji pierścieniowych (Ring Confidential Transactions) wykorzystujących podpisy MLSAG w części 2 oraz podpisy ASNL w części 5

H_ct = RingCTgetHForCT()print(H H_ct)sr Pr = PaperWalletskpkGen() receivers private publicse pe ss = ecdhecdhgen(Pr) compute shared secret ssdigits = 14 in practice it will be 14print(inputs)Cia L1a s2a sa ska = RingCTgenRangeProof(10000 digits)print(outputs)Cib L1b s2b sb skb = RingCTgenRangeProof(7000 digits)Cic L1c s2c sc skc = RingCTgenRangeProof(3000 digits)print(verifying range proofs of outputs)RingCTverRangeProof(Cib L1b s2b sb)RingCTverRangeProof(Cic L1c s2c sc)x P1 = PaperWalletskpkGen()P2 = PaperWalletpkGen()C2 = PaperWalletpkGen()some random commitment grabbed from the blockchainind = 0Ca = RingCTsumCi(Cia)Cb = RingCTsumCi(Cib)Cc = RingCTsumCi(Cic)sk = [x MiniNerosc_sub_keys(ska MiniNerosc_add_keys(skb skc))]

pk = [[P1 P2] [MiniNerosubKeys(Ca MiniNeroaddKeys(Cb Cc)) MiniNerosubKeys(C2 MiniNeroaddKeys(Cb Cc)) ] ]II cc ssVal = MLSAGMLSAG_Sign(pk sk ind)print(Sig verified MLSAGMLSAG_Ver(pk II cc ssVal) )print(Finding received amount corresponding to Cib)RingCTComputeReceivedAmount(pe sr MiniNeroaddScalars(ss skb) Cib)print(Finding received amount corresponding to Cic)RingCTComputeReceivedAmount(pe sr MiniNeroaddScalars(ss skc) Cic)

Przykład transakcji z danymi wejściowymi 10 000 oraz wyjściowymi 3 000 i 7 000(rsquoHrsquo rsquo61fe7f0f5a607a33427d01dd1fded5ffa03fae2e9df9ebccf2e0a2f5bd77a204rsquo)inputs(rsquob b in binaryrsquo 10000 [0 0 0 0 1 0 0 0 1 1 1 0 0 1])Generating Aggregate Schnorr Non-linkable Podpis pierścieniowy outputs(rsquob b in binaryrsquo 7000 [0 0 0 1 1 0 1 0 1 1 0 1 1 0])Generating Aggregate Schnorr Non-linkable Podpis pierścieniowy (rsquob b in binaryrsquo 3000 [0 0 0 1 1 1 0 1 1 1 0 1 0 0])Generating Aggregate Schnorr Non-linkable Podpis pierścieniowy verifying range proofs of outputsVerifying Aggregate Schnorr Non-linkable Podpis pierścieniowy VerifiedVerifying Aggregate Schnorr Non-linkable Podpis pierścieniowy Verified(rsquoGenerating MLSAG sig of dimensions rsquo 2 rsquox rsquo 2)(rsquoverifying MLSAG sig of dimensions rsquo 2 rsquox rsquo 2)(rsquocrsquo[rsquo80a3cfd06dd2862307cd75c2a1566f20cd743dbb0b9feb22d79dcbecb9023f42rsquorsquoa9b7342ba7bf2f102505ca19dab734fde638916c0a29f5b30e49833ab51393earsquorsquo80a3cfd06dd2862307cd75c2a1566f20cd743dbb0b9feb22d79dcbecb9023f42rsquo])(rsquosig verifiesrsquo True)(rsquoSig verifiedrsquo True)Finding received amount corresponding to Cib(rsquoreceived rsquo 7000c Monero Research Lab Page 20 of 20rsquoa488ec68732fb551841c2c6dcc7ffac895d98ec7e9378275ed20ea12805fc18ersquo)Finding received amount corresponding to Cic(rsquoreceived rsquo3000rsquo1b46626858e130a0f3884c74c9fdeabc4d812c519103ea16a35a3f82a3d0ed6drsquo)

Załącznik A Załącznik Security ProofsA1 Brak możliwości sfałszowania MLSAG

Obliczenia przebiegają analogicznie do [8 Teoremat 1] Niech H1 oraz H2 będą losowo wybranymi oracle a SO stanowią podpisy oracle zwracające ważne podpisy MLSAG Załoacuteżmy że istnieje probabilistyczny wielomianowy adwersarz czasowy (PPT) A ktoacutery posiada zdolność sfałszowania MLSAG z listy wektoroacutew kluczy L przy prawdopodobieństwie ktoacuterego nie można pominąć

Gdzie Q1 stanowi wielomianowy parametr bezpieczeństwa k oraz gdzie (m σ) nie stanowi jednego z podpisoacutew zwracanych przez SO Załoacuteżmy że A nie wysyła więcej niż qH + nqS

(gdzie n oznacza liczbę kluczy w L) zapytań dotyczących podpisoacutew oracle H1H2 oraz SO odpowiednio Podpisy oracle H1 oraz H2 uważa się za niezależne i losowe oraz spoacutejne z danymi zapytaniami powtarzającymi się Podpis oracle SO może składać zapytanie H1 oraz H2 Mając wartość A wykaże że istnieje możliwość utworzenia adwersarza M w PPT ktoacutery będzie wykorzystywać A w celu znalezienia logarytmu dyskretnego jednego z kluczy w L

Jeżeli L stanowi zbioacuter kluczy wektoroacutew z ktoacuterych każdy będzie mieć wielkość r (tzn z kluczami publicznymi y1 hellip yr ) to wygenerowany fałszywy podpis

Wygenerowany przez A musi spełniać warunek

Gdzie i są obliczone w ramach mod n oraz są zdefiniowane zgodnie z Rozdziałem 22 Nowy adwersarz M może wykorzystać A w celu sfałszowania podpisoacutew wielomianową liczbę razy i zapisze każdy skrypt Turinga T niezależnie czy sfałszowanie było skuteczne czy nie

Lemma A1 [8 Lemma 1] Niech M wywołuje A w celu uzyskania transkrypcji T Jeżeli T jest skuteczne to M powraca do T do nagłoacutewka H i następnie re-symuluje A w celu uzyskania transkrypcji Trsquo Jeżeli Pr (T okaże się skuteczne) = ϵ to Pr (Trsquo jest skuteczne) = ϵ

Dowoacuted wynika wprost z przywołanego teorematu

Teoremat A2 Prawdopodobieństwo że adwersarz A sfałszuje podpis MLSAG można pominąć przy założeniu logarytmu dyskretnego

Dowoacuted Do przeprowadzenia dowodu będę stosować notację przedstawioną powyżej Podobnie jak w przypadku [8 teoremat 1] ponieważ prawdopodobieństwo odgadnięcia danych wyjściowych z losowego oracle jest znikome w związku z tym dla każdego skutecznego oszustwa A wprowadza transkrypcję uzupełniającą T a zatem mamy mT zapytań w przypadku zapytań do H1 odpowiadających liczbie n zapytań wykorzystywanych w celu weryfikacji podpisu W związku z tym niech Xi1 hellip Xim oznacza zapytania wykorzystywane w procesie weryfikacji fałszu ith oraz niech π oznacza indeks odpowiadający ostatniemu zapytaniu weryfikacyjnego dla danego oszustwa

(Intuicyjnie π odpowiada temu co może stanowić indeks sekretny fałszywego podpisu ponieważ odpowiada on ostatniemu wezwaniu ostatniemu wywołaniu losowego oracle dla danego odpisu)Proacuteba sfałszowania σ podjęta przez A stanowi fałsz (l π) jeżeli i1 = l oraz π jest zgodne z powyższym (zatem fałsz odpowiada zapytaniom l do l + π) Z założenia istnieje para (l π) taka że prawdopodobieństwo związanej transkrypcji T daje skutecznie wygenerowany fałszywy klucz ϵlπ (T) spełnia warunek

1

Teraz przeglądając T do wartości przed zapytaniem l-tym a następnie podejmując proacutebę sfałszowania za pomocą tego samego zbioru kluczy (oraz dopuszczając aby H1 obliczyło nowe rzuty monetami dla wszystkich kolejnych zapytań) z Lemmy A1 wynika że prawdopodobieństwo że Trsquo jest także skuteczne spełnia warunki

_Dlatego prawdopodobieństwo że zaroacutewno T jak i Trsquo odpowiadają weryfikacjom fałszywym σ i σ1 nie może zostać pominięte

Ponieważ nowe rzuty monetami zostały obliczone na podstawie danych wyjściowych losowych oracle H1 oznacza to że przy dużym prawdopodobieństwie istnieje wartość j taka

że oraz W związku z tym możemy rozwiązać klucz prywatny z indeksem π

ktoacutery jest sprzeczny z założeniami logarytmu dyskretnego

A2 Linkowalność MLSAG Teoremat A3 Linkowalność obrazu klucza (Key-Image Linkability) Prawdopodobieństwo że adwersarz a w PPT może utworzyć dwa podpisy weryfikujące (niepołączone w danym

ustawieniu σ σrsquo podpisane w odniesieniu do wektoroacutew kluczy oraz odpowiednio w taki

sposoacuteb że będzie istnieć klucz publiczny i w obu oraz może być pominięte

Dowoacuted Przypuśćmy że w przeciwieństwie do tego co zostało wcześniej powiedziane A utworzył dwa podpisy weryfikujące σ oraz σrsquo o oba są podpisami w odniesieniu do kluczowych wektoroacutew

oraz odpowiednio w taki sposoacuteb że istnieje klucz publiczny y zaroacutewno w jak i

Niech y występuje jako element j należący do a jrsquo jako element należący do rsquo Z teorematu A2 wynika z dużym prawdopodobieństwem że istnieją indeksy π oraz πrsquo dla kluczy publicznych σ oraz σrsquo odpowiednio takie że

oraz

z

oraz

Jeżeli uznamy że x oznacza klucz prywatny y y = xG to po rozwiązaniu powyższego dla Ij

oraz Ij0rsquo mamy następujące roacutewnania oraz podobnie Ijrsquo = xH (y) Tym samym dwa podpisy obejmują Ij = Ijrsquo i w związku z tym ponieważ zduplikowane obrazy kluczy są odrzucone jeden z nich nie może być wykorzystany do weryfikacji

A3 Anonimowość MLSAG W celu udowodnienia anonimowości powyższego protokołu w losowym modelu oracle przyjmijmy że H1 H2 to losowe oracle modelujące dyskretne funkcje haszujące Niech A to adwersarz anonimowości Buduję adwersarza M względem założenia problemu decyzyjnego Diffie Helmana (DDH) zgodnie z poniższym Założenie DDH stwierdza że mając daną krotność (G aG bG ϒG) prawdopodobieństwo ustalenia czy G = abG jest znikome

Teoremat A4 Protokoacuteł pierścieniowy CT jest dwuznaczny w odniesieniu do sygnatariusza przy założeniu problemu decyzyjnego Diffie-HelmanaDowoacuted (zbliżony do dowodu [8 Teoremat 2]) Załoacuteżmy że problem decyzyjny Diffie-Helmana jest trudny w cyklicznej grupie generowanej przez G i załoacuteżmy że istnieje adwersarz A w czasie PPT względem dwuznaczności sygnatariusza Tym samym mając listę L n wektoroacutew

kluczy publicznych o długości m oraz zbioacuter prywatnych kluczy t ważny podpis σ na L podpisany przez użytkownika w odniesieniu do wektora klucza y taki że

odpowiedni wektor klucza prywatnego wynosi spełnia to A może zdeterminować π z prawdopodobieństwem

Dla wybranych wielomianoacutew Q(k) Buduję adwersarza PPT M ktoacutery wykorzystuje krotność danych wejściowych (G aG bG ciG) gdzie I ϵ 0 1 jest losowo wybrany (a nie znany M a priori) c1 = ab oraz c0 jest losowym skalarem a dane wyjściowe i mają prawdopodobieństwo

Dla niektoacuterych wielomianoacutew Q2 (k)Należy rozważyć algorytm SIMNIZKP (zbliżony to tego ktoacutery został zdefiniowany w [6]) ktoacutery jako skalary wejściowe wykorzystuje wektor x klucza prywatnego zbioacuter wektoroacutew kluczy

publicznych indeks π oraz wiadomość m i ktoacutery działa w sposoacuteb następujący1 Wygenerować skalary losowe s1 hellip sm oraz skalar losowy cπ lt- H2 Dla j indeksującego określić

A dla pozostałych j

3 Obliczyć losowe dane wyjściowe na podstawie losowego oracle

4 Dla każdego i roboczego mod m obliczyć

Należy podkreślić że w ostatnim punkcie kiedy i = π - 1 to ci+1 jest już określone w celu utrzymania spoacutejności z losowymi danymi wyjściowymi oracleNależy podkreślić że niezależnie od tego czy jest rzeczywistym kluczem prywatnym odpowiadającym ze względu na to że spoacutejność jest zachowywana przez losowe wartości oracle w kolejnych wezwaniach powyższy podpis jest weryfikowany Jeżeli x jest rzeczywiście wektorem klucza prywatnego y to nie ma roacuteżnicy pomiędzy SIMNIZKP oraz rzeczywistym podpisemNa koniec mając krotność (G aG bG ciG) gdzie a b są losowo wybrany skalarami a c1 = ab c0 elementem losowym i ϵ 0 1 M zachodzi w poniższych krokach i pozwala rozwiązać problem decyzyjny Diffie Helmana za pomocą niepomijalnego prawdopodobieństwa M wychwytuje losowe ϒ lt-H z losowej wartości oracle oraz pobiera parę wektoroacutew klucza prywatnego publicznego (x y) a następnie oblicza s jako a = s + ϒx Teraz M wykonuje

SIMNIZKP za pomocą dowolnie wybranych wektoroacutew kluczy w taki sposoacuteb że w danej wiadomości m oraz Jeżeli prawdziwe jest że i = 1 to c = ab oraz logGaG = logbGcG = a

z uwagi na to że zakłada się iż A jest w stanie znaleźć π z prawdopodobieństwem ktoacuterego nie można pominąć to istnieje niepomijalne prawdopodobieństwo frac12 że A zwroacuteci 1 (i wtedy M zwroacuteci 1) Jeżeli i = 0 to A zwraca 1 wyłącznie z prawdopodobieństwem frac12 a zatem dla niektoacuterych niepomijanych prawdopodobieństw powyżej 1`2 M zwraca tę samą wartość co A i tym samym rozwiązuje problem decyzyjny Diffie-Helmana dla losowo wybranych skalaroacutew bez pomijalnego prawdopodobieństwa powyżej 12 co stanowi sprzeczność

Załącznik B Kod demo Ring CT W repozytorium w [14] zbudowałem prostą demonstrację protokołu poufnych transakcji pierścieniowych (Ring Confidential Transactions) wykorzystujących podpisy MLSAG w części 2 oraz podpisy ASNL w części 5

H_ct = RingCTgetHForCT()print(H H_ct)sr Pr = PaperWalletskpkGen() receivers private publicse pe ss = ecdhecdhgen(Pr) compute shared secret ssdigits = 14 in practice it will be 14print(inputs)Cia L1a s2a sa ska = RingCTgenRangeProof(10000 digits)print(outputs)Cib L1b s2b sb skb = RingCTgenRangeProof(7000 digits)Cic L1c s2c sc skc = RingCTgenRangeProof(3000 digits)print(verifying range proofs of outputs)RingCTverRangeProof(Cib L1b s2b sb)RingCTverRangeProof(Cic L1c s2c sc)x P1 = PaperWalletskpkGen()P2 = PaperWalletpkGen()C2 = PaperWalletpkGen()some random commitment grabbed from the blockchainind = 0Ca = RingCTsumCi(Cia)Cb = RingCTsumCi(Cib)Cc = RingCTsumCi(Cic)sk = [x MiniNerosc_sub_keys(ska MiniNerosc_add_keys(skb skc))]

pk = [[P1 P2] [MiniNerosubKeys(Ca MiniNeroaddKeys(Cb Cc)) MiniNerosubKeys(C2 MiniNeroaddKeys(Cb Cc)) ] ]II cc ssVal = MLSAGMLSAG_Sign(pk sk ind)print(Sig verified MLSAGMLSAG_Ver(pk II cc ssVal) )print(Finding received amount corresponding to Cib)RingCTComputeReceivedAmount(pe sr MiniNeroaddScalars(ss skb) Cib)print(Finding received amount corresponding to Cic)RingCTComputeReceivedAmount(pe sr MiniNeroaddScalars(ss skc) Cic)

Przykład transakcji z danymi wejściowymi 10 000 oraz wyjściowymi 3 000 i 7 000(rsquoHrsquo rsquo61fe7f0f5a607a33427d01dd1fded5ffa03fae2e9df9ebccf2e0a2f5bd77a204rsquo)inputs(rsquob b in binaryrsquo 10000 [0 0 0 0 1 0 0 0 1 1 1 0 0 1])Generating Aggregate Schnorr Non-linkable Podpis pierścieniowy outputs(rsquob b in binaryrsquo 7000 [0 0 0 1 1 0 1 0 1 1 0 1 1 0])Generating Aggregate Schnorr Non-linkable Podpis pierścieniowy (rsquob b in binaryrsquo 3000 [0 0 0 1 1 1 0 1 1 1 0 1 0 0])Generating Aggregate Schnorr Non-linkable Podpis pierścieniowy verifying range proofs of outputsVerifying Aggregate Schnorr Non-linkable Podpis pierścieniowy VerifiedVerifying Aggregate Schnorr Non-linkable Podpis pierścieniowy Verified(rsquoGenerating MLSAG sig of dimensions rsquo 2 rsquox rsquo 2)(rsquoverifying MLSAG sig of dimensions rsquo 2 rsquox rsquo 2)(rsquocrsquo[rsquo80a3cfd06dd2862307cd75c2a1566f20cd743dbb0b9feb22d79dcbecb9023f42rsquorsquoa9b7342ba7bf2f102505ca19dab734fde638916c0a29f5b30e49833ab51393earsquorsquo80a3cfd06dd2862307cd75c2a1566f20cd743dbb0b9feb22d79dcbecb9023f42rsquo])(rsquosig verifiesrsquo True)(rsquoSig verifiedrsquo True)Finding received amount corresponding to Cib(rsquoreceived rsquo 7000c Monero Research Lab Page 20 of 20rsquoa488ec68732fb551841c2c6dcc7ffac895d98ec7e9378275ed20ea12805fc18ersquo)Finding received amount corresponding to Cic(rsquoreceived rsquo3000rsquo1b46626858e130a0f3884c74c9fdeabc4d812c519103ea16a35a3f82a3d0ed6drsquo)

(Intuicyjnie π odpowiada temu co może stanowić indeks sekretny fałszywego podpisu ponieważ odpowiada on ostatniemu wezwaniu ostatniemu wywołaniu losowego oracle dla danego odpisu)Proacuteba sfałszowania σ podjęta przez A stanowi fałsz (l π) jeżeli i1 = l oraz π jest zgodne z powyższym (zatem fałsz odpowiada zapytaniom l do l + π) Z założenia istnieje para (l π) taka że prawdopodobieństwo związanej transkrypcji T daje skutecznie wygenerowany fałszywy klucz ϵlπ (T) spełnia warunek

1

Teraz przeglądając T do wartości przed zapytaniem l-tym a następnie podejmując proacutebę sfałszowania za pomocą tego samego zbioru kluczy (oraz dopuszczając aby H1 obliczyło nowe rzuty monetami dla wszystkich kolejnych zapytań) z Lemmy A1 wynika że prawdopodobieństwo że Trsquo jest także skuteczne spełnia warunki

_Dlatego prawdopodobieństwo że zaroacutewno T jak i Trsquo odpowiadają weryfikacjom fałszywym σ i σ1 nie może zostać pominięte

Ponieważ nowe rzuty monetami zostały obliczone na podstawie danych wyjściowych losowych oracle H1 oznacza to że przy dużym prawdopodobieństwie istnieje wartość j taka

że oraz W związku z tym możemy rozwiązać klucz prywatny z indeksem π

ktoacutery jest sprzeczny z założeniami logarytmu dyskretnego

A2 Linkowalność MLSAG Teoremat A3 Linkowalność obrazu klucza (Key-Image Linkability) Prawdopodobieństwo że adwersarz a w PPT może utworzyć dwa podpisy weryfikujące (niepołączone w danym

ustawieniu σ σrsquo podpisane w odniesieniu do wektoroacutew kluczy oraz odpowiednio w taki

sposoacuteb że będzie istnieć klucz publiczny i w obu oraz może być pominięte

Dowoacuted Przypuśćmy że w przeciwieństwie do tego co zostało wcześniej powiedziane A utworzył dwa podpisy weryfikujące σ oraz σrsquo o oba są podpisami w odniesieniu do kluczowych wektoroacutew

oraz odpowiednio w taki sposoacuteb że istnieje klucz publiczny y zaroacutewno w jak i

Niech y występuje jako element j należący do a jrsquo jako element należący do rsquo Z teorematu A2 wynika z dużym prawdopodobieństwem że istnieją indeksy π oraz πrsquo dla kluczy publicznych σ oraz σrsquo odpowiednio takie że

oraz

z

oraz

Jeżeli uznamy że x oznacza klucz prywatny y y = xG to po rozwiązaniu powyższego dla Ij

oraz Ij0rsquo mamy następujące roacutewnania oraz podobnie Ijrsquo = xH (y) Tym samym dwa podpisy obejmują Ij = Ijrsquo i w związku z tym ponieważ zduplikowane obrazy kluczy są odrzucone jeden z nich nie może być wykorzystany do weryfikacji

A3 Anonimowość MLSAG W celu udowodnienia anonimowości powyższego protokołu w losowym modelu oracle przyjmijmy że H1 H2 to losowe oracle modelujące dyskretne funkcje haszujące Niech A to adwersarz anonimowości Buduję adwersarza M względem założenia problemu decyzyjnego Diffie Helmana (DDH) zgodnie z poniższym Założenie DDH stwierdza że mając daną krotność (G aG bG ϒG) prawdopodobieństwo ustalenia czy G = abG jest znikome

Teoremat A4 Protokoacuteł pierścieniowy CT jest dwuznaczny w odniesieniu do sygnatariusza przy założeniu problemu decyzyjnego Diffie-HelmanaDowoacuted (zbliżony do dowodu [8 Teoremat 2]) Załoacuteżmy że problem decyzyjny Diffie-Helmana jest trudny w cyklicznej grupie generowanej przez G i załoacuteżmy że istnieje adwersarz A w czasie PPT względem dwuznaczności sygnatariusza Tym samym mając listę L n wektoroacutew

kluczy publicznych o długości m oraz zbioacuter prywatnych kluczy t ważny podpis σ na L podpisany przez użytkownika w odniesieniu do wektora klucza y taki że

odpowiedni wektor klucza prywatnego wynosi spełnia to A może zdeterminować π z prawdopodobieństwem

Dla wybranych wielomianoacutew Q(k) Buduję adwersarza PPT M ktoacutery wykorzystuje krotność danych wejściowych (G aG bG ciG) gdzie I ϵ 0 1 jest losowo wybrany (a nie znany M a priori) c1 = ab oraz c0 jest losowym skalarem a dane wyjściowe i mają prawdopodobieństwo

Dla niektoacuterych wielomianoacutew Q2 (k)Należy rozważyć algorytm SIMNIZKP (zbliżony to tego ktoacutery został zdefiniowany w [6]) ktoacutery jako skalary wejściowe wykorzystuje wektor x klucza prywatnego zbioacuter wektoroacutew kluczy

publicznych indeks π oraz wiadomość m i ktoacutery działa w sposoacuteb następujący1 Wygenerować skalary losowe s1 hellip sm oraz skalar losowy cπ lt- H2 Dla j indeksującego określić

A dla pozostałych j

3 Obliczyć losowe dane wyjściowe na podstawie losowego oracle

4 Dla każdego i roboczego mod m obliczyć

Należy podkreślić że w ostatnim punkcie kiedy i = π - 1 to ci+1 jest już określone w celu utrzymania spoacutejności z losowymi danymi wyjściowymi oracleNależy podkreślić że niezależnie od tego czy jest rzeczywistym kluczem prywatnym odpowiadającym ze względu na to że spoacutejność jest zachowywana przez losowe wartości oracle w kolejnych wezwaniach powyższy podpis jest weryfikowany Jeżeli x jest rzeczywiście wektorem klucza prywatnego y to nie ma roacuteżnicy pomiędzy SIMNIZKP oraz rzeczywistym podpisemNa koniec mając krotność (G aG bG ciG) gdzie a b są losowo wybrany skalarami a c1 = ab c0 elementem losowym i ϵ 0 1 M zachodzi w poniższych krokach i pozwala rozwiązać problem decyzyjny Diffie Helmana za pomocą niepomijalnego prawdopodobieństwa M wychwytuje losowe ϒ lt-H z losowej wartości oracle oraz pobiera parę wektoroacutew klucza prywatnego publicznego (x y) a następnie oblicza s jako a = s + ϒx Teraz M wykonuje

SIMNIZKP za pomocą dowolnie wybranych wektoroacutew kluczy w taki sposoacuteb że w danej wiadomości m oraz Jeżeli prawdziwe jest że i = 1 to c = ab oraz logGaG = logbGcG = a

z uwagi na to że zakłada się iż A jest w stanie znaleźć π z prawdopodobieństwem ktoacuterego nie można pominąć to istnieje niepomijalne prawdopodobieństwo frac12 że A zwroacuteci 1 (i wtedy M zwroacuteci 1) Jeżeli i = 0 to A zwraca 1 wyłącznie z prawdopodobieństwem frac12 a zatem dla niektoacuterych niepomijanych prawdopodobieństw powyżej 1`2 M zwraca tę samą wartość co A i tym samym rozwiązuje problem decyzyjny Diffie-Helmana dla losowo wybranych skalaroacutew bez pomijalnego prawdopodobieństwa powyżej 12 co stanowi sprzeczność

Załącznik B Kod demo Ring CT W repozytorium w [14] zbudowałem prostą demonstrację protokołu poufnych transakcji pierścieniowych (Ring Confidential Transactions) wykorzystujących podpisy MLSAG w części 2 oraz podpisy ASNL w części 5

H_ct = RingCTgetHForCT()print(H H_ct)sr Pr = PaperWalletskpkGen() receivers private publicse pe ss = ecdhecdhgen(Pr) compute shared secret ssdigits = 14 in practice it will be 14print(inputs)Cia L1a s2a sa ska = RingCTgenRangeProof(10000 digits)print(outputs)Cib L1b s2b sb skb = RingCTgenRangeProof(7000 digits)Cic L1c s2c sc skc = RingCTgenRangeProof(3000 digits)print(verifying range proofs of outputs)RingCTverRangeProof(Cib L1b s2b sb)RingCTverRangeProof(Cic L1c s2c sc)x P1 = PaperWalletskpkGen()P2 = PaperWalletpkGen()C2 = PaperWalletpkGen()some random commitment grabbed from the blockchainind = 0Ca = RingCTsumCi(Cia)Cb = RingCTsumCi(Cib)Cc = RingCTsumCi(Cic)sk = [x MiniNerosc_sub_keys(ska MiniNerosc_add_keys(skb skc))]

pk = [[P1 P2] [MiniNerosubKeys(Ca MiniNeroaddKeys(Cb Cc)) MiniNerosubKeys(C2 MiniNeroaddKeys(Cb Cc)) ] ]II cc ssVal = MLSAGMLSAG_Sign(pk sk ind)print(Sig verified MLSAGMLSAG_Ver(pk II cc ssVal) )print(Finding received amount corresponding to Cib)RingCTComputeReceivedAmount(pe sr MiniNeroaddScalars(ss skb) Cib)print(Finding received amount corresponding to Cic)RingCTComputeReceivedAmount(pe sr MiniNeroaddScalars(ss skc) Cic)

Przykład transakcji z danymi wejściowymi 10 000 oraz wyjściowymi 3 000 i 7 000(rsquoHrsquo rsquo61fe7f0f5a607a33427d01dd1fded5ffa03fae2e9df9ebccf2e0a2f5bd77a204rsquo)inputs(rsquob b in binaryrsquo 10000 [0 0 0 0 1 0 0 0 1 1 1 0 0 1])Generating Aggregate Schnorr Non-linkable Podpis pierścieniowy outputs(rsquob b in binaryrsquo 7000 [0 0 0 1 1 0 1 0 1 1 0 1 1 0])Generating Aggregate Schnorr Non-linkable Podpis pierścieniowy (rsquob b in binaryrsquo 3000 [0 0 0 1 1 1 0 1 1 1 0 1 0 0])Generating Aggregate Schnorr Non-linkable Podpis pierścieniowy verifying range proofs of outputsVerifying Aggregate Schnorr Non-linkable Podpis pierścieniowy VerifiedVerifying Aggregate Schnorr Non-linkable Podpis pierścieniowy Verified(rsquoGenerating MLSAG sig of dimensions rsquo 2 rsquox rsquo 2)(rsquoverifying MLSAG sig of dimensions rsquo 2 rsquox rsquo 2)(rsquocrsquo[rsquo80a3cfd06dd2862307cd75c2a1566f20cd743dbb0b9feb22d79dcbecb9023f42rsquorsquoa9b7342ba7bf2f102505ca19dab734fde638916c0a29f5b30e49833ab51393earsquorsquo80a3cfd06dd2862307cd75c2a1566f20cd743dbb0b9feb22d79dcbecb9023f42rsquo])(rsquosig verifiesrsquo True)(rsquoSig verifiedrsquo True)Finding received amount corresponding to Cib(rsquoreceived rsquo 7000c Monero Research Lab Page 20 of 20rsquoa488ec68732fb551841c2c6dcc7ffac895d98ec7e9378275ed20ea12805fc18ersquo)Finding received amount corresponding to Cic(rsquoreceived rsquo3000rsquo1b46626858e130a0f3884c74c9fdeabc4d812c519103ea16a35a3f82a3d0ed6drsquo)

oraz

z

oraz

Jeżeli uznamy że x oznacza klucz prywatny y y = xG to po rozwiązaniu powyższego dla Ij

oraz Ij0rsquo mamy następujące roacutewnania oraz podobnie Ijrsquo = xH (y) Tym samym dwa podpisy obejmują Ij = Ijrsquo i w związku z tym ponieważ zduplikowane obrazy kluczy są odrzucone jeden z nich nie może być wykorzystany do weryfikacji

A3 Anonimowość MLSAG W celu udowodnienia anonimowości powyższego protokołu w losowym modelu oracle przyjmijmy że H1 H2 to losowe oracle modelujące dyskretne funkcje haszujące Niech A to adwersarz anonimowości Buduję adwersarza M względem założenia problemu decyzyjnego Diffie Helmana (DDH) zgodnie z poniższym Założenie DDH stwierdza że mając daną krotność (G aG bG ϒG) prawdopodobieństwo ustalenia czy G = abG jest znikome

Teoremat A4 Protokoacuteł pierścieniowy CT jest dwuznaczny w odniesieniu do sygnatariusza przy założeniu problemu decyzyjnego Diffie-HelmanaDowoacuted (zbliżony do dowodu [8 Teoremat 2]) Załoacuteżmy że problem decyzyjny Diffie-Helmana jest trudny w cyklicznej grupie generowanej przez G i załoacuteżmy że istnieje adwersarz A w czasie PPT względem dwuznaczności sygnatariusza Tym samym mając listę L n wektoroacutew

kluczy publicznych o długości m oraz zbioacuter prywatnych kluczy t ważny podpis σ na L podpisany przez użytkownika w odniesieniu do wektora klucza y taki że

odpowiedni wektor klucza prywatnego wynosi spełnia to A może zdeterminować π z prawdopodobieństwem

Dla wybranych wielomianoacutew Q(k) Buduję adwersarza PPT M ktoacutery wykorzystuje krotność danych wejściowych (G aG bG ciG) gdzie I ϵ 0 1 jest losowo wybrany (a nie znany M a priori) c1 = ab oraz c0 jest losowym skalarem a dane wyjściowe i mają prawdopodobieństwo

Dla niektoacuterych wielomianoacutew Q2 (k)Należy rozważyć algorytm SIMNIZKP (zbliżony to tego ktoacutery został zdefiniowany w [6]) ktoacutery jako skalary wejściowe wykorzystuje wektor x klucza prywatnego zbioacuter wektoroacutew kluczy

publicznych indeks π oraz wiadomość m i ktoacutery działa w sposoacuteb następujący1 Wygenerować skalary losowe s1 hellip sm oraz skalar losowy cπ lt- H2 Dla j indeksującego określić

A dla pozostałych j

3 Obliczyć losowe dane wyjściowe na podstawie losowego oracle

4 Dla każdego i roboczego mod m obliczyć

Należy podkreślić że w ostatnim punkcie kiedy i = π - 1 to ci+1 jest już określone w celu utrzymania spoacutejności z losowymi danymi wyjściowymi oracleNależy podkreślić że niezależnie od tego czy jest rzeczywistym kluczem prywatnym odpowiadającym ze względu na to że spoacutejność jest zachowywana przez losowe wartości oracle w kolejnych wezwaniach powyższy podpis jest weryfikowany Jeżeli x jest rzeczywiście wektorem klucza prywatnego y to nie ma roacuteżnicy pomiędzy SIMNIZKP oraz rzeczywistym podpisemNa koniec mając krotność (G aG bG ciG) gdzie a b są losowo wybrany skalarami a c1 = ab c0 elementem losowym i ϵ 0 1 M zachodzi w poniższych krokach i pozwala rozwiązać problem decyzyjny Diffie Helmana za pomocą niepomijalnego prawdopodobieństwa M wychwytuje losowe ϒ lt-H z losowej wartości oracle oraz pobiera parę wektoroacutew klucza prywatnego publicznego (x y) a następnie oblicza s jako a = s + ϒx Teraz M wykonuje

SIMNIZKP za pomocą dowolnie wybranych wektoroacutew kluczy w taki sposoacuteb że w danej wiadomości m oraz Jeżeli prawdziwe jest że i = 1 to c = ab oraz logGaG = logbGcG = a

z uwagi na to że zakłada się iż A jest w stanie znaleźć π z prawdopodobieństwem ktoacuterego nie można pominąć to istnieje niepomijalne prawdopodobieństwo frac12 że A zwroacuteci 1 (i wtedy M zwroacuteci 1) Jeżeli i = 0 to A zwraca 1 wyłącznie z prawdopodobieństwem frac12 a zatem dla niektoacuterych niepomijanych prawdopodobieństw powyżej 1`2 M zwraca tę samą wartość co A i tym samym rozwiązuje problem decyzyjny Diffie-Helmana dla losowo wybranych skalaroacutew bez pomijalnego prawdopodobieństwa powyżej 12 co stanowi sprzeczność

Załącznik B Kod demo Ring CT W repozytorium w [14] zbudowałem prostą demonstrację protokołu poufnych transakcji pierścieniowych (Ring Confidential Transactions) wykorzystujących podpisy MLSAG w części 2 oraz podpisy ASNL w części 5

H_ct = RingCTgetHForCT()print(H H_ct)sr Pr = PaperWalletskpkGen() receivers private publicse pe ss = ecdhecdhgen(Pr) compute shared secret ssdigits = 14 in practice it will be 14print(inputs)Cia L1a s2a sa ska = RingCTgenRangeProof(10000 digits)print(outputs)Cib L1b s2b sb skb = RingCTgenRangeProof(7000 digits)Cic L1c s2c sc skc = RingCTgenRangeProof(3000 digits)print(verifying range proofs of outputs)RingCTverRangeProof(Cib L1b s2b sb)RingCTverRangeProof(Cic L1c s2c sc)x P1 = PaperWalletskpkGen()P2 = PaperWalletpkGen()C2 = PaperWalletpkGen()some random commitment grabbed from the blockchainind = 0Ca = RingCTsumCi(Cia)Cb = RingCTsumCi(Cib)Cc = RingCTsumCi(Cic)sk = [x MiniNerosc_sub_keys(ska MiniNerosc_add_keys(skb skc))]

pk = [[P1 P2] [MiniNerosubKeys(Ca MiniNeroaddKeys(Cb Cc)) MiniNerosubKeys(C2 MiniNeroaddKeys(Cb Cc)) ] ]II cc ssVal = MLSAGMLSAG_Sign(pk sk ind)print(Sig verified MLSAGMLSAG_Ver(pk II cc ssVal) )print(Finding received amount corresponding to Cib)RingCTComputeReceivedAmount(pe sr MiniNeroaddScalars(ss skb) Cib)print(Finding received amount corresponding to Cic)RingCTComputeReceivedAmount(pe sr MiniNeroaddScalars(ss skc) Cic)

Przykład transakcji z danymi wejściowymi 10 000 oraz wyjściowymi 3 000 i 7 000(rsquoHrsquo rsquo61fe7f0f5a607a33427d01dd1fded5ffa03fae2e9df9ebccf2e0a2f5bd77a204rsquo)inputs(rsquob b in binaryrsquo 10000 [0 0 0 0 1 0 0 0 1 1 1 0 0 1])Generating Aggregate Schnorr Non-linkable Podpis pierścieniowy outputs(rsquob b in binaryrsquo 7000 [0 0 0 1 1 0 1 0 1 1 0 1 1 0])Generating Aggregate Schnorr Non-linkable Podpis pierścieniowy (rsquob b in binaryrsquo 3000 [0 0 0 1 1 1 0 1 1 1 0 1 0 0])Generating Aggregate Schnorr Non-linkable Podpis pierścieniowy verifying range proofs of outputsVerifying Aggregate Schnorr Non-linkable Podpis pierścieniowy VerifiedVerifying Aggregate Schnorr Non-linkable Podpis pierścieniowy Verified(rsquoGenerating MLSAG sig of dimensions rsquo 2 rsquox rsquo 2)(rsquoverifying MLSAG sig of dimensions rsquo 2 rsquox rsquo 2)(rsquocrsquo[rsquo80a3cfd06dd2862307cd75c2a1566f20cd743dbb0b9feb22d79dcbecb9023f42rsquorsquoa9b7342ba7bf2f102505ca19dab734fde638916c0a29f5b30e49833ab51393earsquorsquo80a3cfd06dd2862307cd75c2a1566f20cd743dbb0b9feb22d79dcbecb9023f42rsquo])(rsquosig verifiesrsquo True)(rsquoSig verifiedrsquo True)Finding received amount corresponding to Cib(rsquoreceived rsquo 7000c Monero Research Lab Page 20 of 20rsquoa488ec68732fb551841c2c6dcc7ffac895d98ec7e9378275ed20ea12805fc18ersquo)Finding received amount corresponding to Cic(rsquoreceived rsquo3000rsquo1b46626858e130a0f3884c74c9fdeabc4d812c519103ea16a35a3f82a3d0ed6drsquo)

Dla wybranych wielomianoacutew Q(k) Buduję adwersarza PPT M ktoacutery wykorzystuje krotność danych wejściowych (G aG bG ciG) gdzie I ϵ 0 1 jest losowo wybrany (a nie znany M a priori) c1 = ab oraz c0 jest losowym skalarem a dane wyjściowe i mają prawdopodobieństwo

Dla niektoacuterych wielomianoacutew Q2 (k)Należy rozważyć algorytm SIMNIZKP (zbliżony to tego ktoacutery został zdefiniowany w [6]) ktoacutery jako skalary wejściowe wykorzystuje wektor x klucza prywatnego zbioacuter wektoroacutew kluczy

publicznych indeks π oraz wiadomość m i ktoacutery działa w sposoacuteb następujący1 Wygenerować skalary losowe s1 hellip sm oraz skalar losowy cπ lt- H2 Dla j indeksującego określić

A dla pozostałych j

3 Obliczyć losowe dane wyjściowe na podstawie losowego oracle

4 Dla każdego i roboczego mod m obliczyć

Należy podkreślić że w ostatnim punkcie kiedy i = π - 1 to ci+1 jest już określone w celu utrzymania spoacutejności z losowymi danymi wyjściowymi oracleNależy podkreślić że niezależnie od tego czy jest rzeczywistym kluczem prywatnym odpowiadającym ze względu na to że spoacutejność jest zachowywana przez losowe wartości oracle w kolejnych wezwaniach powyższy podpis jest weryfikowany Jeżeli x jest rzeczywiście wektorem klucza prywatnego y to nie ma roacuteżnicy pomiędzy SIMNIZKP oraz rzeczywistym podpisemNa koniec mając krotność (G aG bG ciG) gdzie a b są losowo wybrany skalarami a c1 = ab c0 elementem losowym i ϵ 0 1 M zachodzi w poniższych krokach i pozwala rozwiązać problem decyzyjny Diffie Helmana za pomocą niepomijalnego prawdopodobieństwa M wychwytuje losowe ϒ lt-H z losowej wartości oracle oraz pobiera parę wektoroacutew klucza prywatnego publicznego (x y) a następnie oblicza s jako a = s + ϒx Teraz M wykonuje

SIMNIZKP za pomocą dowolnie wybranych wektoroacutew kluczy w taki sposoacuteb że w danej wiadomości m oraz Jeżeli prawdziwe jest że i = 1 to c = ab oraz logGaG = logbGcG = a

z uwagi na to że zakłada się iż A jest w stanie znaleźć π z prawdopodobieństwem ktoacuterego nie można pominąć to istnieje niepomijalne prawdopodobieństwo frac12 że A zwroacuteci 1 (i wtedy M zwroacuteci 1) Jeżeli i = 0 to A zwraca 1 wyłącznie z prawdopodobieństwem frac12 a zatem dla niektoacuterych niepomijanych prawdopodobieństw powyżej 1`2 M zwraca tę samą wartość co A i tym samym rozwiązuje problem decyzyjny Diffie-Helmana dla losowo wybranych skalaroacutew bez pomijalnego prawdopodobieństwa powyżej 12 co stanowi sprzeczność

Załącznik B Kod demo Ring CT W repozytorium w [14] zbudowałem prostą demonstrację protokołu poufnych transakcji pierścieniowych (Ring Confidential Transactions) wykorzystujących podpisy MLSAG w części 2 oraz podpisy ASNL w części 5

H_ct = RingCTgetHForCT()print(H H_ct)sr Pr = PaperWalletskpkGen() receivers private publicse pe ss = ecdhecdhgen(Pr) compute shared secret ssdigits = 14 in practice it will be 14print(inputs)Cia L1a s2a sa ska = RingCTgenRangeProof(10000 digits)print(outputs)Cib L1b s2b sb skb = RingCTgenRangeProof(7000 digits)Cic L1c s2c sc skc = RingCTgenRangeProof(3000 digits)print(verifying range proofs of outputs)RingCTverRangeProof(Cib L1b s2b sb)RingCTverRangeProof(Cic L1c s2c sc)x P1 = PaperWalletskpkGen()P2 = PaperWalletpkGen()C2 = PaperWalletpkGen()some random commitment grabbed from the blockchainind = 0Ca = RingCTsumCi(Cia)Cb = RingCTsumCi(Cib)Cc = RingCTsumCi(Cic)sk = [x MiniNerosc_sub_keys(ska MiniNerosc_add_keys(skb skc))]

pk = [[P1 P2] [MiniNerosubKeys(Ca MiniNeroaddKeys(Cb Cc)) MiniNerosubKeys(C2 MiniNeroaddKeys(Cb Cc)) ] ]II cc ssVal = MLSAGMLSAG_Sign(pk sk ind)print(Sig verified MLSAGMLSAG_Ver(pk II cc ssVal) )print(Finding received amount corresponding to Cib)RingCTComputeReceivedAmount(pe sr MiniNeroaddScalars(ss skb) Cib)print(Finding received amount corresponding to Cic)RingCTComputeReceivedAmount(pe sr MiniNeroaddScalars(ss skc) Cic)

Przykład transakcji z danymi wejściowymi 10 000 oraz wyjściowymi 3 000 i 7 000(rsquoHrsquo rsquo61fe7f0f5a607a33427d01dd1fded5ffa03fae2e9df9ebccf2e0a2f5bd77a204rsquo)inputs(rsquob b in binaryrsquo 10000 [0 0 0 0 1 0 0 0 1 1 1 0 0 1])Generating Aggregate Schnorr Non-linkable Podpis pierścieniowy outputs(rsquob b in binaryrsquo 7000 [0 0 0 1 1 0 1 0 1 1 0 1 1 0])Generating Aggregate Schnorr Non-linkable Podpis pierścieniowy (rsquob b in binaryrsquo 3000 [0 0 0 1 1 1 0 1 1 1 0 1 0 0])Generating Aggregate Schnorr Non-linkable Podpis pierścieniowy verifying range proofs of outputsVerifying Aggregate Schnorr Non-linkable Podpis pierścieniowy VerifiedVerifying Aggregate Schnorr Non-linkable Podpis pierścieniowy Verified(rsquoGenerating MLSAG sig of dimensions rsquo 2 rsquox rsquo 2)(rsquoverifying MLSAG sig of dimensions rsquo 2 rsquox rsquo 2)(rsquocrsquo[rsquo80a3cfd06dd2862307cd75c2a1566f20cd743dbb0b9feb22d79dcbecb9023f42rsquorsquoa9b7342ba7bf2f102505ca19dab734fde638916c0a29f5b30e49833ab51393earsquorsquo80a3cfd06dd2862307cd75c2a1566f20cd743dbb0b9feb22d79dcbecb9023f42rsquo])(rsquosig verifiesrsquo True)(rsquoSig verifiedrsquo True)Finding received amount corresponding to Cib(rsquoreceived rsquo 7000c Monero Research Lab Page 20 of 20rsquoa488ec68732fb551841c2c6dcc7ffac895d98ec7e9378275ed20ea12805fc18ersquo)Finding received amount corresponding to Cic(rsquoreceived rsquo3000rsquo1b46626858e130a0f3884c74c9fdeabc4d812c519103ea16a35a3f82a3d0ed6drsquo)

Należy podkreślić że w ostatnim punkcie kiedy i = π - 1 to ci+1 jest już określone w celu utrzymania spoacutejności z losowymi danymi wyjściowymi oracleNależy podkreślić że niezależnie od tego czy jest rzeczywistym kluczem prywatnym odpowiadającym ze względu na to że spoacutejność jest zachowywana przez losowe wartości oracle w kolejnych wezwaniach powyższy podpis jest weryfikowany Jeżeli x jest rzeczywiście wektorem klucza prywatnego y to nie ma roacuteżnicy pomiędzy SIMNIZKP oraz rzeczywistym podpisemNa koniec mając krotność (G aG bG ciG) gdzie a b są losowo wybrany skalarami a c1 = ab c0 elementem losowym i ϵ 0 1 M zachodzi w poniższych krokach i pozwala rozwiązać problem decyzyjny Diffie Helmana za pomocą niepomijalnego prawdopodobieństwa M wychwytuje losowe ϒ lt-H z losowej wartości oracle oraz pobiera parę wektoroacutew klucza prywatnego publicznego (x y) a następnie oblicza s jako a = s + ϒx Teraz M wykonuje

SIMNIZKP za pomocą dowolnie wybranych wektoroacutew kluczy w taki sposoacuteb że w danej wiadomości m oraz Jeżeli prawdziwe jest że i = 1 to c = ab oraz logGaG = logbGcG = a

z uwagi na to że zakłada się iż A jest w stanie znaleźć π z prawdopodobieństwem ktoacuterego nie można pominąć to istnieje niepomijalne prawdopodobieństwo frac12 że A zwroacuteci 1 (i wtedy M zwroacuteci 1) Jeżeli i = 0 to A zwraca 1 wyłącznie z prawdopodobieństwem frac12 a zatem dla niektoacuterych niepomijanych prawdopodobieństw powyżej 1`2 M zwraca tę samą wartość co A i tym samym rozwiązuje problem decyzyjny Diffie-Helmana dla losowo wybranych skalaroacutew bez pomijalnego prawdopodobieństwa powyżej 12 co stanowi sprzeczność

Załącznik B Kod demo Ring CT W repozytorium w [14] zbudowałem prostą demonstrację protokołu poufnych transakcji pierścieniowych (Ring Confidential Transactions) wykorzystujących podpisy MLSAG w części 2 oraz podpisy ASNL w części 5

H_ct = RingCTgetHForCT()print(H H_ct)sr Pr = PaperWalletskpkGen() receivers private publicse pe ss = ecdhecdhgen(Pr) compute shared secret ssdigits = 14 in practice it will be 14print(inputs)Cia L1a s2a sa ska = RingCTgenRangeProof(10000 digits)print(outputs)Cib L1b s2b sb skb = RingCTgenRangeProof(7000 digits)Cic L1c s2c sc skc = RingCTgenRangeProof(3000 digits)print(verifying range proofs of outputs)RingCTverRangeProof(Cib L1b s2b sb)RingCTverRangeProof(Cic L1c s2c sc)x P1 = PaperWalletskpkGen()P2 = PaperWalletpkGen()C2 = PaperWalletpkGen()some random commitment grabbed from the blockchainind = 0Ca = RingCTsumCi(Cia)Cb = RingCTsumCi(Cib)Cc = RingCTsumCi(Cic)sk = [x MiniNerosc_sub_keys(ska MiniNerosc_add_keys(skb skc))]

pk = [[P1 P2] [MiniNerosubKeys(Ca MiniNeroaddKeys(Cb Cc)) MiniNerosubKeys(C2 MiniNeroaddKeys(Cb Cc)) ] ]II cc ssVal = MLSAGMLSAG_Sign(pk sk ind)print(Sig verified MLSAGMLSAG_Ver(pk II cc ssVal) )print(Finding received amount corresponding to Cib)RingCTComputeReceivedAmount(pe sr MiniNeroaddScalars(ss skb) Cib)print(Finding received amount corresponding to Cic)RingCTComputeReceivedAmount(pe sr MiniNeroaddScalars(ss skc) Cic)

Przykład transakcji z danymi wejściowymi 10 000 oraz wyjściowymi 3 000 i 7 000(rsquoHrsquo rsquo61fe7f0f5a607a33427d01dd1fded5ffa03fae2e9df9ebccf2e0a2f5bd77a204rsquo)inputs(rsquob b in binaryrsquo 10000 [0 0 0 0 1 0 0 0 1 1 1 0 0 1])Generating Aggregate Schnorr Non-linkable Podpis pierścieniowy outputs(rsquob b in binaryrsquo 7000 [0 0 0 1 1 0 1 0 1 1 0 1 1 0])Generating Aggregate Schnorr Non-linkable Podpis pierścieniowy (rsquob b in binaryrsquo 3000 [0 0 0 1 1 1 0 1 1 1 0 1 0 0])Generating Aggregate Schnorr Non-linkable Podpis pierścieniowy verifying range proofs of outputsVerifying Aggregate Schnorr Non-linkable Podpis pierścieniowy VerifiedVerifying Aggregate Schnorr Non-linkable Podpis pierścieniowy Verified(rsquoGenerating MLSAG sig of dimensions rsquo 2 rsquox rsquo 2)(rsquoverifying MLSAG sig of dimensions rsquo 2 rsquox rsquo 2)(rsquocrsquo[rsquo80a3cfd06dd2862307cd75c2a1566f20cd743dbb0b9feb22d79dcbecb9023f42rsquorsquoa9b7342ba7bf2f102505ca19dab734fde638916c0a29f5b30e49833ab51393earsquorsquo80a3cfd06dd2862307cd75c2a1566f20cd743dbb0b9feb22d79dcbecb9023f42rsquo])(rsquosig verifiesrsquo True)(rsquoSig verifiedrsquo True)Finding received amount corresponding to Cib(rsquoreceived rsquo 7000c Monero Research Lab Page 20 of 20rsquoa488ec68732fb551841c2c6dcc7ffac895d98ec7e9378275ed20ea12805fc18ersquo)Finding received amount corresponding to Cic(rsquoreceived rsquo3000rsquo1b46626858e130a0f3884c74c9fdeabc4d812c519103ea16a35a3f82a3d0ed6drsquo)

pk = [[P1 P2] [MiniNerosubKeys(Ca MiniNeroaddKeys(Cb Cc)) MiniNerosubKeys(C2 MiniNeroaddKeys(Cb Cc)) ] ]II cc ssVal = MLSAGMLSAG_Sign(pk sk ind)print(Sig verified MLSAGMLSAG_Ver(pk II cc ssVal) )print(Finding received amount corresponding to Cib)RingCTComputeReceivedAmount(pe sr MiniNeroaddScalars(ss skb) Cib)print(Finding received amount corresponding to Cic)RingCTComputeReceivedAmount(pe sr MiniNeroaddScalars(ss skc) Cic)

Przykład transakcji z danymi wejściowymi 10 000 oraz wyjściowymi 3 000 i 7 000(rsquoHrsquo rsquo61fe7f0f5a607a33427d01dd1fded5ffa03fae2e9df9ebccf2e0a2f5bd77a204rsquo)inputs(rsquob b in binaryrsquo 10000 [0 0 0 0 1 0 0 0 1 1 1 0 0 1])Generating Aggregate Schnorr Non-linkable Podpis pierścieniowy outputs(rsquob b in binaryrsquo 7000 [0 0 0 1 1 0 1 0 1 1 0 1 1 0])Generating Aggregate Schnorr Non-linkable Podpis pierścieniowy (rsquob b in binaryrsquo 3000 [0 0 0 1 1 1 0 1 1 1 0 1 0 0])Generating Aggregate Schnorr Non-linkable Podpis pierścieniowy verifying range proofs of outputsVerifying Aggregate Schnorr Non-linkable Podpis pierścieniowy VerifiedVerifying Aggregate Schnorr Non-linkable Podpis pierścieniowy Verified(rsquoGenerating MLSAG sig of dimensions rsquo 2 rsquox rsquo 2)(rsquoverifying MLSAG sig of dimensions rsquo 2 rsquox rsquo 2)(rsquocrsquo[rsquo80a3cfd06dd2862307cd75c2a1566f20cd743dbb0b9feb22d79dcbecb9023f42rsquorsquoa9b7342ba7bf2f102505ca19dab734fde638916c0a29f5b30e49833ab51393earsquorsquo80a3cfd06dd2862307cd75c2a1566f20cd743dbb0b9feb22d79dcbecb9023f42rsquo])(rsquosig verifiesrsquo True)(rsquoSig verifiedrsquo True)Finding received amount corresponding to Cib(rsquoreceived rsquo 7000c Monero Research Lab Page 20 of 20rsquoa488ec68732fb551841c2c6dcc7ffac895d98ec7e9378275ed20ea12805fc18ersquo)Finding received amount corresponding to Cic(rsquoreceived rsquo3000rsquo1b46626858e130a0f3884c74c9fdeabc4d812c519103ea16a35a3f82a3d0ed6drsquo)