Kryptografia II stopień

W9. Podpisy, Fiat–Shamir i BLS

Nowa potrzeba: odbiorca nie uczestniczy w rozmowie w chwili tworzenia dokumentu. Chcemy zostawić wiadomość i obiekt, który sprawdzi później. Dlatego zastępujemy żywą rozmowę dwoma lokalnymi algorytmami: Sign u autora oraz Verify u odbiorcy. Weryfikacja nie wymaga ponownego połączenia z autorem.

Podpis nie jest zapisem dowolnej udanej identyfikacji. Taki zapis uczciwego Schnorra potrafi stworzyć poznany symulator. Potrzebujemy dodatkowego związania wyzwania z wiadomością. Pokaże je transformata Fiata–Shamira. Podpisy cyfrowe jako ogólna rodzina nie są z definicji nieinteraktywnymi dowodami z wiedzą zerową. W Schnorrze wykorzystujemy związek z dowodem znajomości sekretu i analizą w modelu wyroczni losowej. Własność podpisu, którą musimy następnie udowodnić, to niepodrabialność. W odróżnieniu od symulowalnego zapisu identyfikacji podpis jest przeznaczony do publicznego przekazywania i sprawdzania.

Podpis umożliwia publiczną weryfikację wiadomości. W EUF-CMA przeciwnik może uzyskać podpisy wybranych wiadomości, a wygrywa przez podpis nowej. Silna niepodrabialność dodatkowo wyklucza nowy podpis wiadomości już podpisanej.

Rozwinięcie skrótu EUF-CMA to existential unforgeability under chosen-message attack. „Egzystencjalne” oznacza, że wystarczy dowolna nowa wiadomość spełniająca warunek gry. Atak nie musi podrabiać konkretnego dokumentu wybranego przez audytora. „Wybrane wiadomości” oznaczają dostęp do podpisywania przed zakończeniem ataku. Weryfikacja podpisu jest publiczna, więc nie musimy ukrywać jej za tajną wyrocznią.

Podpis cyfrowy: Setup, KeyGen, Sign, Verify

Wracamy do kontraktu wprowadzonego na początku. Sign korzysta z klucza tajnego, a Verify z właściwego klucza publicznego. Wymaganie, aby przeciwnik nie tworzył nowych akceptowanych podpisów, jest osobną definicją niepodrabialności. Schemat zapisujemy jako:

Sign znaczy podpisz, a Verify sprawdź. W tym kursie opisujemy podpis z dołączoną wiadomością: weryfikator otrzymuje zarówno $m$, jak i $\sigma$. Nie odzyskuje dokumentu z samego podpisu. W ogólnym interfejsie zakładamy, że Sign może wyznaczyć odpowiadający klucz publiczny z klucza tajnego i parametrów. Tam, gdzie potrzebne są dodatkowe jawne dane, zaznaczamy je w opisie konkretnego klucza.

Przy doskonałej poprawności dla każdych parametrów i pasującej pary kluczy zwracanych przez Setup oraz KeyGen wymagamy:

Prawdopodobieństwo w tym wzorze dotyczy losowości Sign przy ustalonych parametrach, kluczach i wiadomości. Sign może być losowy, jak w omawianym Schnorrze, albo deterministyczny, jak w podstawowym BLS przy ustalonym haszu. Verify jest tutaj deterministyczny. Niepodrabialność będzie mówiła o tworzeniu nowych akceptowanych podpisów przez przeciwnika. Nie wynika z samego równania poprawności.

Gdzie wykonuje się Sign

Użytkownik przekazuje urządzeniu dokładne bajty $m$. Urządzenie odnajduje uprawniony klucz $sk$ i uruchamia $\sigma\leftarrow\mathsf{Sign}(pp,sk,m)$. Na zewnątrz zwraca podpis. To, że algorytm ma klucz wśród argumentów, nie oznacza wysyłania klucza do odbiorcy ani konieczności przekazywania go przy każdym wywołaniu przez aplikację. W API urządzenia aplikacja może podawać identyfikator klucza przechowywanego wewnątrz.

