Kryptografia II stopień
Od definicji bezpieczeństwa do konstrukcji, redukcji i publikacji naukowych.
W14. Zobowiązania i reszyfrowanie
Zobowiązanie ukrywa decyzję, a zarazem utrudnia jej zmianę. Publikujemy , później otwieramy wiadomość i losowość. Ukrywanie chroni nadawcę. Wiązanie chroni odbiorcę.
Interfejs zobowiązania
Zapisujemy . Po ustaleniu wywołanie zwraca publiczne zobowiązanie i prywatne dane otwarcia . Przy otwarciu autor ujawnia , a odbiorca liczy . Uczciwe otwarcie ma dawać . Odbiorca nie dysponuje procedurą Dec z tajnym kluczem. To autor musi ujawnić otwarcie.
Realizacja Pedersena: , wiadomość , świeża losowość i dane otwarcia . CheckOpen sprawdza typy oraz poniższe równanie. Nazwa Commit oznacza tu algorytm zobowiązania do wiadomości, a nie krok identyfikacji Schnorra. Kontekst schematu rozróżnia te dwa interfejsy.
Zobowiązanie Pedersena: algorytmy i przepływ
Otwierający nie zna logarytmu h przy podstawie g.
Sprawdź typy i zakresy.
Zobowiązanie Pedersena
Zobowiązujący:
Odbiorca:
- Zobowiązujący, Commit:
- Zobowiązujący → Odbiorca: Etap zobowiązania
- Odbiorca, Zapamiętaj: Nie ma algorytmu deszyfrowania C.
- Zobowiązujący → Odbiorca: Późniejsze otwarcie
- Odbiorca, CheckOpen:
Pedersen: , gdzie generatory mają rząd , a otwierający nie zna . Jednostajne daje jednostajne niezależnie od . Dwa otwarcia przy dają:
Mianownik nie jest zerowy, inaczej równość wymuszałaby modulo . To redukcja wiązania do DL. Podmiot wybierający i zachowujący ma pułapkę do zmiany otwarcia. Ustanowienie parametrów jest częścią modelu.
Zobowiązanie pozostaje, lecz wiadomość się zmienia
W zapisie schematu mamy . Jeżeli otwierający celowo ustawił , może zwiększyć wiadomość o jeden i skorygować losowość:
Realizacja na krzywej. Generatory odpowiadają punktom . Równanie zobowiązania to , a znana relacja to . Odwrotność i wszystkie działania na skalarach wykonujemy w , nie na liczbach zmiennoprzecinkowych. Przy poprawnym ustawieniu parametrów nikt nie powinien znać relacji logarytmicznej między generatorami. W demonstracji drugi wariant wyznacza przez mapowanie do z osobną etykietą domeny. Nie deklarujemy przez to konkretnego profilu RFC 9380.
MCL WebAssembly w . Losowość r jest losowana w pełnym ciele skalarów. Jej ujawnienie na ekranie służy wyłącznie objaśnieniu.
Zapis i obliczenia. Wzory schematu są multiplikatywne. MCL realizuje je na krzywej. Generatory odpowiadają punktom . 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.
Obliczenia MCL na krzywej. Poniżej pokazujemy konkretne operacje biblioteki. Grupy punktów zapisujemy addytywnie.
Parametry i otwarcie
Oczekuje.
Opublikowane zobowiązanie
Oczekuje.
Pierwsze otwarcie
Oczekuje.
Druga wiadomość i próba otwarcia
Oczekuje.
Sprawdź: Włącz znaną relację generatorów z wykładnikiem 7. Czy dwa różne otwarcia dają dokładnie ten sam element grupy? Odtwórz 7 z ich różnicy.
Znajomość pułapki narusza wiązanie. Nie usuwa samego argumentu doskonałego ukrywania przy jednostajnym, nieujawnionym . Na ekranie pokazujemy wyłącznie do sprawdzenia rachunku. Po ujawnieniu otwarcia nie oczekujemy już ukrywania wiadomości.
Reszyfrowanie ElGamala przez świeże :
zachowuje wiadomość, ponieważ czynniki skracają się podczas deszyfrowania. Rerandomizacja nie daje integralności. Proxy re-encryption zmienia uprawnienia do deszyfrowania i jest inną funkcjonalnością.
Powiązania: C11.5: ukrywanie i związanie Pedersena. Dla porównania innej funkcjonalności opartej na działaniach grupowych: C8: szyfrowanie publiczne. Zobowiązania wracają w dowodach wiedzy, protokołach losowania i weryfikacji obliczeń.
W14a. Rerandomizacja i delegowanie deszyfrowania
Serwer przechowuje zaszyfrowane dane. Chcemy pozwolić mu coś z nimi zrobić bez ujawniania wiadomości. Odświeżenie wyglądu szyfrogramu oraz zmiana uprawnionego odbiorcy to dwa różne zadania. Pierwsze prowadzi do miksów, drugie do proxy re-encryption, czyli reenkrypcji przez pośrednika.
ElGamal: nowa losowość, ten sam klucz
Przyjmijmy i wiadomość . ElGamal tworzy .
Rerandomizacja ElGamala: algorytmy i przepływ
Setup, KeyGen, Enc i Dec są dokładnie algorytmami ElGamala. Dodajemy jedną procedurę publiczną. Zmieniamy oznaczenia składników na U,V jak w tym rozdziale.
Sprawdź wejście. Ani sekret a, ani pierwotne r nie są argumentami.
Rerandomizacja ElGamala
Publiczny pośrednik:
Odbiorca:
- Publiczny pośrednik, Wejście ReRand:
- Publiczny pośrednik, ReRand:
- Publiczny pośrednik → Odbiorca: Ten sam adresat, nowy szyfrogram
- Odbiorca, Dec:
Każdy znający publiczny może wybrać niezależne i obliczyć:
Odbiorca odzyskuje . Losowość jest jednostajna, nawet gdy ustalimy poprzednie . Publiczna transformacja nie wymaga znajomości ani , ani . W grupie zapisanej addytywnie mamy:
To nie jest zmiana adresata. Wciąż odszyfrowuje Alicja z sekretem . To również nie jest integralność: publiczna możliwość zmiany szyfrogramu jest tutaj zamierzona. Bezpieczeństwo poufności ElGamala wiążemy z DDH w wybranej grupie, nie z samą poprawnością deszyfrowania. W demonstratorze zwykły ElGamal działa w , bez udostępniania odpowiednika sekretnego klucza w .
BBS: prosty iloraz kluczy i jego cena
- BBS
- Blaze–Bleumer–Strauss. Nazwiska autorów omawianej reenkrypcji. Nie chodzi o generator Blum–Blum–Shub.
W konstrukcji typu Blaze–Bleumer–Strauss zmieniamy także format szyfrowania. Nie należy podstawić poniższego klucza reenkrypcji do zwykłego ElGamala z poprzedniego akapitu.
Reenkrypcja typu BBS: algorytmy i przepływ
Setup i KeyGen jak w grupowym przykładzie. Alicja ma (A,a), Bob (B,b). Wyliczenie ReKeyGen wymaga obu sekretów i odbywa się poza pokazanym przepływem szyfrogramu. Nie przekazujemy a ani b do proxy.
Rząd q jest liczbą pierwszą. Ustal kodowania i działania grupy. Dodatkowe funkcje wskazano przy konstrukcji.
Sekret a pozostaje u właściciela. Odbiorca uwierzytelnia publiczny A.
To nie interfejs z samym publicznym B. Klucz delegacji udostępnia się proxy.
Ta sama procedura z a odszyfrowuje C_A. Waliduj typy wszystkich wejść.
Reenkrypcja typu BBS
Nadawca:
Proxy:
Bob:
- Nadawca, Enc dla Alicji:
- Nadawca → Proxy: Szyfrogram dla Alicji
- Proxy, ReEnc: Użyj dostarczonego rk. Proxy nie zna a ani b.
- Proxy → Bob: Szyfrogram dla Boba
- Bob, Dec:
Dla niezerowych sekretów Alicji i Boba przyjmujemy:
Proxy zmienia pierwszy składnik, zachowując drugi:
W MCL używamy równoważnego zapisu , , . Bob oblicza . Widząc iloraz sekretów, od razu zadajmy trzy pytania:
- Kto tworzy klucz delegacji? Do wyliczenia skalaru potrzeba obu sekretów lub odpowiedniej procedury między stronami. Sam publiczny nie daje skalaru .
- W jaką stronę działa uprawnienie? Odwrotność daje . Iloczyn kluczy delegacji pozwala przejść przez kolejnych odbiorców. To delegacja dwukierunkowa i wieloetapowa.
- Co daje zmowa? Proxy zna , a Bob zna . Razem obliczają . Ujawniają cały sekret Alicji, nie tylko jedną wiadomość.
Niezmieniony drugi składnik pozwala też łączyć szyfrogramy przed transformacją i po niej. Przekazanie dostępu nie oznacza anonimowości relacji. Jest to dydaktyczna postać algebry BBS, EUROCRYPT 1998, nad grupą rzędu będącego liczbą pierwszą.
AFGH: pairing zmienia typ szyfrogramu
- AFGH
- Ateniese–Fu–Green–Hohenberger. Nazwiska autorów omawianego schematu reenkrypcji z pairingiem.
Chcemy, aby Alicja tworzyła delegację z własnego sekretu i publicznego klucza Boba. W ulepszonym wariancie Ateniese–Fu–Green–Hohenberger klucz ma dwa składniki sekretne. Jeden odpowiada za własne szyfrogramy, drugi za odbiór delegowanych szyfrogramów.
AFGH: delegacja i zmiana typu: algorytmy i przepływ
To dokładnie dydaktyczna instancja ścieżki delegacji opisanej poniżej. Indeks 2 oznacza szyfrogram przed delegacją, a 1 po niej. Nie deklarujemy kompletnej implementacji oryginalnego AFGH ani automatycznego przeniesienia jego dowodu do pairingu typu 3.
Parametry zawierają grupy, pierwszy rząd q, generatory, pairing i kodowania.
M należy do . Maskę oblicza się jako (Z^{a₁})^r z klucza publicznego.
W każdym algorytmie sprawdź typy i podgrupy. Po transformacji D nie jest argumentem dla ReEnc.
AFGH: delegacja i zmiana typu
Alicja / nadawca:
Proxy:
Bob:
- Alicja / nadawca, ReKeyGen: tylko Alicja:
- Alicja / nadawca → Proxy: Uprawnienie delegacji
- Alicja / nadawca, Enc₂: dowolny nadawca:
- Alicja / nadawca → Proxy: Dane do przekształcenia
- Proxy, ReEnc:
- Proxy → Bob: Wynik ma inny typ
- Bob, Dec₁:
Rachunek potęgowy instancji dydaktycznej. Dla generatorów , i pairingu oznaczmy . Niezerowe są sekretami Alicji, a niezerowe sekretami Boba. Ich klucze publiczne to oraz . Alicja tworzy . Dla świeżo wylosowanego szyfrogram wiadomości ma postać . Proxy oblicza:
Drugi rachunek wykonuje Bob, znający . To samo potęgowanie w grupach źródłowych poniżej zapisujemy jako mnożenie punktów przez skalary. Jest to ta sama dydaktyczna specjalizacja typów, z ograniczeniem dotyczącym przenoszenia dowodu opisanym dalej.
Dla demonstracji ustalamy , generatory i . Wiadomość jest elementem . Skalary są niezerowe. Grupy źródłowe zapisujemy addytywnie, a multiplikatywnie:
- Alicja deleguje: tworzy i przekazuje go proxy. Nie potrzebuje .
- Nadawca szyfruje dla Alicji: dla losowego tworzy szyfrogram drugiego poziomu .
- Proxy przekształca: oblicza i przekazuje Bobowi szyfrogram pierwszego poziomu .
- Bob odszyfrowuje: oblicza . Alicja nadal może odszyfrować pierwotną parę jako .
Dlaczego tylko jeden etap delegacji? Po transformacji pierwszy składnik leży w , a nie w . Nie wolno podać go jako pierwszego argumentu tego samego pairingu. Zmiana typu wyjścia jest tutaj częścią funkcjonalności, nie usterką interfejsu.
Oryginalna publikacja opisuje pairing symetryczny. Powyższy układ typów dla BLS12-381 jest specjalizacją dydaktyczną do sprawdzania równań, a nie deklaracją przeniesienia oryginalnego twierdzenia bezpieczeństwa na pairing typu 3. Źródło konstrukcji z dwoma skalarami to Third Attempt w AFGH, NDSS 2005 i §3.3 wersji TISSEC 2006. W tej wersji oryginalny argument poufności wykorzystuje eDBDH, a ochrony sekretu głównego problem logarytmu dyskretnego.
- NDSS
- Network and Distributed System Security Symposium. Sympozjum o bezpieczeństwie sieci i systemów rozproszonych.
- TISSEC
- Transactions on Information and System Security. Dawny tytuł czasopisma ACM o bezpieczeństwie informacji i systemów.
- eDBDH
- extended Decisional Bilinear Diffie–Hellman. Rozszerzony decyzyjny biliniowy problem Diffiego–Hellmana. Dokładny zestaw dodatkowych danych określa założenie w publikacji o reenkrypcji.
Nieodzyskany skalar nie oznacza braku szkody
Proxy wraz z Bobem może obliczyć . Nie jest to sam skalar , ale wystarcza do obliczania i odczytu szyfrogramów drugiego poziomu Alicji. Ochrona sekretu głównego i nieprzekazywalność prawa odczytu są różnymi własnościami. Tego pomocniczego punktu nie wolno traktować jako obojętnej dodatkowej części publicznego klucza.
Omawiany rachunek nie daje automatycznie delegacji ograniczonej do jednego dokumentu, ochrony CCA ani odwołania dostępu do już ujawnionych danych. Szyfrowanie elementu grupy nie jest też gotowym formatem szyfrowania plików. Realne zastosowanie wymaga odpowiedniej konstrukcji hybrydowej i modelu integralności zgodnego z dozwoloną transformacją.
Rzeczywiste operacje MCL. Typy szyfrogramów pozostają jawne. Rachunek pairingowy jest instancją dydaktyczną, nie audytowanym wdrożeniem AFGH.
Przed
Po
Kontrola wyniku
Porównanie oczekuje.
Zapis i obliczenia. Wzory schematu są multiplikatywne. MCL realizuje je na krzywej. W ElGamalu i BBS generator odpowiada punktowi . W AFGH generatory odpowiadają punktom . 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. Pairing występuje tylko w wariancie AFGH. W grupie docelowej zapis pozostaje multiplikatywny.
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 |
|---|
W teście niewłaściwego klucza porównujemy wynik z wiadomością znaną demonstratorowi. Sam odbiorca nie zawsze dostałby błąd. W surowym szyfrowaniu grupowym może otrzymać inny poprawny element grupy. To kolejna różnica między poprawnością, poufnością i uwierzytelnionym odczytem.
| Mechanizm | Cel | Co musi znać pośrednik? | Najważniejsza granica |
|---|---|---|---|
| Rerandomizacja ElGamala | Nowy wygląd, ten sam odbiorca. | Klucz publiczny i nową losowość. | Nie daje integralności ani zmiany odbiorcy. |
| BBS | Zmiana odbiorcy, możliwe dalsze delegacje. | Skalarny iloraz kluczy. | Delegacja odwracalna. Zmowa z odbiorcą ujawnia sekret. |
| AFGH, wariant omawiany | Jednokierunkowa, jednoetapowa transformacja. | Punkt klucza delegacji. | Ochrona sekretnego skalaru nie wyklucza ujawnienia zdolności deszyfrowania. |
Powiązania: zadania o typach i koluzji, laboratorium przekształceń, homomorfizm. Ta sama algebra może służyć innej funkcjonalności, ale nie przenosi automatycznie jej gwarancji.
W14b. Sieci miksujące: ukryć przyporządkowanie
Poufność ukrywa treść. Czasem równie istotne jest pytanie który szyfrogram wyjściowy odpowiada któremu wejściu. Przykładem jest partia zaszyfrowanych kart do głosowania lub wiadomości, których kolejność ujawniałaby nadawców. Mix przyjmuje całą partię, zmienia kolejność i przekształca szyfrogramy.
Dlaczego potrzebne są dwie operacje
- Samo tasowanie: zmieniamy kolejność, ale bajty szyfrogramów pozostają te same. Obserwator porównuje wejścia i wyjścia i odtwarza permutację.
- Sama rerandomizacja: zmieniają się bajty, ale zachowanie kolejności ujawnia przyporządkowanie pozycji.
- Obie operacje: tajna permutacja usuwa powiązanie pozycyjne, a niezależna rerandomizacja usuwa proste rozpoznawanie po równości szyfrogramów. Dalszy argument prywatności wymaga właściwego modelu i założeń kryptograficznych.
Dla szyfrogramów pod wspólnym kluczem mix wybiera tajną permutację zbioru i niezależne . Publikuje:
Kolejny mix wykonuje ten sam rodzaj operacji na nowej partii. W demonstracji wszystkie etapy pozostają widoczne, ale przypisanie wiadomości do pozycji jest ukryte do chwili odszyfrowania. Opcjonalne oznaczenie pochodzenia pokazuje wiedzę administracyjną demonstratora, a nie dane wysyłane przez prawdziwy mix. Losowa permutacja może pozostawić niektóre pozycje, a nawet całą kolejność bez zmian. Jedna taka próba nie jest błędem losowania.
Lokalny model partii szyfrogramów ElGamala w MCL. To nie działająca sieć anonimowa ani implementacja dowodu shuffle.
Partia wejściowa
- 1
- 2
- 3
- 4
Po miksie 1
- 1
- 2
- 3
- 4
Po miksie 2
- 1
- 2
- 3
- 4
Po odszyfrowaniu
- 1
- 2
- 3
- 4
Kontrola partii 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 |
|---|
Co trzeba udowodnić, zanim zaufamy partii
Złośliwy mix mógłby usunąć kartę, powielić inną albo podmienić wiadomość. Samo poprawne odszyfrowanie każdej pozycji tego nie wykrywa. Potrzebujemy dowodu, że nowa partia zawiera ten sam multizbiór wiadomości, przy ukrytym przyporządkowaniu. Świadkiem są permutacja i losowości. Publiczne dane to klucz oraz obie partie:
oznacza zbiór wszystkich permutacji pozycji. Dowód z wiedzą zerową tej relacji ma przekonać odbiorcę o poprawności przetasowania bez pokazania . Równość iloczynów wszystkich szyfrogramów nie wystarcza, bo kompensujące się zmiany mogą zachować iloczyn, a zmienić wiadomości. Przykładem właściwych rozwiązań są weryfikowalne przetasowania Neffa. Demonstracja oblicza szyfrowanie, tasowanie i rerandomizację, ale nie implementuje tego dowodu.
Historia, model i granice anonimowości
Historyczny mix Chauma usuwa warstwy szyfrowania i przestawia wiadomości. Nie jest identyczny z pokazanym tu miksem rerandomizującym ElGamala. Łączy je cel: utrudnić powiązanie wejścia z wyjściem. Różnią je formaty komunikatów, operacje i sposób uzasadnienia bezpieczeństwa.
W modelu miksów rerandomizujących niepowiązywalność wejść i wyjść partii może opierać się na co najmniej jednym uczciwym miksie, który zachowa tajną permutację i losowość. To wymaga również poufności szyfrowania, właściwego postępowania z błędnymi szyfrogramami i nieprzekroczonego progu kompromitacji klucza deszyfrującego. Samo dodanie jednego serwera nie dowodzi anonimowości wobec aktywnego przeciwnika.
Odszyfrowanie można rozdzielić progowo między uczestników. Chroni to przed samotnym posiadaczem całego klucza, lecz wymaga bezpiecznego generowania udziałów i sprawdzania częściowych deszyfrowań. Nawet prawidłowy shuffle nie ukryje tożsamości wpisanej w treść, nie usunie korelacji długości i czasu poza modelem partii ani nie zmusi serwera do odpowiedzi. Weryfikowalność, anonimowość i dostępność trzeba rozpatrywać osobno.
Powiązania: wiedza zerowa, próg, ćwiczenia, laboratorium partii.