Kryptografia II stopień
Od definicji bezpieczeństwa do konstrukcji, redukcji i publikacji naukowych.
W8. Identyfikacja i granica chronionego urządzenia
Identyfikacja sprawdza, czy aktualny rozmówca posiada sekret. Trzeba wskazać, jakie wcześniejsze rozmowy przeciwnik obserwuje lub sam prowadzi. Pasywna obserwacja i aktywny trening są różnymi modelami.
Trzy błędne poprawki: poprawność zostaje, bezpieczeństwo znika
Punktem odniesienia jest Schnorr. Celowo zmienimy jego odpowiedź i odpowiednie równanie sprawdzające. Uczciwe wykonania nadal będą akceptowane. Dla każdego wariantu podamy jednak strategię oszusta, który nie zna sekretu. To przykłady z analizy protokołów, nie alternatywne bezpieczne konstrukcje.
1. Odpowiedź afiniczna. Zastąpmy odpowiedź przez , a weryfikację przez . Z obserwowanego przeciwnik wybiera własne i tworzy nowe zobowiązanie . Gdy otrzyma nowe wyzwanie , odpowiada:
Sprawdzenie przechodzi, bo . Przeciwnik nie znał ani . Wyeliminował stare wyzwanie i wstawił nowe. Pamięć poprzednich zobowiązań nie naprawia problemu, bo może być nowe.
MCL WebAssembly, BLS12-381. Punkty w , skalary w . Klucze wyłącznie testowe.
1. Pierwszy przebieg
Obserwacja uczciwej rozmowy.
Weryfikacja oczekuje.
2. Drugi przebieg
Ujawniony nonce z pierwszej rozmowy. Sekret nadal nie został odczytany z urządzenia.
Weryfikacja oczekuje.
3. Sprawdzenie podszycia
Strategia korzysta z publicznej rozmowy i własnej losowości.
Oszust nie otrzymuje ani , ani .
Odrzucenie tej strategii nie jest pełnym dowodem bezpieczeństwa Schnorra.
Wynik oczekuje.
Zapis i obliczenia. Wzory schematu są multiplikatywne. MCL realizuje je na krzywej. Generator odpowiada punktowi . W grupach punktów iloczyn oznacza dodawanie, potęga oznacza mnożenie punktu przez skalar, a odwrotność oznacza punkt przeciwny. Nie potęgujemy współrzędnych. Ten rachunek nie używa pairingu.
Gotowe do rozpoczęcia.
Pełne wartości transkryptów
Serializacja MCL w zapisie szesnastkowym. Skróty na schemacie wskazują te same wartości.
| Wartość | Serializacja |
|---|
2. Wyzwanie przed całym nawiasem. Niech , a weryfikacja sprawdza . Oszust losuje i przed wyzwaniem wysyła . Potem odpowiada . Nie potrzebował nawet wcześniejszego transkryptu. Ułożył znany sobie logarytm całej podstawy, którą weryfikator podniesie do wyzwania.
3. Brak związania z tożsamością. Dowodzący miał wysyłać , a weryfikator sprawdzać . Oszust po prostu wysyła dla własnego i odpowiada . Równanie niczego nie sprawdza względem klucza . Sam udział tajnego w uczciwym algorytmie nie zmusza oszusta do jego użycia.
W każdym przypadku atak jest chronologicznie wykonalny. Pierwsza wiadomość nie zależy od przyszłego wyzwania. To ważny test poprawności analizy: „rozwiązanie” wymagające wcześniejszego poznania świeżej losowej wartości weryfikatora nie jest atakiem w tym modelu.
Relay to jeszcze inny cel ochrony
Oszust może także przekazywać w czasie rzeczywistym zobowiązanie uczciwej osoby, wyzwanie weryfikatora i odpowiedź. Nie poznaje wtedy klucza. Zwykły eksperyment podszycia po zakończeniu treningu wyklucza taki bieżący dostęp do dowodzącego. Jeśli rzeczywisty scenariusz go dopuszcza, trzeba osobno zapewnić właściwe powiązanie kanału, czynności lub fizycznej odległości. Nie naprawia tego większa grupa algebraiczna.
Okamoto: inny świadek i inny punkt osadzenia
Ten sam interfejs identyfikacji, inna konstrukcja. Pozostają Setup, KeyGen oraz interaktywne i . Zmienia się postać sekretu, zobowiązania i odpowiedzi. Poniżej KeyGen tworzy parę skalarów. Commit używa dwóch świeżych skalarów, Respond zwraca parę odpowiedzi, a Check sprawdza jedno równanie. Oba generatory należą tutaj do tej samej grupy. To nie są grupy źródłowe pairingu.
W Schnorrze świadkiem jest jeden wykładnik. W Okamoto jest nim para wykładników reprezentująca publiczny element . Generatory należą do tej samej grupy pierwszego rzędu . Ich indeksy odróżniają bazy. Nie oznaczają grup źródłowych pairingu . Nie zakładamy znajomości logarytmu jednego generatora względem drugiego.
Identyfikacja Okamoto: algorytmy i przepływ
P i V są algorytmami interaktywnymi. Poniżej wydzielamy ich kroki oraz prywatny stan sesji. Każdy stan odpowiedzi jest jednorazowy. Niepoprawny komunikat kończy sesję odrzuceniem.
Dwa generatory tej samej grupy. Relacja logarytmiczna między nimi nie jest udostępniana.
Powtórz losowanie, jeżeli A jest neutralny.
Sprawdź wyzwanie i zużyj oba nonce.
Walidacja typów i zakresów poprzedza równanie.
Identyfikacja Okamoto
Dowodzący:
Weryfikator:
- Dowodzący, Commit:
- Dowodzący → Weryfikator: Jedno zobowiązanie
- Weryfikator, Challenge:
- Weryfikator → Dowodzący: Jedno wyzwanie
- Dowodzący, Respond:
- Dowodzący → Weryfikator: Dwie odpowiedzi skalarne
- Weryfikator, Check:
- Klucz: losujemy parę i publikujemy , odrzucając .
- Zobowiązanie: dla nowej rozmowy losujemy niezależne i wysyłamy .
- Wyzwanie: weryfikator losuje po otrzymaniu .
- Odpowiedź: dowodzący wysyła dwa skalary , .
Sprawdzenie ponownie opiera się na mnożeniu potęg:
Przejście do krzywej: oznaczmy te dwie bazy przez . Wtedy , , a kontrola ma postać . Odpowiedzi nadal są skalarami. Klasyczny Okamoto nie wymaga pairingu. Pairing pojawia się dopiero w osobno opisanej modyfikacji.
Ekstrakcja pary daje reprezentację. Aby zredukować atak do DL jednego generatora względem drugiego, trzeba porównać ją z reprezentacją zaszytą przez redukcję. Dwa równania same nie kończą tego dowodu.
Pełny dowód: aktywne sesje, nierozróżnialność świadków i rewinding. Zobacz, dlaczego redukcja zna jedną reprezentację, a potrzebuje drugiej, oraz skąd biorą się wszystkie czynniki w prawdopodobieństwie sukcesu.
Ujawnienie, ustawienie i reset
- Ujawnienie: przeciwnik poznaje . Przy odzyskuje .
- Ustawienie: narzuca znane . Rachunek jest ten sam, lecz interfejs ataku inny.
- Reset: niekoniecznie znany nonce powtarza się. Dwie odpowiedzi eliminują go przez odejmowanie.
To wspólna algebra liniowa, ale różne uprawnienia. Przy resecie nonce może pozostać nieznany. Wystarczy jego powtórzenie. Przy ustawieniu przeciwnik zna narzuconą wartość. Przy ujawnieniu poznaje wartość wybraną przez urządzenie. Model powinien wskazać moment udostępnienia, możliwość wyboru wiadomości i liczbę przebiegów.
Rozszerzenie modelu może wymusić zmianę architektury. Jeżeli celem jest ochrona tożsamości mimo wycieku nonce, klasyczna skalarna odpowiedź Schnorra nie spełnia tego celu. Samo ponowne sformułowanie dowodu tego nie zmieni. Trzeba zmienić konstrukcję, ograniczyć interfejs urządzenia lub inaczej rozdzielić sekrety. Jeżeli przeciwnik dostaje cały klucz długoterminowy, model odporności tylko na nonce przestaje być właściwym opisem.
Odpowiedź jako element grupy
Cel modyfikacji: zachować trzy wiadomości identyfikacji, ale nie wydawać skalarnej odpowiedzi, z której przy znanym nonce można wyliczyć klucz. Odpowiedź będzie elementem grupy, a kontrola użyje pairingu. To zmiana konstrukcji i modelu urządzenia, nie tylko sposobu zapisu.
Schnorr z odpowiedzią grupową: algorytmy i przepływ
Profil dydaktyczny tej modyfikacji zachowuje trzy komunikaty, ale skalar odpowiedzi zastępuje elementem . Grupy źródłowe i mają ten sam pierwszy rząd q. Granice modelu urządzenia wyjaśniamy po diagramie. Równanie weryfikacji nie zastępuje dowodu bezpieczeństwa.
Nie wydawaj skalaru odpowiedzi. Zużyj stan sesji.
Najpierw walidacja punktów i zakresu c.
Schnorr z odpowiedzią grupową
Dowodzący:
Weryfikator:
- Dowodzący, Commit:
- Dowodzący → Weryfikator: Zobowiązanie w grupie źródłowej
- Weryfikator, Challenge:
- Weryfikator → Dowodzący: Wyzwanie skalarne
- Dowodzący, Respond:
- Dowodzący → Weryfikator: Odpowiedź grupowa, nie skalar
- Weryfikator, Check: Odtwórz B z tego samego kodowania.
Najpierw zachowajmy notację potęgową. Niech , i . Hash daje element . Zamiast ujawniać skalar , wysyłamy jego obraz:
Lewą stronę równania można przepisać jako . Prawa strona jest tym samym elementem przez dwuliniowość. Chroniona operacja zwraca , a część robocza łączy ten wynik z własnym . Nie potrzebuje do tego odczytu . To opis rachunku przy założonym podziale urządzenia, nie dowód bezpieczeństwa tego podziału.
Realizacja na krzywej: zapis addytywny tej samej konstrukcji. Rysunek zachowuje powyższe potęgi. Poniższe równanie wyjaśnia operacje wykonywane przez MCL:
Niech , , i . Wyznaczamy oraz . Sprawdzamy:
Przy znanym i można obliczyć punkt , ale nie otrzymuje się wprost . Znaczenie punktu zależy od powiązania bazy z kontekstem i modelu zapytań. Ta obserwacja nie dowodzi odporności na wszystkie wycieki.
Dydaktyczny podział obliczeń. Obie części wykonują się w tej samej przeglądarce. To nie jest izolacja HSM.
Zapis i obliczenia. Wzory schematu są multiplikatywne. MCL realizuje je na krzywej. Generator odpowiada punktowi . W grupach punktów iloczyn oznacza dodawanie, potęga oznacza mnożenie punktu przez skalar, a odwrotność oznacza punkt przeciwny. Nie potęgujemy współrzędnych. Ten schemat używa również pairingu. W grupie docelowej zapis pozostaje multiplikatywny.
Gotowe do rozpoczęcia.
Granica zaufania: moduł przechowuje i zwraca . Zwykły kod liczy . W realizacji na krzywej są to odpowiednio i . To dydaktyczne rozłożenie równania i założony interfejs urządzenia, nie fizyczny HSM w przeglądarce. Ujawnienie łamie założenie. Inne użycia sekretu, np. w AKE, wymagają osobnej analizy.
W8a. Identyfikacja, transkrypt i zaprzeczalność
Identyfikacja ma przekonać rozmówcę teraz. Podpis ma dać dokument sprawdzalny również później i przez inne osoby. Nie są to zamienne cele. Pytamy więc nie tylko, czy weryfikacja przyjmuje, ale także, kto mógł wytworzyć jej zapis i komu ten zapis coś udowadnia.
Przyjmijmy grupę rzędu , gdzie jest liczbą pierwszą, generator , sekret i uwierzytelniony klucz publiczny . Opis i diagramy zachowują ten zapis potęgowy. Operacje na skalarach wykonujemy w . W tym rozdziale zwraca skalar. Osobny skrót zwraca bitów i haszuje kanoniczny zapis elementu grupy, a nie mapuje do grupy.
Schnorr: kolejność, która oddziela symulację od ataku
Weryfikator nie wybiera pierwszego komunikatu. Najpierw dowodzący ustala zobowiązanie, dopiero potem otrzymuje wyzwanie:
- Dowodzący losuje i wysyła .
- Weryfikator losuje i wysyła .
- Dowodzący odsyła . Weryfikator sprawdza .
Uczciwy transkrypt da się wygenerować bez . Symulator losuje niezależnie i oblicza . Równanie weryfikacji zachodzi z definicji. Dla każdego ustalonego przekształcenie jest bijekcją. Dlatego symulowane trójki mają dokładnie taki rozkład jak trójki z uczciwej rozmowy. To argument honest-verifier zero knowledge, czyli wiedzy zerowej względem uczciwego weryfikatora.
Nie oznacza to jednak umiejętności podszycia się w czasie rzeczywistym. Symulator konstruuje zobowiązanie po wyborze wyzwania i odpowiedzi. Atakujący w protokole musi wysłać zobowiązanie przed poznaniem wyzwania. Gdybyśmy odwrócili te dwa komunikaty bez innych zmian, symulator stałby się rzeczywistym algorytmem podszycia. Ten błąd porównaj z atakami na identyfikację.
Stinson–Wu: dlaczego weryfikator może zacząć
Wariant Stinsona–Wu z wcześniejszych wykładów nie polega na przestawieniu strzałek Schnorra. Pierwszy komunikat zawiera element grupy Diffiego–Hellmana i skrót oczekiwanej odpowiedzi. Weryfikator zna tę odpowiedź jeszcze przed rozmową, ale osoba podsłuchująca nie zna jego wykładnika.
Identyfikacja Stinsona–Wu: algorytmy i przepływ
Omawiany profil protokołu 2.2 używa niezerowych sekretów. P odpowiada na wyzwanie, a V rozpoczyna rozmowę. Nazwy Challenge, Respond i Check wydzielają kroki tych dwóch maszyn.
Skrót otrzymuje kanoniczne kodowanie elementu grupy.
Sekret a pozostaje u właściciela. Odbiorca uwierzytelnia publiczny A.
Najpierw sprawdź zaufany klucz A. Zachowaj T prywatnie.
Sprawdź C w właściwej podgrupie i odrzuć element neutralny. Przy błędnym h nie wysyłaj Z.
Sprawdź poprawność otrzymanego elementu i porównaj z zapamiętanym T.
Identyfikacja Stinsona–Wu
Dowodzący:
Weryfikator:
- Weryfikator, Challenge: T i r pozostają po prawej stronie.
- Weryfikator → Dowodzący: Weryfikator rozpoczyna
- Dowodzący, Respond: kontrola przed odpowiedzią: Błędny punkt lub skrót: przerwij bez Z.
- Dowodzący → Weryfikator: Tylko po poprawnej kontroli
- Weryfikator, Check: Porównaj z własnym oczekiwanym wynikiem.
- Weryfikator losuje tajne , oblicza i , po czym wysyła parę .
- Dowodzący sprawdza poprawność punktu i oblicza . Najpierw sprawdza . Przy niezgodności przerywa bez wysyłania .
- Przy zgodności dowodzący odsyła . Weryfikator akceptuje wtedy i tylko wtedy, gdy .
W grupie krzywej jest to dokładnie oraz . Nie potrzebujemy pairingu. Dwa komunikaty nie oznaczają dwóch prostych operacji, bo przed odpowiedzią trzeba wykonać kontrolę skrótu. Pominięcie kontroli oddawałoby przeciwnikowi usługę obliczania dla dowolnego podanego .
To operacyjny wariant z protokołu 2.2 Stinsona–Wu. Używamy niezerowych sekretów i niejednostkowych punktów, zgodnie z przykładem ze slajdów. W oryginalnym opisie jest losowane z całego . Przy porównywaniu rozkładów symulatora i protokołu trzeba zachować tę samą dziedzinę losowania. Implementacja odbierająca cudze punkty musi sprawdzić ich przynależność do właściwej podgrupy przed mnożeniem przez sekret. Demonstrator wytwarza wszystkie punkty lokalnie z generatora tej podgrupy. Nie implementuje przyjmowania komunikatów z sieci.
Zaprzeczalność: symulator bez klucza tajnego
„Weryfikator może sam wygenerować całość” oznacza istnienie konkretnego algorytmu. Nazywamy go symulatorem, czyli generatorem zapisu rozmowy, który nie potrzebuje udziału dowodzącego. Nie wystarczy, że zapis spełnia równania weryfikacji. Musi także mieć odpowiedni rozkład, aby obserwator nie mógł odróżnić go od prawdziwego zapisu. Tutaj uzyskamy dokładnie ten sam rozkład.
Wejście publiczne: parametry oraz poprawny, niejednostkowy klucz . Sekret niebędący wejściem: wykładnik , dla którego . Wyjście: transkrypt , czyli uporządkowany zapis dwóch komunikatów:
Symulator jest efektywnym algorytmem probabilistycznym. Ma własną losowość, ale nie dostaje cudzego sekretu ani dostępu do urządzenia dowodzącego. Losowany przez niego nie jest odzyskanym sekretem rzeczywistej sesji. Jest nową, niezależną wartością, która służy do zbudowania nowego zapisu. Tak jak w omawianym profilu protokołu, losowanie jest jednostajne z .
Symulator transkryptu Stinsona–Wu: algorytmy i przepływ
Sim generuje zapis, a nie prowadzi rozmowy z posiadaczem sekretu. Zakładamy poprawne parametry i klucz A. Własna losowość r pozostaje wewnątrz algorytmu.
Wejście nie zawiera a. Nie wywołujemy Respond i nie kontaktujemy się z dowodzącym.
Symulator transkryptu Stinsona–Wu
Symulator:
Obserwator zapisu:
- Symulator, Sim: wylosuj własny wykładnik: Ta sama dziedzina co w protokole.
- Symulator, Sim: wylicz oba punkty: Publiczny A wystarcza. Nie znamy a.
- Symulator, Sim: dołącz skrót: Oba komunikaty powstały lokalnie.
- Symulator → Obserwator zapisu: Przekazanie gotowego zapisu
- Obserwator zapisu, Widok osoby trzeciej: Brak informacji o pochodzeniu zapisu.
Dlaczego nie da się rozpoznać pochodzenia zapisu
Ustalmy poprawne oraz odpowiadający sekret . Niech oznacza transkrypt pełnej, uczciwej rozmowy z poprzedniego diagramu. W tym eksperymencie dowodzący rzeczywiście używa . Natomiast oznacza wynik algorytmu powyżej. Porównujemy rozkłady wyników, nie zakładamy, że dwa niezależne uruchomienia dadzą identyczne bajty.
Dowód w trzech krokach:
- W obu eksperymentach jest losowane jednostajnie z tego samego zbioru . Możemy więc porównać wyniki dla każdego ustalonego .
- Pierwszy punkt jest w obu przypadkach równy . Odpowiedź prawdziwego dowodzącego oraz odpowiedź utworzona przez symulator są równe:
- Ta sama funkcja zastosowana do tego samego elementu daje ten sam . Dla każdego otrzymujemy więc ten sam transkrypt, z tym samym prawdopodobieństwem. Stąd:
Symbol oznacza tutaj równość rozkładów. Formalnie, dla dowolnego testu , który otrzymuje tylko i zwraca bit, zachodzi:
Prawdopodobieństwa obejmują losowość tworzenia transkryptu i ewentualną losowość testu. To równość dokładna, a nie tylko nierozróżnialność dla testów o ograniczonym czasie działania. Ten konkretny argument nie wymaga trudności logarytmu dyskretnego ani modelu wyroczni losowej. Wynika z równości grupowej i identycznego sposobu losowania. Założenia bezpieczeństwa są potrzebne do innych twierdzeń, w szczególności do analizy podszywania.
Co to daje dla zaprzeczalności
Sam transkrypt uczciwej rozmowy nie jest przenośnym dowodem udziału właściciela klucza. Weryfikator mógł stworzyć taki zapis bez niego. Osoba trzecia, która zna tylko dane publiczne i ten zapis, nie ma testu pozwalającego ustalić jego pochodzenie. To właśnie uzasadnienie zaprzeczalności takiego transkryptu. Nie twierdzimy, że symulator usuwa nagrania, poświadczenia urządzenia lub inne dowody pochodzące spoza protokołu.
Nie jest to algorytm podszywania się w żywej rozmowie. Symulator sam wybiera , więc może obliczyć . Atakujący, który otrzymał od uczciwego weryfikatora cudze , nie może zastąpić go własnym wyzwaniem. Musi odpowiedzieć dla otrzymanego , nie znając ani , ani wykładnika tego wyzwania. Równość rozkładów nie daje mu takiej umiejętności. Zaprzeczalność zapisu i odporność na podszywanie odpowiadają na różne pytania.
Zakres argumentu: porównaliśmy pełne, uczciwe rozmowy. Dla złośliwego weryfikatora trzeba zdefiniować jego cały widok, obejmujący również własny stan, i zbudować odpowiedni symulator. To mocniejsze wymaganie. W analizie Stinsona–Wu pełniejszy wynik o wiedzy zerowej korzysta z modelu wyroczni losowej i założenia wiedzy o wykładniku, KEA. Analiza podszywania wykorzystuje również CDH. Nie wyprowadzamy tych twierdzeń wyłącznie z powyższej równości. Poprawny skrót nie jest też bezwarunkowym dowodem znajomości przez nadawcę, bo całe wyzwanie można przekopiować.
- KEA
- knowledge-of-exponent assumption. Założenie wiedzy wykładnika.
W demonstratorze MCL poniżej weryfikator liczy oczekiwaną odpowiedź bez sekretu , a dowodzący oblicza . Na rysunku zachowujemy potęgi. Realizacja na krzywej wykonuje odpowiednio i . Porównanie wyników pokazuje krok algebraiczny dowodu. Sam test numeryczny nie zastępuje argumentu o całym rozkładzie.
Fiat–Shamir zmienia rolę wyzwania
W Schnorrze zamiast niezależnego możemy związać wyzwanie z wiadomością , kluczem, zobowiązaniem i opisem grupy. Dla i zapisujemy najpierw:
Odbiorca wylicza hasz ponownie i sprawdza . W addytywnym profilu demonstratora reprezentuje punkt , i . Hasz otrzymuje kanoniczne kodowania tych punktów:
Teraz odbiorca podpisu sam odtwarza . Trójka wygenerowana przez zwykły symulator Schnorra spełnia równanie grupowe, ale jej niezależnie wylosowane zazwyczaj nie jest haszem otrzymanego . W idealnym modelu przy niezależnym świeżym zapytaniu szansa zgodności wynosi . Tak powstaje istotna różnica między symulacją rozmowy a podrobieniem podpisu.
Złośliwy interaktywny weryfikator może wybrać wyzwanie właśnie jako taki hasz. Jeżeli kodowania, klucze i dziedziny protokołów na to pozwalają, otrzyma odpowiedź o postaci podpisu. Dlatego samo HVZK nie uzasadnia zaprzeczalności wobec dowolnego weryfikatora. Programowanie wyroczni losowej w dowodzie Fiata–Shamira nie daje zwykłemu użytkownikowi możliwości zmieniania rzeczywistej funkcji haszującej.
Stinson–Wu nie jest protokołem public-coin o tej samej strukturze. Naiwne ustalenie nie tworzy analogicznego podpisu. Upublicznia , więc każdy może obliczyć i wygenerować odpowiedź. Sekret weryfikatora jest tu częścią mechanizmu, a nie zbędnym źródłem losowości.
| Pytanie | Schnorr | Stinson–Wu, omawiany wariant |
|---|---|---|
| Kto zaczyna? | Dowodzący ustala . | Weryfikator wysyła . |
| Co jest wyzwaniem? | Jawny skalar , nieznany przy wyborze . | Punkt i skrót . Skalar pozostaje tajny. |
| Jak symulujemy uczciwy zapis? | Wybieramy , potem obliczamy . | Wybieramy , potem obliczamy całą rozmowę z publicznego . |
| Dlaczego istnieje test przed odpowiedzią? | Bezpieczeństwo zależy m.in. od kolejności zobowiązania i wyzwania. | Kontrola ogranicza wydawanie potęg . |
| Co daje znana losowość weryfikatora? | Znajomość po ustaleniu jest normalna. Poznanie go wcześniej zmienia sytuację. | Ujawnienie pozwala podszyć się przez obliczenie , bez odzyskania . |
| Czy wystarczy zwykłe podstawienie Fiata–Shamira? | Jest podstawą konstrukcji podpisu, z osobną analizą bezpieczeństwa. | Nie. Jawne pozwala wytworzyć odpowiedź każdemu. |
MCL WebAssembly · BLS12-381. W obliczeniach . Wszystkie klucze są testowe.
Schnorr · trzy komunikaty
Sprawdzenie oczekuje.
Stinson–Wu · dwa komunikaty
Sprawdzenie oczekuje.
Co można stworzyć bez dowodzącego?
Symulator Schnorra dostaje tylko parametry i klucz publiczny.
Symulacja oczekuje.
Weryfikator Stinsona–Wu zna oczekiwaną odpowiedź jeszcze przed rozmową.
Porównanie oczekuje.
Zapis i obliczenia. Wzory schematu są multiplikatywne. MCL realizuje je na krzywej. Generator odpowiada punktowi . W grupach punktów iloczyn oznacza dodawanie, potęga oznacza mnożenie punktu przez skalar, a odwrotność oznacza punkt przeciwny. Nie potęgujemy współrzędnych. Ten rachunek nie używa pairingu.
Gotowe do rozpoczęcia.
Pełne wartości obliczeń
Serializacje MCL i skróty SHA-256. Dane powstają lokalnie. Skróty widoczne na rysunku nie są dodatkowymi operacjami protokołu.
| Wartość | Pełny zapis |
|---|
Wspólna granica: żaden z tych przepływów sam nie mierzy odległości ani nie uniemożliwia przezroczystego przekazywania komunikatów. Ochrona przed relay, ujawnieniem stanu i błędnymi punktami wymaga jawnego modelu. Pytaj kolejno: co przyjmuje weryfikator, kto może stworzyć zapis, kto może odpowiedzieć na bieżąco i co wolno ujawnić?
Powiązania: zadania o zaprzeczalności, laboratorium porównawcze, dowód transformaty. Źródła: Schnorr, Fiat–Shamir, Stinson–Wu.