Do sprawdzenia potrzebne są $pp,pk,m,\sigma$. Jeśli odbiorca nie ma wiarygodnego powiązania $pk$ z autorem, poprawne Verify potwierdza zgodność podpisu z tym kluczem, ale nie nazwisko autora. Ustalenie tego powiązania, kontrola uprawnień i ochrona urządzenia są częścią systemu otaczającego schemat.

Podpis Schnorra

Z rozmowy identyfikacyjnej przechodzimy do schematu $\Pi_{\mathrm{Sch}}=(\mathsf{Setup},\mathsf{KeyGen},\mathsf{Sign},\mathsf{Verify})$. W tym dydaktycznym profilu podpis ma postać pary $\sigma=(X,s)$. Element $X$ jest zobowiązaniem, a skalar $s$ odpowiedzią. Wiadomość $m$ dostarczamy do Verify oddzielnie.

Setup: grupa i hasz Schnorra

Wejście: $1^\lambda$. Wyjście: $pp=(G,q,g,\mathcal H,\operatorname{enc})$. Grupa $G$ ma pierwszy rząd $q$ i generator $g$. Funkcja $\mathcal H:\{0,1\}^*\to\mathbb Z_q$ zwraca skalar. Kodowanie $\operatorname{enc}$ jednoznacznie zapisuje typy i granice pól. Ustalamy także separator domeny $\mathtt{Schnorr}$. Parametry i oznaczenie profilu są wspólne dla podpisującego oraz weryfikatora. Późniejszy dowód analizuje $\mathcal H$ w modelu wyroczni losowej.

KeyGen: klucze podpisującego

Wejście: $pp$. Losujemy $a\overset{\$}{\leftarrow}\mathbb Z_q$ i obliczamy $A=g^a$. Wyjście: $(pk,sk)=(A,a)$. Małe $a$ jest tajnym skalarem, a duże $A$ publicznym elementem grupy. To te same role co w protokole identyfikacji, ale inny interfejs niż w szyfrowaniu. Sign używa $a$, a Verify używa $A$.

Sign: tworzenie podpisu

Wejście: $pp$, klucz tajny $a$ i wiadomość $m\in\{0,1\}^*$. Algorytm wyznacza odpowiadający klucz publiczny $A=g^a$. Następnie:

1. Losuje świeże $u\overset{\$}{\leftarrow}\mathbb Z_q$ i oblicza $X=g^u$.
2. Oblicza $c=\mathcal H(\operatorname{enc}(\mathtt{Schnorr},A,X,m))$.
3. Oblicza $s=u+c\cdot a\bmod q$.
4. Zwraca $\sigma=(X,s)\in G\times\mathbb Z_q$.

Skalar $u$ nie jest częścią podpisu i nie może być ponownie używany w innym podpisywaniu. Wartość $c$ będzie odtworzona z jawnych danych, więc w tym formacie nie trzeba jej przesyłać.

Verify: sprawdzanie podpisu

Wejście: $pp$, klucz publiczny $A$, wiadomość $m$ i podpis $\sigma$. Sprawdzamy jednoznaczny format oraz typy $A,X\in G$ i $s\in\mathbb Z_q$. Błędne wejście daje 0. Dla poprawnego formatu obliczamy ponownie $c$ z tych samych czterech argumentów i zwracamy:

Algorytm nie otrzymuje $a$ ani $u$. Nie ufa wartości $c$ podanej przez inną stronę.

Poprawność i przejście z identyfikacji

Dla podpisu zwróconego przez Sign zachodzi:

