AtHeartEngineer/rfc-index
1
0
Fork 0
mirror of https://github.com/vacp2p/rfc-index.git synced 2026-01-06 22:34:02 -05:00
Code Issues Packages Projects Releases Wiki Activity

Fix LaTeX errors (#163)

Browse Source 
LaTeX are causing build errors on rfc.vac.dev. Potential fixes..
This commit is contained in:
Jimmy Debe
2025-06-02 17:33:46 -04:00
committed by GitHub
parent f829b12517
commit db90adc94e
2 changed files with 50 additions and 48 deletions
Download Patch File Download Diff File Expand all files Collapse all files

18
vac/raw/deleted/eth-secpm.md
View File

@@ -422,7 +422,7 @@ Credentials MUST follow the specifications of section 5.3 of
Below follows the flow diagram for the generation of credentials.
Users MUST generate key pairs by themselves.
![figure1](./images/eth-secpm_credential.png)
![figure1](vac/raw/images/eth-secpm_credential.png)
### Message framing
@@ -765,10 +765,10 @@ CredentialType credential_types<V>;
The flow diagram shows the procedure to fetch key material from other
users:
![figure2](./images/eth-secpm_fetching.png)
![figure2](/vac/raw/images/eth-secpm_fetching.png)
Below follows the flow diagram for the creation of a group:
![figure3](./images/eth-secpm_creation.png)
![figure3](/vac/raw/images/eth-secpm_creation.png)
### Group evolution
@@ -843,15 +843,15 @@ The client MUST apply the proposals in the list in the order described
in Section 12.3 of [RFC9420](https://datatracker.ietf.org/docrfc9420/).
Below follows the flow diagram for the addition of a member to a group:
![figure4](./images/eth-secpm_add.png)
![figure4](/vac/raw/images/eth-secpm_add.png)
The diagram below shows the procedure to remove a group member:
![figure5](./images/eth-secpm_remove.png)
![figure5](/vac/raw/images/eth-secpm_remove.png)
The flow diagram below shows an update procedure:
![figure6](./images/eth-secpm_update.png)
![figure6](/vac/raw/images/eth-secpm_update.png)
### Commit messages
@@ -1293,7 +1293,7 @@ and checks that it corresponds to an address contained in the ACL.
7. Off-chain - Alice sends a welcome message to Bob.
8. Off-chain - Alice SHOULD broadcasts a message announcing the
addition of Bob to other users of the group.
![figure7](./images/eth-secpm_onchain-register-1.png)
![figure7](/vac/raw/images/eth-secpm_onchain-register-1.png)
#### Alice does not know Bob’s Ethereum address
@@ -1316,7 +1316,7 @@ contract.
8. Off-chain - Alice SHOULD broadcasts a message announcing the
addition of Bob to other users of the group.
![figure8](./images/eth-secpm_onchain-register-2.png)
![figure8](/vac/raw/images/eth-secpm_onchain-register-2.png)
### Considerations regarding smart contracts
@@ -1336,7 +1336,7 @@ off-chain message.
- The creator of the contract MUST update the ACL, and send
messages to the group for key update.
![figure9](./images/eth-secpm_onchain-update.png)
![figure9](/vac/raw/images/eth-secpm_onchain-update.png)
> It is important to note that both
user removal and updates of any kind

80
vac/raw/mix.md
View File

@@ -233,7 +233,7 @@ such as low latency and efficient multiplexing).
keystream, which is XORed with the plaintext to produce the ciphertext.
- **HMAC-SHA-256:** 256-bit MAC (truncated to 128 bits).
- **Inputs:** Key `k` (16 bytes), Message `m`
- **Message**: Data to be authenticated (_e.g.,_ $β$ component).
- **Message**: Data to be authenticated (_e.g.,_ $$\beta$$ component).
- **Output**: MAC `mac` (truncated to 128 bits).
- **Operation**: HMAC-SHA-256 uses the key and the message to produce a
hash-based message authentication code.
@@ -247,7 +247,7 @@ such as low latency and efficient multiplexing).
- Represents a Curve25519 group element (x-coordinate in GF(2^255 - 19)).
- Used by mix nodes to extract shared session key using their private key.
2. **Beta ($β$)**: $((t+1)r + 1)\kappa$ bytes typically, where $r$ is the maximum
2. **Beta ($$\beta$$)**: $((t+1)r + 1)\kappa$ bytes typically, where $r$ is the maximum
path length.
- Contains the encrypted routing information.
@@ -255,18 +255,18 @@ such as low latency and efficient multiplexing).
latency/anonymity trade-offs.
- This gives a reasonable size of $336$ bytes, when $t = 3$ (refer
Section 5.2.10 for the choice of $t$).
- We extend $β$ to accommodate next hop address and delay below.
- We extend $$\beta$$ to accommodate next hop address and delay below.
3. **Gamma ($γ$)**: $\kappa$ bytes (16 bytes)
- Output of HMAC-SHA-256, truncated to 128 bits.
- Ensures the integrity of the header information.
4. **Delta ($δ$)**: The encrypted payload, which can be of variable size.
4. **Delta ($$\delta$$)**: The encrypted payload, which can be of variable size.
- According to the [MixMatch](https://petsymposium.org/popets/2024/popets-2024-0050.pdf)
paper, the Nym network uses Sphinx packets of a fixed
size (2413 bytes).
- Considering this, the maximum $δ$ size can be chosen as 2413 bytes minus
- Considering this, the maximum $$\delta$$ size can be chosen as 2413 bytes minus
the header length (which will be derived below).
#### 4.2 Address Format and Delay Specification
@@ -289,8 +289,8 @@ or $3$).
- QUIC/TLS protocol identifier flag (1 byte)
- Peer ID (32 bytes for Ed25519 or Secp256k1).
The entire Sphinx packet header ($α$, $β$, and $γ$) can fit within a fixed size
of $32 + (r(t+1)+1)\kappa + 16 = 384$ bytes, leaving ample room for a large $δ$ of
The entire Sphinx packet header ($α$, $$\beta$$, and $γ$) can fit within a fixed size
of $32 + (r(t+1)+1)\kappa + 16 = 384$ bytes, leaving ample room for a large $$\delta$$ of
up to $2413 - 384 = 2029$ bytes.
#### 4.3 Message Format
@@ -406,31 +406,31 @@ sender, intermediary, and exit node) is detailed in the following subsections.
- Derive the AES key and IV:
$`\text{φ\_aes\_key}_{i-1} = KDF(\text{"aes\_key"}\ |\ s_{i-1})`$
$`\phi_{\mathrm{aes\_key}_{i-1}} = \mathrm{KDF}("aes\_key" \mid s_{i-1})`$
$`\text{φ\_iv}_{i-1} = H(\text{"iv"}\ |\ s_{i-1})`$ (truncated to 128 bits)
$`\phi_{\mathrm{iv}_{i-1}} = \mathrm{H}("iv" \mid s_{i-1})`$ (truncated to 128 bits)
- Compute the filler string $\phi_i$ using $\text{AES-CTR}^\prime_i$,
which is AES-CTR encryption with the keystream starting from
index $((t+1)(r-i)+t+2)\kappa$ :
$`\phi_i = \text{AES-CTR}^\prime_i(\text{φ\_aes\_key}_{i-1},\ \text{φ\_iv}_{i-1},
\ \phi_{i-1}\ |\ 0_{(t+1)\kappa})`$,
$`\phi_i = \mathrm{AES\text{-}CTR}'_i(\phi_{\mathrm{aes\_key}_{i-1}},
\phi_{\mathrm{iv}_{i-1}}, \phi_{i-1} \mid 0_{(t+1)\kappa})`$,
where $0_{(t+1)\kappa}$ is the string of $0$ bits of length $(t+1)\kappa$.
Note that the length of $\phi_i$ is $(t+1)i\kappa$.
c. **Compute** **Betas and Gammas ($\beta_i$**, $\gamma_i$, **$i=0$** to **$L-1$)**
c. **Compute** **Betas and Gammas ($$\beta_i$$**, $\gamma_i$, **$i=0$** to **$L-1$)**
For each $i$ (from $L-1$ to $0$):
- Derive the AES key, MAC key, and IV:
$`\text{β\_aes\_key}_{i} = KDF(\text{"aes\_key"}\ |\ s_{i})`$
$`\beta_{\mathrm{aes\_key}_i} = \mathrm{KDF}("aes\_key" \mid s_i)`$
$`\text{mac\_key}_{i} = KDF(\text{"mac\_key"}\ |\ s_{i})`$
$`\text{β\_iv}_{i} = H(\text{"iv"}\ |\ s_{i})`$ (truncated to 128 bits)
$`\beta_{\mathrm{iv}_i} = \mathrm{H}("iv" \mid s_i)`$ (truncated to 128 bits)
- Generate random $`\text{delay\_i}`$, a 16-bit unsigned integer (0-65535 milliseconds).
@@ -443,20 +443,21 @@ sender, intermediary, and exit node) is detailed in the following subsections.
- If $i = L-1$ (_i.e.,_ exit node):
$`\beta_i = \text{AES-CTR}(\text{β\_aes\_key}_{i},\ \text{β\_iv}_{i},\ 0_{((t+1)
(r-L)+t+2)\kappa})\ |\ \phi_{L-1}`$
$`\beta_i = \mathrm{AES\text{-}CTR}(\beta_{\mathrm{aes\_key}_i}, \beta_{\mathrm{iv}_i},
0_{((t+1)(r-L)+t+2)\kappa}) \mid \phi_{L-1}`$
- Otherwise (_i.e.,_ intermediary node):
$`\beta_i = \text{AES-CTR}(\text{β\_aes\_key}_{i},\ \text{β\_iv}_{i},\ \text
{addr}_{i+1} \ |\ \text{delay}_{i+1}\ | \ \gamma_{i+1}\ |\ {\beta_{i+1}}_
{[0\ldots(r(t+1)-t)\kappa−1]})`$
$`\beta_i = \mathrm{AES\text{-}CTR}\bigl(\beta_{\mathrm{aes\_key}_i},
\beta_{\mathrm{iv}_i}, \mathrm{addr}_{i+1} \mid \mathrm{delay}_{i+1}
\mid \gamma_{i+1} \mid \beta_{i+1 \, [0 \ldots (r(t+1) - t)\kappa - 1]} \bigr)`$
Note that the length of $\beta_i$ is $(r(t+1)+1)\kappa$, $0 \leq i \leq L-1$,
Note that the length of $$\beta_i$$ is $(r(t+1)+1)\kappa$, $0 \leq i \leq L-1$,
where $t$ is the combined length of next hop address and delay.
- $`\gamma_i = \text{HMAC-SHA-256}(\text{mac\_key}_i,\ β_i)`$\
Note that the length of $\gamma_i$ is $\kappa$.
- $`\gamma_i = \mathrm{HMAC\text{-}SHA\text{-}256}(\mathrm{mac\_key}_i, \beta_i)`$\
Note that the length of $\gamma_i$ is $\kappa$.
d. **Compute** **Deltas (**$\delta_i$, **$i=0$** to **$L-1$)**
@@ -464,18 +465,19 @@ sender, intermediary, and exit node) is detailed in the following subsections.
- Derive the AES key and IV:
$`\text{δ\_aes\_key}_{i} = KDF(\text{"δ\_aes\_key"}\ |\ s_{i})`$
$`\delta_{\mathrm{aes\_key}_i} = \mathrm{KDF}("\delta\_aes\_key" \mid s_i)`$
$`\text{δ\_iv}_{i} = H(\text{"δ\_iv"}\ |\ s_{i})`$ (truncated to 128 bits)
$`\delta_{\mathrm{iv}_i} = \mathrm{H}("\delta\_iv" \mid s_i)`$ (truncated to 128 bits)
- If $i = L-1$ (_i.e.,_ exit node):
$`\delta_i = \text{AES-CTR}(\text{δ\_aes\_key}_{i},\ \text{δ\_iv}_{i},
\ 0_{\kappa}\ |\ m)`$, where $m$ is the `message`.
$`\delta_i = \mathrm{AES\text{-}CTR}(\delta_{\mathrm{aes\_key}_i},
\delta_{\mathrm{iv}_i}, 0_{\kappa} \mid m)`$
, where $m$ is the `message`.
- Otherwise (_i.e.,_ intermediary node):
$`\delta_i = \text{AES-CTR}(\text{δ\_aes\_key}_{i},\ \text{δ\_iv}_{i},\ \delta_{i+1})`$
$`\delta_i = \mathrm{AES\text{-}CTR}(\delta_{\mathrm{aes\_key}_i}, \delta_{\mathrm{iv}_i}, \delta_{i+1})`$
Note that the length of $\delta$ is $|m| + \kappa$.
@@ -532,8 +534,8 @@ to relay a message:
$`\text{mac\_key} = KDF(\text{"mac\_key"}\ |\ s)`$
b. Check if $`\gamma = \text{HMAC-SHA-256}(\text{mac\_key},\ β)`$ . If not,
discard the message.
b. Check if $`\gamma = \mathrm{HMAC\text{-}SHA\text{-}256}(\mathrm{mac\_key}, \beta)`$.
If not, discard the message.
c. Otherwise, store tag $H(s)$ in the list of seen message tags.
@@ -541,12 +543,12 @@ to relay a message:
a. Derive the AES key, MAC key, and IV:
$`\text{β\_aes\_key} = KDF(\text{"aes\_key"}\ |\ s)`$
$`\beta_{\mathrm{aes\_key}} = \mathrm{KDF}("aes\_key" \mid s)`$
$`\text{β\_iv} = H(\text{"iv"}\ |\ s)`$ (truncated to 128 bits)
$`\beta_{\mathrm{iv}} = \mathrm{H}("iv" \mid s)`$ (truncated to 128 bits)
b. Compute
$`B = \text{AES-CTR}(\text{β\_aes\_key},\ \text{β\_iv},\ \beta\ |\ 0_{(t+1)k})`$.
$`B = \mathrm{AES\text{-}CTR}(\beta_{\mathrm{aes\_key}}, \beta_{\mathrm{iv}}, \beta \mid 0_{(t+1)k})`$.
c. Uniquely parse prefix of $B$
@@ -570,7 +572,7 @@ to relay a message:
g. **Extract Beta**
$`\beta' = B_{[(t\kappa+\kappa)\ldots(r(t+1)+t+2)\kappa-1]}`$ (following
$`\beta' = B_{[(t\kappa+\kappa) \ldots (r(t+1)+t+2)\kappa - 1]}`$ (following
$((t+1)r + 1)\kappa$ bytes).
h. **Compute Alpha**
@@ -582,9 +584,9 @@ to relay a message:
i. **Compute Delta**
- Derive the AES key and IV:
$`\text{δ\_aes\_key} = KDF(\text{"δ\_aes\_key"}\ |\ s)`$
$`\text{δ\_iv} = H(\text{"δ\_iv"}\ |\ s)$` (truncated to 128 bits)
- Compute $`\delta' = \text{AES-CTR}(\text{δ\_aes\_key},\ \text{δ\_iv},\ \delta)`$
$`\delta_{\mathrm{aes\_key}} = \mathrm{KDF}("\delta\_aes\_key" \mid s)`$
$`\delta_{\mathrm{iv}} = \mathrm{H}("\delta\_iv" \mid s)`$ (truncated to 128 bits)
- Compute $`\delta' = \mathrm{AES\text{-}CTR}(\delta_{\mathrm{aes\_key}}, \delta_{\mathrm{iv}}, \delta)`$
6. **Construct Final Sphinx Packet**
@@ -616,11 +618,11 @@ to relay a message:
- Derive the AES key and IV:
$`\text{δ\_aes\_key} = KDF(\text{"δ\_aes\_key"}\ |\ s)`$
$`\delta_{\mathrm{aes\_key}} = \mathrm{KDF}("\delta\_aes\_key" \mid s)`$
$`\text{δ\_iv} = H(\text{"δ\_iv"}\ |\ s)`$ (truncated to 128 bits)
$`\delta_{\mathrm{iv}} = \mathrm{H}("\delta\_iv" \mid s)`$ (truncated to 128 bits)
- Compute $`\delta' = \text{AES-CTR}(\text{δ\_aes\_key},\ \text{δ\_iv},\ \delta)`$.
- Compute $`\delta' = \mathrm{AES\text{-}CTR}(\delta_{\mathrm{aes\_key}}, \delta_{\mathrm{iv}}, \delta)`$.
3. **Extract Message**