fix latex issues

This commit is contained in:
seugu
2025-12-12 14:37:14 +03:00
committed by GitHub
parent 1dd49644c6
commit 73b6bf92df

View File

@@ -570,23 +570,23 @@ The header consists of the fields $α$, $β$, and $γ$, totaling a fixed size pe
Thus, the total header length is: Thus, the total header length is:
$` $$
\begin{aligned} \begin{aligned}
|Header| &= α + β + γ \\ |Header| &= α + β + γ \\
&= 32 + ((t + 1)r + 1)κ + 16 &= 32 + ((t + 1)r + 1)κ + 16
\end{aligned} \end{aligned}
`$ $$
Notation: $|x|$ denotes the size (in bytes) of field $x$. Notation: $|x|$ denotes the size (in bytes) of field $x$.
Using the recommended value of $r = 5$ and $t = 6$, the header size is: Using the recommended value of $r = 5$ and $t = 6$, the header size is:
$` $$
\begin{aligned} \begin{aligned}
|Header| &= 32 + 576 + 16 \\ |Header| &= 32 + 576 + 16 \\
&= 624 \ bytes &= 624 \ bytes
\end{aligned} \end{aligned}
`$ $$
#### 8.3.2 Payload Size #### 8.3.2 Payload Size
@@ -595,11 +595,11 @@ This subsection defines the size of the encrypted payload $δ$ in a Sphinx packe
$δ$ contains the application message, padded to a fixed maximum length to ensure all packets are indistinguishable on the wire. $δ$ contains the application message, padded to a fixed maximum length to ensure all packets are indistinguishable on the wire.
The size of $δ$ is calculated as: The size of $δ$ is calculated as:
$` $$
\begin{aligned} \begin{aligned}
|δ| &= TotalPacketSize - HeaderSize |δ| &= TotalPacketSize - HeaderSize
\end{aligned} \end{aligned}
`$ $$
The recommended total packet size is $4608$ bytes, chosen to: The recommended total packet size is $4608$ bytes, chosen to:
@@ -609,12 +609,12 @@ The recommended total packet size is $4608$ bytes, chosen to:
This recommended total packet size of \$4608\$ bytes yields: This recommended total packet size of \$4608\$ bytes yields:
$` $$
\begin{aligned} \begin{aligned}
Payload &= 4608 - 624 \\ Payload &= 4608 - 624 \\
&= 3984\ bytes &= 3984\ bytes
\end{aligned} \end{aligned}
`$ $$
Implementations MUST account for payload extensions, such as SURBs, when determining the maximum message size that can be encapsulated in a single Sphinx packet. Implementations MUST account for payload extensions, such as SURBs, when determining the maximum message size that can be encapsulated in a single Sphinx packet.
Details on SURBs are defined in [Section X.X]. Details on SURBs are defined in [Section X.X].
@@ -726,21 +726,21 @@ The construction MUST proceed as follows:
- Choose a random private exponent $x \in_R \mathbb{Z}_q^*$. - Choose a random private exponent $x \in_R \mathbb{Z}_q^*$.
- Initialize: - Initialize:
$` $$
\begin{aligned} \begin{aligned}
α_0 &= g^x \\ α_0 &= g^x \\
s_0 &= y_0^x \\ s_0 &= y_0^x \\
b_0 &= H(α_0\ |\ s_0) b_0 &= H(α_0\ |\ s_0)
\end{aligned} \end{aligned}
`$ $$
- For each hop $i$ (from $1$ to $L-1$), compute: - For each hop $i$ (from $1$ to $L-1$), compute:
$` $$
\begin{aligned} \begin{aligned}
α_i &= α_{i-1}^{b_{i-1}} \\ α_i &= α_{i-1}^{b_{i-1}} \\
s_i &= y_{i}^{x\prod_{\text{j=0}}^{\text{i-1}} b_{j}} \\ s_i &= y_{i}^{x\prod_{\text{j=0}}^{\text{i-1}} b_{j}} \\
b_i &= H(α_i\ |\ s_i) b_i &= H(α_i\ |\ s_i)
\end{aligned} \end{aligned}
`$ $$
Note that the length of $α_i$ is $32$ bytes, $0 \leq i \leq L-1$ as defined in [Section 8.3.1](#831-header-field-sizes). Note that the length of $α_i$ is $32$ bytes, $0 \leq i \leq L-1$ as defined in [Section 8.3.1](#831-header-field-sizes).
@@ -755,24 +755,24 @@ The construction MUST proceed as follows:
- Derive per-hop AES key and IV: - Derive per-hop AES key and IV:
$` $$
\begin{array}{l} \begin{array}{l}
Φ_{\mathrm{aes\_key}_{i-1}} = Φ_{\mathrm{aes\_key}_{i-1}} =
\mathrm{KDF}(\text{"aes\_key"} \mid s_{i-1})\\ \mathrm{KDF}(\text{"aes\_key"} \mid s_{i-1})\\
Φ_{\mathrm{iv}_{i-1}} = Φ_{\mathrm{iv}_{i-1}} =
\mathrm{KDF}(\text{"iv"} \mid s_{i-1}) \mathrm{KDF}(\text{"iv"} \mid s_{i-1})
\end{array} \end{array}
`$ $$
- Compute the filler string $Φ_i$ using $\text{AES-CTR}^\prime_i$, which is AES-CTR encryption with the keystream starting from index $((t+1)(r-i)+t+2)κ$ : - Compute the filler string $Φ_i$ using $\text{AES-CTR}^\prime_i$, which is AES-CTR encryption with the keystream starting from index $((t+1)(r-i)+t+2)κ$ :
$` $$
\begin{array}{l} \begin{array}{l}
Φ_i = \mathrm{AES\text{-}CTR}'_i\bigl(Φ_{\mathrm{aes\_key}_{i-1}}, Φ_i = \mathrm{AES\text{-}CTR}'_i\bigl(Φ_{\mathrm{aes\_key}_{i-1}},
Φ_{\mathrm{iv}_{i-1}}, Φ_{i-1} \mid 0_{(t+1)κ} \bigr),\; \; \; Φ_{\mathrm{iv}_{i-1}}, Φ_{i-1} \mid 0_{(t+1)κ} \bigr),
\text{where notation } 0_x \text{ defines the string of } 0 \text{ bits of length } x\text{.}
\end{array} \end{array}
`$ $$
where notation $0_x$ defines the string of $0$ bits of length $x$.
Note that the length of $Φ_i$ is $(t+1)iκ$, $0 \leq i \leq L-1$. Note that the length of $Φ_i$ is $(t+1)iκ$, $0 \leq i \leq L-1$.
@@ -787,7 +787,7 @@ The construction MUST proceed as follows:
- Derive per-hop AES key, MAC key, and IV: - Derive per-hop AES key, MAC key, and IV:
$` $$
\begin{array}{l} \begin{array}{l}
β_{\mathrm{aes\_key}_i} = β_{\mathrm{aes\_key}_i} =
\mathrm{KDF}(\text{"aes\_key"} \mid s_i)\\ \mathrm{KDF}(\text{"aes\_key"} \mid s_i)\\
@@ -796,7 +796,7 @@ The construction MUST proceed as follows:
β_{\mathrm{iv}_i} = β_{\mathrm{iv}_i} =
\mathrm{KDF}(\text{"iv"} \mid s_i) \mathrm{KDF}(\text{"iv"} \mid s_i)
\end{array} \end{array}
`$ $$
- Set the per hop two-byte encoded delay $\mathrm{delay}_i$ as defined in [Section 8.4](#84-address-and-delay-encoding): - Set the per hop two-byte encoded delay $\mathrm{delay}_i$ as defined in [Section 8.4](#84-address-and-delay-encoding):
@@ -807,36 +807,36 @@ The construction MUST proceed as follows:
- If $i = L-1$ (_i.e.,_ exit node): - If $i = L-1$ (_i.e.,_ exit node):
$` $$
\begin{array}{l} \begin{array}{l}
β_i = \mathrm{AES\text{-}CTR}\bigl(β_{\mathrm{aes\_key}_i}, β_i = \mathrm{AES\text{-}CTR}\bigl(β_{\mathrm{aes\_key}_i},
β_{\mathrm{iv}_i}, Δ \mid \mathrm{delay}_i \mid 0_{((t+1)(r-L)+2)κ} β_{\mathrm{iv}_i}, Δ \mid \mathrm{delay}_i \mid 0_{((t+1)(r-L)+2)κ}
\bigr) \bigm| Φ_{L-1} \bigr) \bigm| Φ_{L-1}
\end{array} \end{array}
`$ $$
- Otherwise (_i.e.,_ intermediary node): - Otherwise (_i.e.,_ intermediary node):
$` $$
\begin{array}{l} \begin{array}{l}
β_i = \mathrm{AES\text{-}CTR}\bigl(β_{\mathrm{aes\_key}_i}, β_i = \mathrm{AES\text{-}CTR}\bigl(β_{\mathrm{aes\_key}_i},
β_{\mathrm{iv}_i}, \mathrm{addr}_{i+1} \mid \mathrm{delay}_i β_{\mathrm{iv}_i}, \mathrm{addr}_{i+1} \mid \mathrm{delay}_i
\mid γ_{i+1} \mid β_{i+1 \, [0 \ldots (r(t+1) - t)κ - 1]} \bigr),\\ \mid γ_{i+1} \mid β_{i+1 \, [0 \ldots (r(t+1) - t)κ - 1]} \bigr)
\text{where notation } X_{[a \ldots b]} \text{ denotes the substring of } X
\text{ from byte offset } a \text{ to } b\text{, inclusive, using zero-based indexing.}
\end{array} \end{array}
`$ $$
where notation $X_{[a \ldots b]}$ denotes the substring of $X$
from byte offset $a$ to $b$ inclusive, using zero-based indexing.
Note that the length of $\beta_i$ is $(r(t+1)+1)κ$, $0 \leq i \leq L-1$ as defined in [Section 8.3.1](#831-header-field-sizes). Note that the length of $\beta_i$ is $(r(t+1)+1)κ$, $0 \leq i \leq L-1$ as defined in [Section 8.3.1](#831-header-field-sizes).
- Compute the message authentication code $γ_i$: - Compute the message authentication code $γ_i$:
$` $$
\begin{array}{l} \begin{array}{l}
γ_i = \mathrm{HMAC\text{-}SHA\text{-}256}\bigl(\mathrm{mac\_key}_i, γ_i = \mathrm{HMAC\text{-}SHA\text{-}256}\bigl(\mathrm{mac\_key}_i,
β_i \bigr) β_i \bigr)
\end{array} \end{array}
`$ $$
Note that the length of $\gamma_i$ is $κ$, $0 \leq i \leq L-1$ as defined in [Section 8.3.1](#831-header-field-sizes). Note that the length of $\gamma_i$ is $κ$, $0 \leq i \leq L-1$ as defined in [Section 8.3.1](#831-header-field-sizes).
@@ -848,35 +848,35 @@ The construction MUST proceed as follows:
- Derive per-hop AES key and IV: - Derive per-hop AES key and IV:
$` $$
\begin{array}{l} \begin{array}{l}
δ_{\mathrm{aes\_key}_i} = δ_{\mathrm{aes\_key}_i} =
\mathrm{KDF}(\text{"δ\_aes\_key"} \mid s_i)\\ \mathrm{KDF}(\text{"δ\_aes\_key"} \mid s_i)\\
δ_{\mathrm{iv}_i} = δ_{\mathrm{iv}_i} =
\mathrm{KDF}(\text{"δ\_iv"} \mid s_i) \mathrm{KDF}(\text{"δ\_iv"} \mid s_i)
\end{array} \end{array}
`$ $$
- Using the derived keys, compute the encrypted payload $δ_i$: - Using the derived keys, compute the encrypted payload $δ_i$:
- If $i = L-1$ (_i.e.,_ exit node): - If $i = L-1$ (_i.e.,_ exit node):
$` $$
\begin{array}{l} \begin{array}{l}
δ_i = \mathrm{AES\text{-}CTR}\bigl(δ_{\mathrm{aes\_key}_i}, δ_i = \mathrm{AES\text{-}CTR}\bigl(δ_{\mathrm{aes\_key}_i},
δ_{\mathrm{iv}_i}, 0_{κ} \mid m δ_{\mathrm{iv}_i}, 0_{κ} \mid m
\bigr) \bigr)
\end{array} \end{array}
`$ $$
- Otherwise (_i.e.,_ intermediary node): - Otherwise (_i.e.,_ intermediary node):
$` $$
\begin{array}{l} \begin{array}{l}
δ_i = \mathrm{AES\text{-}CTR}\bigl(δ_{\mathrm{aes\_key}_i}, δ_i = \mathrm{AES\text{-}CTR}\bigl(δ_{\mathrm{aes\_key}_i},
δ_{\mathrm{iv}_i}, δ_{i+1} \bigr) δ_{\mathrm{iv}_i}, δ_{i+1} \bigr)
\end{array} \end{array}
`$ $$
Note that the length of $\delta_i$, $0 \leq i \leq L-1$ is $|m| + κ$ bytes. Note that the length of $\delta_i$, $0 \leq i \leq L-1$ is $|m| + κ$ bytes.
@@ -946,21 +946,21 @@ After successful deserialization, the mix node performs the following steps:
- Derive the MAC key from the session secret $s$: - Derive the MAC key from the session secret $s$:
$` $$
\begin{array}{l} \begin{array}{l}
\mathrm{mac\_key} = \mathrm{mac\_key} =
\mathrm{KDF}(\text{"mac\_key"} \mid s) \mathrm{KDF}(\text{"mac\_key"} \mid s)
\end{array} \end{array}
`$ $$
- Verify the integrity of the routing header: - Verify the integrity of the routing header:
$` $$
\begin{array}{l} \begin{array}{l}
γ \stackrel{?}{=} \mathrm{HMAC\text{-}SHA\text{-}256}(\mathrm{mac\_key}, γ \stackrel{?}{=} \mathrm{HMAC\text{-}SHA\text{-}256}(\mathrm{mac\_key},
β) β)
\end{array} \end{array}
`$ $$
If the check fails, discard the packet and terminate processing. If the check fails, discard the packet and terminate processing.
@@ -968,24 +968,24 @@ After successful deserialization, the mix node performs the following steps:
- Derive the routing header AES key and IV from the session secret $s$: - Derive the routing header AES key and IV from the session secret $s$:
$` $$
\begin{array}{l} \begin{array}{l}
β_{\mathrm{aes\_key}} = β_{\mathrm{aes\_key}} =
\mathrm{KDF}(\text{"aes\_key"} \mid s)\\ \mathrm{KDF}(\text{"aes\_key"} \mid s)\\
β_{\mathrm{iv}} = β_{\mathrm{iv}} =
\mathrm{KDF}(\text{"iv"} \mid s) \mathrm{KDF}(\text{"iv"} \mid s)
\end{array} \end{array}
`$ $$
- Decrypt the suitably padded $β$ to obtain the routing block $B$ for this hop: - Decrypt the suitably padded $β$ to obtain the routing block $B$ for this hop:
$` $$
\begin{array}{l} \begin{array}{l}
B = \mathrm{AES\text{-}CTR}\bigl(β_{\mathrm{aes\_key}}, B = \mathrm{AES\text{-}CTR}\bigl(β_{\mathrm{aes\_key}},
β_{\mathrm{iv}}, β \mid 0_{(t+1)κ} β_{\mathrm{iv}}, β \mid 0_{(t+1)κ}
\bigr) \bigr)
\end{array} \end{array}
`$ $$
This step removes the filler string appended during header encryption in [Section 8.5.2](#852-construction-steps) step 3.c. and yields the plaintext routing information for this hop. This step removes the filler string appended during header encryption in [Section 8.5.2](#852-construction-steps) step 3.c. and yields the plaintext routing information for this hop.
@@ -995,23 +995,23 @@ After successful deserialization, the mix node performs the following steps:
- Derive the payload AES key and IV from the session secret $s$: - Derive the payload AES key and IV from the session secret $s$:
$` $$
\begin{array}{l} \begin{array}{l}
δ_{\mathrm{aes\_key}} = δ_{\mathrm{aes\_key}} =
\mathrm{KDF}(\text{"δ\_aes\_key"} \mid s)\\ \mathrm{KDF}(\text{"δ\_aes\_key"} \mid s)\\
δ_{\mathrm{iv}} = δ_{\mathrm{iv}} =
\mathrm{KDF}(\text{"δ\_iv"} \mid s) \mathrm{KDF}(\text{"δ\_iv"} \mid s)
\end{array} \end{array}
`$ $$
- Decrypt one layer of the encrypted payload $δ$: - Decrypt one layer of the encrypted payload $δ$:
$` $$
\begin{array}{l} \begin{array}{l}
δ' = \mathrm{AES\text{-}CTR}\bigl(δ_{\mathrm{aes\_key}}, δ' = \mathrm{AES\text{-}CTR}\bigl(δ_{\mathrm{aes\_key}},
δ_{\mathrm{iv}}, δ \bigr) δ_{\mathrm{iv}}, δ \bigr)
\end{array} \end{array}
`$ $$
The resulting $δ'$ is the decrypted payload for this hop and MUST be interpreted depending on the parsed node's role, determined by $B$, as described in [Section 8.6.2](#862-node-role-determination). The resulting $δ'$ is the decrypted payload for this hop and MUST be interpreted depending on the parsed node's role, determined by $B$, as described in [Section 8.6.2](#862-node-role-determination).
@@ -1036,35 +1036,35 @@ Once the node determines its role as an intermediary following the steps in [Sec
- Extract the first $(tκ - 2)$ bytes of $B$ as the next hop address $\mathrm{addr}$ - Extract the first $(tκ - 2)$ bytes of $B$ as the next hop address $\mathrm{addr}$
$` $$
\begin{array}{l} \begin{array}{l}
\mathrm{addr} = B_{[0\ldots(tκ - 2) - 1]} \mathrm{addr} = B_{[0\ldots(tκ - 2) - 1]}
\end{array} \end{array}
`$ $$
- Extract next two bytes as the mean delay $\mathrm{delay}$ - Extract next two bytes as the mean delay $\mathrm{delay}$
$` $$
\begin{array}{l} \begin{array}{l}
\mathrm{delay} = B_{[(tκ - 2)\ldots{tκ} - 1]} \mathrm{delay} = B_{[(tκ - 2)\ldots{tκ} - 1]}
\end{array} \end{array}
`$ $$
- Extract next $κ$ bytes as the next hop MAC $γ'$ - Extract next $κ$ bytes as the next hop MAC $γ'$
$` $$
\begin{array}{l} \begin{array}{l}
γ' = B_{[tκ\ldots(t + 1)κ - 1]} γ' = B_{[tκ\ldots(t + 1)κ - 1]}
\end{array} \end{array}
`$ $$
- Extract next $(r(t+1)+1)κ$ bytes as the next hop routing information $β'$ - Extract next $(r(t+1)+1)κ$ bytes as the next hop routing information $β'$
$` $$
\begin{array}{l} \begin{array}{l}
β' = B_{[(t + 1)κ\ldots(r(t +1 ) + t + 2)κ - 1]} β' = B_{[(t + 1)κ\ldots(r(t +1 ) + t + 2)κ - 1]}
\end{array} \end{array}
`$ $$
If parsing fails, discard the packet and terminate processing. If parsing fails, discard the packet and terminate processing.
@@ -1074,12 +1074,12 @@ Once the node determines its role as an intermediary following the steps in [Sec
- Compute the next hop ephemeral public value $α'$, deriving the blinding factor $b$ from the shared secret $s$ computed in [Section 8.6.1](#861-shared-preprocessing) step 1. - Compute the next hop ephemeral public value $α'$, deriving the blinding factor $b$ from the shared secret $s$ computed in [Section 8.6.1](#861-shared-preprocessing) step 1.
$` $$
\begin{aligned} \begin{aligned}
b &= H(α\ |\ s) \\ b &= H(α\ |\ s) \\
α' &= α^b α' &= α^b
\end{aligned} \end{aligned}
`$ $$
- Use the $β'$ and $γ'$ extracted in Step 1. as the routing information and MAC respectively in the outgoing packet. - Use the $β'$ and $γ'$ extracted in Step 1. as the routing information and MAC respectively in the outgoing packet.
@@ -1126,33 +1126,33 @@ Once the node determines its role as an exit following the steps in [Section 8.6
- Extract first $(tκ - 2)$ bytes of $B$ as the destination address $Δ$ - Extract first $(tκ - 2)$ bytes of $B$ as the destination address $Δ$
$` $$
\begin{array}{l} \begin{array}{l}
Δ = B_{[0\ldots(tκ - 2) - 1]} Δ = B_{[0\ldots(tκ - 2) - 1]}
\end{array} \end{array}
`$ $$
2. **Recover Padded Application Message** 2. **Recover Padded Application Message**
- Verify the decrypted payload $δ'$ computed in [Section 8.6.1](#861-shared-preprocessing) step 5.: - Verify the decrypted payload $δ'$ computed in [Section 8.6.1](#861-shared-preprocessing) step 5.:
$` $$
\begin{array}{l} \begin{array}{l}
δ'_{[0\ldots{κ} - 1]} \stackrel{?}{=} 0_{κ} δ'_{[0\ldots{κ} - 1]} \stackrel{?}{=} 0_{κ}
\end{array} \end{array}
`$ $$
If the check fails, discard $δ'$ and terminate processing. If the check fails, discard $δ'$ and terminate processing.
- Extract rest of the bytes of $δ'$ as the padded application message $m$: - Extract rest of the bytes of $δ'$ as the padded application message $m$:
$` $$
\begin{array}{l} \begin{array}{l}
m = δ'_{[κ\ldots]},\; \; \; m = δ'_{[κ\ldots]},
\text{where notation } X_{[a \ldots]} \text{ denotes the substring of } X
\text{ from byte offset } a \text{ to the end of the string using zero-based indexing.}
\end{array} \end{array}
`$ $$
where notation $X_{[a \ldots]}$ denotes the substring of $X$
from byte offset $a$ to the end of the string using zero-based indexing.
3. **Extract Application Message** 3. **Extract Application Message**
@@ -1347,4 +1347,4 @@ However, these protections do not prevent adversaries from injecting large volum
DoS protection—such as admission control, rate-limiting, or resource-bound access—MUST be implemented outside the core protocol. DoS protection—such as admission control, rate-limiting, or resource-bound access—MUST be implemented outside the core protocol.
Any such mechanism MUST preserve sender unlinkability and SHOULD be evaluated carefully to avoid introducing correlation risks. Any such mechanism MUST preserve sender unlinkability and SHOULD be evaluated carefully to avoid introducing correlation risks.
Defending against large-scale DoS attacks is considered a deployment-level responsibility and is out of scope for this specification. Defending against large-scale DoS attacks is considered a deployment-level responsibility and is out of scope for this specification.