To dowód poprawności. Niepodrabialność wymaga osobnego dowodu z symulacją i forking lemma. Zgodnie z tym opisem losujemy z $\mathbb Z_q$. Klucz $a=0$ jest degeneracją o prawdopodobieństwie $1/q$. Profil odrzucający taki klucz musi jawnie zmienić regułę KeyGen, nie samo równanie Verify.

Weryfikator nie wysyła już losowego wyzwania. Sam wylicza je z klucza, zobowiązania i wiadomości. Podpisujący musi więc najpierw ustalić zobowiązanie, następnie policzyć hasz, a dopiero potem odpowiedź. Dziedzina oznaczona napisem Schnorr rozdziela to zastosowanie od innych protokołów korzystających z podobnych obiektów.

Dwa formaty tego samego podpisu

W powyższym formacie przesyłamy $(X,s)$, a weryfikator oblicza $c$. Można zamiast tego przesłać $(s,c)$ i odzyskać zobowiązanie. Klucz publiczny nadal wynosi $A=g^a$. Dla tego samego kodowania i tej samej etykiety domeny weryfikator wykonuje:

Nawias kwadratowy oznacza bit wyniku porównania. Przed tym rachunkiem sprawdzamy parametry, dozwoloną podgrupę klucza oraz kanoniczne kodowanie skalarów $s,c\in\{0,\ldots,q-1\}$. Stosujemy te same reguły dopuszczalności klucza i zobowiązania co w wybranym profilu Sign. Nie wystarczy obliczyć $X'$ i ogłosić sukcesu. Dla dowolnych skalarów da się obliczyć jakiś element grupy. Dopiero ponowne obliczenie hasza i porównanie $c'=c$ wiąże wynik z wiadomością.

W realizacji addytywnej $A=a\cdot P$ i $X'=s\cdot P-c\cdot A$. Przy uczciwym podpisie odtwarzamy dokładnie pierwotne $X$, więc oba formaty prowadzą do tego samego wejścia hasza. Zadania C6.6 i L4.7 pozwalają porównać liczbę przesyłanych bajtów i działania Verify. Zmiana formatu nie jest nową gwarancją bezpieczeństwa i nie uzasadnia zmiany dziedziny hasza między implementacjami.

Ataki na błędne warianty hasza

Pominięcie zobowiązania.

Celowo błędny wariant wylicza $c=\mathcal H(m)$, pomijając $X$. Przeciwnik zna wtedy $c$ przed ustaleniem zobowiązania. Wybiera dowolne $s$ i oblicza:

Oddaje $(X,s)$. Weryfikacja przechodzi dla wiadomości $m$. Nie znalazł kolizji hasza i nie poznał klucza. Konstrukcja pozwoliła mu rozwiązać równanie w niewłaściwej kolejności. Powrót do związania zobowiązania zamyka tę prostą strategię, ale pełny dowód nadal wymaga symulacji zapytań i argumentu forking.

„Hasz” o zbyt prostej algebrze.

Rozważmy inną, jawnie błędną funkcję $\mathcal H_{\mathrm{bad}}(X,m)=\operatorname{enc}(X)+m\bmod q$, gdzie wiadomości są skalarami, a kodowanie publiczne. Z podpisu $(X_0,s_0)$ wiadomości $m_0$ przeciwnik wybiera $r$ i tworzy:

Nowe wyzwanie jest równe poprzedniemu, więc równanie podpisu nadal zachodzi. Aby spełnić warunek nowej wiadomości, trzeba uzyskać $m_1\ne m_0$. Atak pokazuje znaczenie struktury funkcji, nie ogólną wadę dodawania w ciele. W poprawnym podpisie używamy właściwej funkcji z właściwym modelem, a nie dowolnego kodowania nazwanego haszem.

Zbyt krótkie wyzwanie.

Jeśli wyzwanie ma tylko $h$ możliwych wartości, oszust może zgadywać $c$, wybierać $s$, tworzyć $X=g^s\cdot A^{-c}$ i sprawdzać, czy hasz zwrócił zgadnięte $c$. Dla świeżych wejść w idealnym modelu prawdopodobieństwo trafienia wynosi $1/h$ na próbę. Mała przestrzeń wyzwań osłabia podpis niezależnie od rozmiaru grupy.

