Notacja

Przyjmujemy następujące oznaczenia:

$m$ -- wiadomość,
$K(m)$ -- wiadomość zaszyfrowana kluczem symetrycznym K,
$K^{-1}(m)$ -- wiadomość odszyfrowana kluczem symetrycznym K,
$K_{1}K_{2}(m)$ -- skrótowy zapis dla złożenia $K_{2}(K_{1}(m))$,
$E(m)$ -- wiadomość ,,zapieczętowana'' kluczem E.

Rysunek 4.2: Komunikat przygotowany przez nadawcę $A$ do wysłania ścieżką $A \rightarrow A1 \rightarrow A2 \rightarrow A3 \rightarrow A4 \rightarrow A$

Pojedynczy miks $i$ otrzymuje komunikaty postaci (por. rys. 4.2):

$$E_i(header[K_i,A_{i+1},...]),m_2,m_3,...,m_n,m_{data}$$

Każdy komunikat składa się z $n+1$ bloków stałej długości. Dodatkowo wszystkie z wyjątkiem ostatniego ($m_{data}$) mają również równą długość. Po odebraniu miks deszyfruje przeznaczony dla niego nagłówek $header[K_i,A_{i+1},...]$ i przetwarza resztę w następujący sposób:

$$\longrightarrow K_i^{-1}(m_2),K_i^{-1}(m_3),..., K_i^{-1}(m_n),K_i^{-1}(footer[...]),K_i^{-1}(m_{data})$$

$footer$ jest strukturą zawierającą informacje zwrotne przekazywane przez każdy z miksów. Jest ona dodawana przede wszystkim dla zachowania długości komunikatu (równoważy usunięcie nagłówka). Następnie tak otrzymany komunikat zostaje wysłany do $A_{i+1}$. Graficzna prezentacja tej operacji przedstawiona jest na rysunku 4.3.

Rysunek 4.3: Operacja wykonywana przez miks. 1) Postać komunikatu otrzymanego przez miks $A_0$. 2) Po odpieczętowaniu nagłówka otrzymujemy adres kolejnego miksu $A_1$ oraz klucz symetryczny $K_0$. 3) Dodanie wypełnienia $F_0$ (potencjalnie zawierającego dodatkowe informacje) do części nagłówkowej komunikatu. 4) Całość zostaje odszyfrowana kluczem $K_0$ i przesłana do $A_1$

Jeśli dany miks został wyznaczony przez pierwotnego nadawcę komunikatu do wykonania żądania HTTP, to informacja o tym fakcie znajduje się w nagłówku ($header$), a otrzymany pakiet ma wtedy postać:

$$E_i(header[K_i,A_{i+1},...]),m_2,m_3,...,m_n,K_i(reqest)$$

Miks wykonuje wtedy żądanie, a komunikat wynikowy generuje podobnie jak w poprzednim przypadku, zastępując jedynie ostatni blok odebraną odpowiedzią (zasobem HTTP).

$$\longrightarrow K_i^{-1}(m_2),K_i^{-1}(m_3),..., K_i^{-1}(m_n),K_i^{-1}(footer[...]),K_i^{-1}(response)$$

Pakiet wracający już do nadawcy ma postać:

$$E_1(loop),m_2,m_3,...,m_n,m_{data}$$

Komunikat $loop$ jest informacją, dzięki której można rozpoznać zainicjowaną przez siebie wiadomość.

Poniższy przykład demonstruje w jaki sposób nadawca musi przygotować komunikat, aby został on poprawnie przetworzony przez sieć miksów. $A_0$ to adres nadawcy. Nadawca wybiera dwa inne miksy (ponieważ w tym przykładzie $n = 3$) o adresach $A_1$ i $A_2$ oraz losuje odpowiadające im klucze $K_1$ i $K_2$. Utworzona wiadomość ma postać:

$$E_1(head[K_1,A_2]),K_1(E_2(head[K_2,A_0])),K_2K_1(E_3(loop)),m_{data}$$

Zostaje ona wysłana pod adres $A_1$, gdzie jest przetwarzana:

$$\longrightarrow E_2(head[K_2,A_0]),K_2(E_3(loop)),K_1^{-1}(footer),K_1^{-1}(m_{data})$$

A następnie przez $A_2$:

$$\longrightarrow E_3(loop),K_1^{-1}K_2^{-1}(footer),K_2^{-1}(footer),K_1^{-1}K_2^{-1}(m_{data})$$

I w tej postaci powraca ostatecznie do $A_0$. Rysunek 4.4 przedstawia przykład przetworzenia komunikatu w przypadku czterech miksów pośredniczących, z których drugi ($A2$) został wyznaczony do wykonania żądania.

Rysunek 4.4: Postać komunikatu po przejściu przez kolejne miksy