tlsnotary/website
1
0
Fork 0
mirror of https://github.com/tlsnotary/website.git synced 2026-01-09 14:08:01 -05:00
Code Issues Packages Projects Releases Wiki Activity

Fixed \cdot and \oplus warnings (•,⊕)

Browse Source
This commit is contained in:
Hendrik Eeckhaut
2025-05-15 12:35:20 +02:00
parent bcf66796af
commit e34f0ea17f
2 changed files with 27 additions and 27 deletions
Download Patch File Download Diff File Expand all files Collapse all files

3
TODO.md
View File

@@ -14,4 +14,5 @@ TODO:
* ~~dark/light theme diagrams~~ * ~~dark/light theme diagrams~~
* rename repo landing-page -> website * rename repo landing-page -> website
* archive old documentation website * archive old documentation website
* What to do with drafts etc? * What to do with drafts etc?
* Check Docusaurus warnings

51
docs/mpc/mac.md
View File

@@ -44,15 +44,14 @@ the TLS record).
The `GHASH output` is the output of the GHASH function described in the The `GHASH output` is the output of the GHASH function described in the
[NIST publication](https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-38d.pdf) [NIST publication](https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-38d.pdf)
in section 6.4 in this way: "In effect, the GHASH function calculates $ in section 6.4 in this way: "In effect, the GHASH function calculates $
X_1•H^{m} ⊕ X_2•H^{m−1} ⊕ ... ⊕ X_{m−1}•H^{2} ⊕ X_m•H$". $H$ X_1 \cdot H^{m} \oplus X_2 \cdot H^{m−1} \oplus \ldots \oplus X_{m−1} \cdot H^{2} \oplus X_m \cdot H$". $H$ and $X$ are elements of the extension field $\mathrm{GF}(2^{128})$.
and $X$ are elements of the extension field $\mathrm{GF}(2^{128})$.
* "•" is a special type of multiplication called `multiplication in a finite * "$\cdot$" is a special type of multiplication called `multiplication in a finite
field` described in section 6.3 of the NIST publication. field` described in section 6.3 of the NIST publication.
* ⊕ is `addition in a finite field` and it is defined as XOR. * \oplus is `addition in a finite field` and it is defined as XOR.
In other words, GHASH splits up the ciphertext into 16-byte blocks, each block In other words, GHASH splits up the ciphertext into 16-byte blocks, each block
is numbered $X_1, X_2, ...$ etc. There's also $H$ is numbered $X_1, X_2, \ldots$ etc. There's also $H$
which is called the `GHASH key`, which just is the AES-encrypted zero-block. We which is called the `GHASH key`, which just is the AES-encrypted zero-block. We
need to raise $H$ to as many powers as there are blocks, i.e. if need to raise $H$ to as many powers as there are blocks, i.e. if
we have 5 blocks then we need 5 powers: $H, H^2, H^3, H^4, H^5$. we have 5 blocks then we need 5 powers: $H, H^2, H^3, H^4, H^5$.
@@ -82,7 +81,7 @@ and distributive: $a(b+c)=ab+ac$.
The goal of the protocol is to compute the MAC in such a way that neither party The goal of the protocol is to compute the MAC in such a way that neither party
would learn the other party's share of $H$ i.e. the `GHASH key` would learn the other party's share of $H$ i.e. the `GHASH key`
share. At the start of the protocol each party has: share. At the start of the protocol each party has:
1. ciphertext blocks $X_1, X_2, ..., X_m$. 1. ciphertext blocks $X_1, X_2, \ldots, X_m$.
2. XOR share of $H$: the `User` has $H_u$ 2. XOR share of $H$: the `User` has $H_u$
and the `Notary` has $H_n$. and the `Notary` has $H_n$.
3. XOR share of the `GCTR output`: the `User` has $GCTR_u$ 3. XOR share of the `GCTR output`: the `User` has $GCTR_u$
@@ -95,23 +94,23 @@ Note that **2.** and **3.** were obtained at an earlier stage of the TLSNotary p
To illustrate what we want to achieve, we consider the case of just having To illustrate what we want to achieve, we consider the case of just having
a single ciphertext block $X_1$. The `GHASH_output` will be: a single ciphertext block $X_1$. The `GHASH_output` will be:
$X_1•H = X_1•(H_u ⊕ H_n) = X_1•H_u ⊕ X_1•H_n$ $X_1\cdot H = X_1 \cdot(H_u \oplus H_n) = X_1 \cdot H_u \oplus X_1 \cdot H_n$
The `User` and the `Notary` will compute locally the left and the right terms The `User` and the `Notary` will compute locally the left and the right terms
respectively. Then each party will XOR their result to the `GCTR output` share respectively. Then each party will XOR their result to the `GCTR output` share
and will get their XOR share of the MAC: and will get their XOR share of the MAC:
`User` : $X_1 • H_u \quad ⊕ \quad GCTR_u = MAC_u$ `User` : $X_1 \cdot H_u \quad \oplus \quad GCTR_u = MAC_u$
`Notary`: $X_1 • H_n \quad ⊕ \quad GCTR_n = MAC_n$ `Notary`: $X_1 \cdot H_n \quad \oplus \quad GCTR_n = MAC_n$
Finally, the `Notary` sends $ MAC_n$ to the `User` who obtains: Finally, the `Notary` sends $ MAC_n$ to the `User` who obtains:
$MAC = MAC_n \quad ⊕ \quad MAC_u$ $MAC = MAC_n \quad \oplus \quad MAC_u$
**For longer ciphertexts, the problem is that higher powers of the hashkey **For longer ciphertexts, the problem is that higher powers of the hashkey
$H^k$ cannot be computed locally, because we deal with additive sharings, $H^k$ cannot be computed locally, because we deal with additive sharings,
i.e.$ (H_u)^k ⊕ (H_n)^k \neq H^k$.** i.e.$ (H_u)^k \oplus (H_n)^k \neq H^k$.**
### 3.2 Computing ciphertexts with an arbitrary number of blocks ### 3.2 Computing ciphertexts with an arbitrary number of blocks
We now introduce our 2PC MAC protocol for computing ciphertexts with an We now introduce our 2PC MAC protocol for computing ciphertexts with an
@@ -124,11 +123,11 @@ steps.
**multiplicative** shares $\overline{H}_u$ and $\overline{H}_n$. **multiplicative** shares $\overline{H}_u$ and $\overline{H}_n$.
2. This allows each party to **locally** compute the needed higher powers of these multiplicative 2. This allows each party to **locally** compute the needed higher powers of these multiplicative
shares, i.e for $m$ blocks of ciphertext: shares, i.e for $m$ blocks of ciphertext:
- the user computes $\overline{H_u}^2, \overline{H_u}^3, ... \overline{H_u}^m$ - the user computes $\overline{H_u}^2, \overline{H_u}^3, \ldots \overline{H_u}^m$
- the notary computes $\overline{H_n}^2, \overline{H_n}^3, ... \overline{H_n}^m$ - the notary computes $\overline{H_n}^2, \overline{H_n}^3, \ldots \overline{H_n}^m$
3. Then both parties convert each of these multiplicative shares back to additive shares 3. Then both parties convert each of these multiplicative shares back to additive shares
- the user ends up with $H_u, H_u^2, ... H_u^m$ - the user ends up with $H_u, H_u^2, \ldots H_u^m$
- the notary ends up with $H_n, H_n^2, ... H_n^m$ - the notary ends up with $H_n, H_n^2, \ldots H_n^m$
4. Each party can now **locally** compute their additive MAC share $MAC_{n/u}$. 4. Each party can now **locally** compute their additive MAC share $MAC_{n/u}$.
The conversion steps (**1** and **3**) require communication between the user The conversion steps (**1** and **3**) require communication between the user
@@ -147,7 +146,7 @@ we use an adapted version of the A2M protocol in chapter 4 of [Efficient Secure
Two-Party Exponentiation](https://www.cs.umd.edu/~fenghao/paper/modexp.pdf). Two-Party Exponentiation](https://www.cs.umd.edu/~fenghao/paper/modexp.pdf).
The user will decompose his share into $i$ individual oblivious transfers The user will decompose his share into $i$ individual oblivious transfers
$t_{u, i}^k = R \cdot (k \cdot 2^i + H_{u, i} \cdot 2^i ⊕ s_i)$, where $t_{u, i}^k = R \cdot (k \cdot 2^i + H_{u, i} \cdot 2^i \oplus s_i)$, where
- $R$ is some random value used for all oblivious transfers - $R$ is some random value used for all oblivious transfers
- $s_i$ is a random mask used per oblivious transfer, with $\sum_i s_i = 0$ - $s_i$ is a random mask used per oblivious transfer, with $\sum_i s_i = 0$
- $k \in \\{0, 1\\}$ depending on the receiver's choice. - $k \in \\{0, 1\\}$ depending on the receiver's choice.
@@ -161,9 +160,9 @@ $\overline{H_n}$.
$$ $$
\begin{align} \begin{align}
H &= H_u ⊕ H_n \\\\ H &= H_u \oplus H_n \\\\
&= R^{-1} \cdot R \cdot \sum_i (H_{u,i} ⊕ H_{n, i}) \cdot 2^i ⊕ s_i \\\\ &= R^{-1} \cdot R \cdot \sum_i (H_{u,i} \oplus H_{n, i}) \cdot 2^i \oplus s_i \\\\
&= R^{-1} \cdot \sum_i t_{u, i}^{H_{n, i}} ⊕ R \cdot \sum_i s_i \\\\ &= R^{-1} \cdot \sum_i t_{u, i}^{H_{n, i}} \oplus R \cdot \sum_i s_i \\\\
&= \overline{H_u} \cdot \overline{H_n} &= \overline{H_u} \cdot \overline{H_n}
\end{align} \end{align}
$$ $$
@@ -194,9 +193,9 @@ $$
\begin{aligned} \begin{aligned}
\overline{H} &= \overline{H_u} \cdot \overline{H_n} \\\\ \overline{H} &= \overline{H_u} \cdot \overline{H_n} \\\\
&= \overline{H_u} \cdot \sum_i \overline{H_{n, i}} \cdot 2^i \\\\ &= \overline{H_u} \cdot \sum_i \overline{H_{n, i}} \cdot 2^i \\\\
&= \sum_i (\overline{H_{n, i}} \cdot \overline{H_u} \cdot 2^i ⊕ s_i) ⊕ \sum_i s_i \\\\ &= \sum_i (\overline{H_{n, i}} \cdot \overline{H_u} \cdot 2^i \oplus s_i) \oplus \sum_i s_i \\\\
&= \sum_i t_{u, i}^{\overline{H_{n, i}}} ⊕ \sum_i s_i \\\\ &= \sum_i t_{u, i}^{\overline{H_{n, i}}} \oplus \sum_i s_i \\\\
&\equiv H_n ⊕ H_u &\equiv H_n \oplus H_u
\end{aligned} \end{aligned}
$$ $$
@@ -210,10 +209,10 @@ for even $k$:
$$ $$
\begin{align} \begin{align}
H^k &= (H_n^{k/2} ⊕ H_u^{k/2})^2 \\\\ H^k &= (H_n^{k/2} \oplus H_u^{k/2})^2 \\\\
&= (H_n^{k/2})^2 ⊕ H_n^{k/2} H_u^{k/2} ⊕ H_u^{k/2} H_n^{k/2} ⊕ (H_u^{k/2})^2 \\\\ &= (H_n^{k/2})^2 \oplus H_n^{k/2} H_u^{k/2} \oplus H_u^{k/2} H_n^{k/2} \oplus (H_u^{k/2})^2 \\\\
&= (H_n^{k/2})^2 ⊕ (H_u^{k/2})^2 \\\\ &= (H_n^{k/2})^2 \oplus (H_u^{k/2})^2 \\\\
&= H_n^k ⊕ H_u^k &= H_n^k \oplus H_u^k
\end{align} \end{align}
$$ $$