To nie ten sam rachunek co poszukiwanie dowolnej kolizji hasza z kosztem urodzinowym. Tutaj trzeba trafić określoną wartość po ustaleniu związanej z nią reszty danych. Zanim użyjesz pierwiastka z rozmiaru przestrzeni, nazwij dokładnie zdarzenie, którego szukasz.

Hash wiąże wiadomość, klucz i zobowiązanie. Model wyroczni losowej idealizuje hash. Redukcja może programować odpowiedzi pod warunkami tego modelu. Implementacja nie ma programowalnego SHA.

Forking lemma służy otrzymaniu drugiego kompatybilnego wykonania ze zmienionym wyzwaniem. Nie gwarantuje sukcesu. Symulację i straty wyprowadzamy w pogłębieniu dowodowym.

Podpis BLS

W BLS podpis jest jednym elementem grupy, zamiast pary zobowiązanie–odpowiedź. Nadal mamy ten sam ogólny interfejs $\Pi_{\mathrm{BLS}}=(\mathsf{Setup},\mathsf{KeyGen},\mathsf{Sign},\mathsf{Verify})$. Zmieniają się typ podpisu i sposób sprawdzania. Poniżej opisujemy pojedynczy podpis, nie agregację podpisów.

Setup: grupy i hash do punktu

Wejście: $1^\lambda$. Wyjście: $pp=(q,G_1,G_2,G_T,e,g_2,\mathcal H_{G_1})$ wraz z kodowaniami i separatorem domeny hasza. Grupy mają ten sam pierwszy rząd $q$. Pairing $e:G_1\times G_2\to G_T$ jest biliniowy i niezdegenerowany, a $g_2$ generuje $G_2$. Funkcja $\mathcal H_{G_1}:\{0,1\}^*\to G_1$ poprawnie haszuje wiadomość do grupy, w uzgodnionym profilu haszowania. Nie jest jawnym kodowaniem do skalaru pomnożonego przez stałą bazę.

KeyGen: sekret i klucz w drugiej grupie

Wejście: $pp$. Losujemy niezerowe $a\overset{\$}{\leftarrow}\mathbb Z_q^*$ i obliczamy $A_2=g_2^a$. Wyjście: $(pk,sk)=(A_2,a)$. Publiczny $A_2$ należy do $G_2$. Podpis będzie należał do $G_1$. W podstawowym wariancie nie trzeba publikować drugiego klucza w $G_1$.

Sign: haszowanie i działanie sekretem

Wejście: $pp$, klucz tajny $a$ oraz wiadomość $m\in\{0,1\}^*$. Wyznaczamy $Q=\mathcal H_{G_1}(m)$ i zwracamy $\sigma=Q^a\in G_1$. Przy ustalonym kluczu i profilu hasza wynik jest deterministyczny. Nie losujemy osobnego nonce jak w Schnorrze.

Verify: równanie parowań

Wejście: $pp$, klucz publiczny $A_2$, wiadomość $m$ i podpis $\sigma$. Sprawdzamy kodowania i przynależność do podgrup $A_2\in G_2$ oraz $\sigma\in G_1$. Odrzucamy neutralny klucz publiczny. Dla błędnego wejścia zwracamy 0. W przeciwnym razie samodzielnie liczymy $Q=\mathcal H_{G_1}(m)$ i zwracamy 1 wtedy i tylko wtedy, gdy:

Argumenty pairingu mają ustaloną kolejność: najpierw element $G_1$, potem element $G_2$. Weryfikator nie potrzebuje sekretu $a$.

Poprawność, notacja i demonstrator

Podpis i jego kontrola mają prosty zapis potęgowy:

Obie strony są równe $e(\mathcal H_{G_1}(m),g_2)^a$. Hasz daje element grupy, nie jawny skalar do pomnożenia przez stały generator. Potęgowanie hasza oznacza tu działanie sekretnego skalara na otrzymanej bazie. W implementacji na krzywej ta sama operacja nosi nazwę mnożenia skalarnego.

W addytywnych grupach źródłowych $\sigma=a\cdot\mathcal H_{G_1}(m)$, $A_2=a\cdot P_2$. Sprawdzamy:

Multiplikatywnie zapisujemy $\sigma=\mathcal H_{G_1}(m)^a$. To mnożenie punktu przez skalar zapisane potęgą, nie potęgowanie współrzędnych.

Gdy wariant używa także $A_1=a\cdot P_1$, zgodność reprezentacji sprawdza $e(A_1,P_2)=e(P_1,A_2)$. Podstawowy wariant nie musi publikować obu. Grupy źródłowe nie są zamienne w API.

Błędny zamiennik: $\mathcal H_{\mathrm{bad}}(m)=h(m)\cdot P_1$ dla znanego publicznie $h(m)$. Z podpisu dla $h(m)\ne0$ odzyskujemy $a\cdot P_1$ i tworzymy podpis każdej wiadomości. Poprawny hash do grupy nie ujawnia tak znanego logarytmu.

Demonstrator używa hashAndMapToG1 MCL. Nie deklaruje standardowego formatu BLS ani konkretnego zestawu RFC 9380. Bada pojedyncze podpisy. Agregacja wymaga dodatkowych warunków, np. ochrony przed rogue-key attacks.

Pełna ścieżka dowodowa: Schnorr: symulator, fork i redukcja DL, Okamoto: podpis i dwie reprezentacje. Najpierw przeczytaj definicję EUF-CMA powyżej. Rozdziały dowodowe podają założenia, wszystkie interfejsy oraz straty prawdopodobieństwa.

Powiązania: C6, L4, Boneh–Lynn–Shacham, RFC 9380.

W10. Ustalanie kluczy: DH, SIGMA i NAXOS

NAXOS

NAXOS. Nazwa własna protokołu uwierzytelnionej wymiany klucza, nie skrót rozwijany do angielskich słów.

Nowa potrzeba: nie wystarczy rozpoznać rozmówcy ani podpisać dokumentu. Dwie strony chcą uzyskać ten sam świeży sekret do ochrony kolejnych wiadomości i wiedzieć, z kim go współdzielą. Uzgodnienie klucza jest protokołem. Podpis jest jednym z możliwych narzędzi jego uwierzytelniania, a nie kompletnym protokołem wymiany.

Interfejs AKE: klucze długoterminowe i stan sesji

AKE, authenticated key exchange, oznacza uwierzytelnione uzgadnianie klucza. Dla omawianych systemów z kluczami publicznymi uporządkujemy opis jako

Jest to wspólny interfejs dydaktyczny dla maszyny stanów protokołu. Publikacje mogą grupować te czynności inaczej. Nie jest to twierdzenie, że każdy protokół AKE ma identyczne komunikaty lub korzysta z podpisów. W SIGMA KeyGen przygotuje klucze podpisu, a w NAXOS klucze dla działań grupowych. Inne rodziny AKE mogą używać współdzielonego sekretu lub hasła.

Niech $\mathrm{ID}$ oznacza lokalną tożsamość, $\mathrm{peer}$ zamierzonego partnera, a $\mathrm{role}$ rolę inicjatora lub odpowiadającego. Stan $st$ zawiera m.in. klucz długoterminowy lub odwołanie do niego, świeże sekrety sesji, dotychczasowe komunikaty i etap protokołu. Bufor $out$ zawiera komunikat do wysłania, a $in$ komunikat otrzymany. Pusty bufor zapisujemy jako $\varepsilon$.

Klucz wewnętrznie obliczony z otrzymanych punktów nie jest automatycznie kluczem zaakceptowanej sesji. Najpierw muszą przejść kontrole wymagane przez protokół. Wywołanie Next odrzuca także komunikat w niewłaściwym formacie lub niedozwolony na danym etapie. Po zakończeniu nie kontynuuje tej samej sesji z nowymi komunikatami.

Poprawność: jeśli uczciwi, zgodnie skonfigurowani partnerzy wykonają cały protokół i otrzymają wymagane komunikaty, akceptują zgodny klucz oraz właściwego partnera. Bezpieczeństwo: w określonym modelu aktywnej sieci przeciwnik nie powinien rozpoznać klucza świeżej sesji ani naruszyć wymaganej gwarancji uwierzytelnienia. Dokładne reguły partnerowania i ujawnień są częścią definicji. Nie wyprowadza się ich z samej równości dwóch kluczy.

Rdzeń DH i atak pośrednika

W DH Alicja wysyła $X=g^x$, Bob $Y=g^y$, a oboje liczą $Z=g^{x\cdot y}$. Przeciwnik pośrodku może zastąpić punkty i uzgodnić dwa sekrety. Zgodność uczciwego rachunku nie zapewnia tożsamości rozmówcy.

AKE łączy uwierzytelnianie z ustanowieniem świeżego klucza. Potrzebne są jednoznaczne kodowania, role, identyfikatory, transkrypt i właściwa KDF. Oddzielne etykiety wyznaczają klucze aplikacyjne, klucze MAC i kierunki komunikacji.

Od elementu grupy do bajtów klucza

Wspólny $Z$ jest elementem grupy, nie od razu kluczem AES. Najpierw obie strony kodują go w identyczny ciąg bajtów $\operatorname{encode}(Z)$. Następnie KDF korzysta z tego tajnego materiału i jawnego kontekstu. Wyprowadza osobne bajty dla każdego zastosowania, np. klucz MAC $k_m$ i klucz szyfrowania $k_E$. Kontekst zawiera uzgodnione identyfikatory protokołu, sesji i ról.

To zapis interfejsu, nie specyfikacja konkretnej KDF. W HKDF etap Extract przetwarza materiał wejściowy z użyciem soli, a Expand wyprowadza klucze z informacją o kontekście i przeznaczeniu. Szczegółowy profil protokołu określa kodowanie, sól i długości. Ten praktyczny mechanizm odróżniamy od idealnej wyroczni wyprowadzającej klucz w dowodzie NAXOS. Nie zastępujemy jednej drugim bez osobnej analizy.

Dwie rozmowy zamiast jednej: man in the middle

Alicja wysyła $X=g^x$, ale Ewa zatrzymuje go i wysyła Bobowi $U=g^u$. Bob odpowiada $Y=g^y$, a Ewa podmienia odpowiedź dla Alicji na $V=g^v$. Alicja liczy $V^x$, które Ewa oblicza jako $X^v$. Bob liczy $U^y$, które Ewa oblicza jako $Y^u$. Ewa nie zna $x$ ani $y$, ale zna oba klucze.

Problemem nie jest złamanie CDH. Ewa rozwiązuje dwa zadania, w których sama wybrała jeden wykładnik. Potrzebujemy uwierzytelnienia wkładów i połączenia ich z tożsamościami oraz rolami. Samo poprawne potęgowanie po obu stronach nie daje tego związku.

Zobacz oba sekrety pośrednika

W poniższym rachunku $X=g^x$ i $Y=g^y$ są uczciwymi wkładami. W wariancie ataku Ewa podstawia $U=g^u$ dla Boba oraz $V=g^v$ dla Alicji. Indeks $\mathrm{recv}$ oznacza element faktycznie otrzymany z sieci. Sprawdzamy osobno $V^x=X^v$ i $U^y=Y^u$. Strona Ewy używa wyłącznie przechwyconych elementów oraz własnych skalarów. Nie otrzymuje $x$ ani $y$. Realizacja na krzywej zapisuje te same równości jako $x\cdot V=v\cdot X$ i $y\cdot U=u\cdot Y$.

To demonstracja nieuwierzytelnionego DH, nie implementacja SIGMA ani NAXOS. Uzyskany punkt wymaga jeszcze wyprowadzenia kluczy z kontekstem. Dodanie KDF samo nie uwierzytelnia podstawionych wkładów.

SIGMA: podpis i MAC mają różne zadania

Podpis wiąże wkłady DH. MAC pod kluczem wyprowadzonym z DH wiąże tożsamość z wymianą.

To nie kompletny format IKE. Profile określają kontekst, role, kodowania i ewentualne szyfrowanie tożsamości. Klucz musi być powiązany ze sprawdzoną tożsamością. Podpis pod jednym punktem nie zastępuje konstrukcji.

Który algorytm jest wywoływany w SIGMA

Rozpiszmy skróty z rysunku. Parametry schematu podpisu oznaczamy przez $pp_{\mathrm{sig}}$, a zarejestrowane klucze Boba przez $(pk_B,sk_B)$. Dla podstawowego przepływu powyżej $m_B=\operatorname{enc}(X,Y)$ jest podpisywaną wiadomością Boba, a $m_A=\operatorname{enc}(Y,X)$ wiadomością Alicji. Kolejność pól rozróżnia role. Pełny profil ustala ponadto separatory domen i kontekst protokołu.

1. Bob oblicza wspólny sekret: $Z=X^y$. Z jego kodowania wyprowadza klucz $k_m$ do MAC i oddzielny materiał na klucz aplikacyjny.
2. Bob wywołuje podpis: $\sigma_B\leftarrow\mathsf{Sign}(pp_{\mathrm{sig}},sk_B,m_B)$. Klucz $sk_B$ pozostaje w urządzeniu, a $\sigma_B$ trafia do komunikatu.
3. Bob uwierzytelnia tożsamość w tej wymianie: $\tau_B\leftarrow\mathsf{Tag}(k_m,\operatorname{enc}(\mathrm{ID}_B))$. To znacznik MAC, nie drugi podpis cyfrowy.
4. Alicja weryfikuje: oblicza $Z=Y^x$ i zgodny $k_m$. Uruchamia $\mathsf{Verify}(pp_{\mathrm{sig}},pk_B,m_B,\sigma_B)$ oraz $\mathsf{Check}(k_m,\operatorname{enc}(\mathrm{ID}_B),\tau_B)$. Sprawdza również, czy $pk_B$ jest właściwym zarejestrowanym kluczem wskazanego partnera.
5. Alicja odsyła własny dowód: wywołuje Sign ze swoim $sk_A$ dla $m_A$ oraz Tag dla swojej tożsamości. Bob wykonuje odpowiadające sprawdzenia. Każda lokalna sesja wydaje klucz aplikacji dopiero zgodnie z warunkami akceptacji profilu.

To rozwinięcie interfejsów Sign, Verify, Tag i Check w podstawowej strukturze SIGMA, nie kompletna specyfikacja IKE. Konkretne kodowania, certyfikaty, ochrona tożsamości i momenty akceptacji wymagają pełnego profilu. Porównanie ról podpisu i MAC oraz warianty przepływu przedstawia Krawczyk, SIGMA, §5.

NAXOS: zalążek nie jest wykładnikiem

Ten sam cel AKE, inne wnętrze algorytmu Next. NAXOS nie jest SIGMA z zamienionym haszem. Zamiast dołączać podpisy wiąże długoterminowe i efemeryczne sekrety poprzez działania grupowe oraz wyrocznie wyprowadzające wykładnik i klucz. Dlatego nie dopisujemy mu wywołania Sign, którego w tej konstrukcji nie ma.