Skip to content

Commit 4e095a7

Browse files
committed
missing notes
1 parent 5a48711 commit 4e095a7

4 files changed

Lines changed: 300 additions & 0 deletions

File tree

lectures/2026/2026-03-18.tex

Lines changed: 119 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,119 @@
1+
%!TEX root = ../notes.tex
2+
\section{March 18, 2026}
3+
\label{20260318}
4+
5+
\subsection{Hardware Secure Module (HSM)}
6+
7+
In Intel SGX, you can do arbitrary computations. However, HSM can only do restricted computations, for example, encryption/decryption. Alice can have an HSM that encrypts a message and she sends the encryption to Bob who has an HSM to decrypt the message. Another example is an HSM that takes in a ciphertext, decrypts it, then re-encrypts it with a new secret key.
8+
9+
This is used in places like Visa and a lot of bank systems. This is because they do not want to store the key anywhere, so that the user can only interact with the HSM like a black box without seeing the key.
10+
11+
\textit{How does an encrypt/decrypt HSM pair agree on a key?} The encrypt HSM (Alice) randomly samples $k_1, k_2, k_3$ such that $k_1 \oplus k_2 \oplus k_3 = k$. Then the 3 of them will be mailed to the decrypt HSM (Bob) using 3 different carriers, and the decrypt HSM will reconstruct the key $k$ on its own.
12+
13+
\subsection{Secure Multi-Party Computation}
14+
15+
\subsubsection{2-Party Computation}
16+
17+
We've seen this before, but it is whensome parties want to compute the output of some function on their individual inputs, without revealing their own inputs.
18+
19+
\begin{example}
20+
Alice and Bob just returned from a date, and want to figure out if they each want a second date. Alice has some choice bit $x$ and Bob some choice bit $y$. They want to jointly compute $f(x, y) = x\land y$.
21+
\end{example}
22+
\begin{example}
23+
Alice and Bob want to compare riches (who is richer?). They compute
24+
\[f(x, y) = \begin{cases}
25+
0 & \text{if }x>y \\
26+
1 & \text{otherwise}
27+
\end{cases}\]
28+
\end{example}
29+
\begin{example}
30+
Alice and Bob meet for the first time and want to see if they have friends in common. They have sets of friends $X,Y$, and compute
31+
\[f(X, Y) = X\cap Y.\]
32+
There are variants of this which only give cardinality of $X\cap Y$, etc.
33+
\end{example}
34+
35+
\Graphic{images/2023-03-16/2pc.png}{0.6}
36+
37+
In general, this is when two parties have inputs $x, y$ and want to compute some function $f(x, y)$ on them.
38+
39+
Use cases include:
40+
\begin{itemize}
41+
\item Password breach alert (Chrome/Firefox/Azure/iOS Keychain) runs a set intersection on your passwords and server leaked passwords.
42+
\item Privacy-preserving contact tracing for COVID-19 (Apple and Google). We want to know if we have contact but not who had contact with.
43+
\item Ads conversion measurements/personalized advertising (Google/Meta). We want to match conversions without either party knowing who converted.
44+
\end{itemize}
45+
46+
\subsubsection{Multiple Parties!}
47+
The general case of this is Secure Multi-Party Computation (MPC)
48+
49+
\Graphic{images/2023-03-16/mpc.png}{0.4}
50+
51+
This is when we have some parties $P_i$ and want to compute input on $f(x_i, \cdots, x_n)$.
52+
53+
Here are some applications:
54+
\begin{itemize}
55+
\item Privacy-preserving Inventory Matching (J.P. Morgan)
56+
\item Distributed key management (Unbound/Coinbase)
57+
\item Federated learning (used in Google Keyboard Search Suggestion). We want to run machine learning, federated amongst multiple devices. However, we don't want to leak the actual training data from users.
58+
\item Auctions (Danish sugar beet auction). Nobody should reveal their bid in the clear.
59+
\item Also deployed in Boston area to analyze the wage gap between genders without revealing the individual salaries.
60+
\item Study/Analysis on Medical Data. Every institution has limited data, but they cannot openly share that data due to regulations. How could they jointly do analysis on this data without revealing the data.
61+
\item Fraud Detection (banks). Users might have cards at multiple banks, they want to jointly detect fraud but do not want to share their transactions.
62+
\end{itemize}
63+
64+
When we normally talk about cryptography, we talk about `slowing down' the system (crypto makes everything slower). In the case of MPC, though, we've enabled new features that were not otherwise possible without these tools.
65+
66+
\subsection{Definition}
67+
Our setting is that we have $n$ parties $P_1, \dots, P_n$ with private inputs $x_1, \dots, x_n$. They want to jointly compute $f(x_1, \dots, x_n)$.
68+
69+
In terms of communication infrastructure: we usually assume point-to-point channels between each pair $(p_i, p_j)$. We know how to do this (key exchange, authenticated encryption, etc). Sometimes, we also assume a reliable broadcast channel where every other party gets information.
70+
71+
There is a single adversary that can ``corrupt'' a subset of the parties (at most $t$).
72+
73+
\emph{What properties do we want out of this system?} Here are some common security properties we might want:
74+
\begin{description}
75+
\item[Correctness.] The function is computed correctly.
76+
\item[Privacy.] Only the output is revealed.
77+
\item[Independence of Inputs.] Parties cannot choose their inputs depending on others' inputs.
78+
\end{description}
79+
Also with security guarantees:
80+
\begin{description}
81+
\item[Security with Abort.] The adversary may ``abort'' the protocol. This prevents honest parties from receiving the output. This is the weakest model.
82+
\item[Fairness.] If one party receives the output, then all parties will receive the output.
83+
\item[Guaranteed Output Delivery (GOD):] Honest parties \emph{always} receive output. Even if adversarial parties leave, the honest parties will simply continue the protocol.
84+
\end{description}
85+
86+
We also have some characterizations of adversaries:
87+
\begin{itemize}
88+
\item Allowed adversarial behavior:
89+
\begin{itemize}
90+
\item Semi-honest (or passive/honest-but-curious): They follow the protocol description honestly, but they try to extract more information by inspecting the transcript. This is the weaker model.
91+
\item Malicious/active: These adversaries can deviate arbitrarily from protocol description.
92+
\end{itemize}
93+
\item Adversary's computing power:
94+
\begin{itemize}
95+
\item Unbounded computing power: this gives us information-theoretic (IT) security.
96+
\item PPT bounded: this gives us computational security.
97+
\end{itemize}
98+
\end{itemize}
99+
100+
If you're interested, you can look into the literature of how to define security for MPCs. The idea is similar to that of ZK proofs---everything an adversary can do (see the transcript) can be simulated by a simulator who only has the input and output.
101+
102+
103+
\subsubsection{Feasibility Results}
104+
In the computational security setting, if we have a fundamental building block, a semi-honest oblivious transfer (OT), we can get semi-honest MPC for any function $t<n$. At a high level, using zero-knowledge proofs to enforce correctness of the protocol, we can convert any semi-honest MPC into a malicious MPC.
105+
106+
In terms of information-theoretic (IT) security. We can also get semi-honest and malicious MPC for any function with $t < \frac{n}{2}$. We call this an \ul{honest majority}. This is a necessary bound, we cannot do any better than this.
107+
108+
\subsection{Oblivious Transfer}
109+
\begin{definition}[Oblivious Transfer]
110+
An \ul{oblivious transfer} is a protocol in which a sender, with messages $m_0, m_1\in\{0, 1\}^l$ gives a choice to the receiver to receive either $m_0, m_1$.
111+
112+
Given a choice bit from the receiver $b\in\{0,1\}$, the receiver gets $m_b$ and the sender also gets no information about the messeage transferred.
113+
114+
\Graphic{images/2023-03-21/ot.png}{0.6}
115+
\end{definition}
116+
117+
We'll learn about constructions of OT later, but we black-box its implementation until later.
118+
119+
Using a semi-honest OT, we can use Yao's Garbled Circuit to construct semi-honest 2PC for any function. We can also use the GMW compiler to compile this into a semi-honest MPC for any function. We'll focus on the first approach in this lecture, but we'll learn GMW in the following lectures.

lectures/2026/2026-03-30.tex

Lines changed: 105 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,105 @@
1+
%!TEX root = ../notes.tex
2+
\section{March 30, 2026}
3+
\label{20260330}
4+
5+
\subsection{Multi-Party Computation - Big Picture}
6+
7+
There are two different levels of MPC: either semi-honest or malicious. Semi-honest means that the adversary follows the protocol, but tries to extract more information. Malicious means that the adversary deviates from the protocol to extract information.
8+
9+
If we have an oblivious transfer (OT) that is secure against semi-honest adversaries, we can use it with Yao's garbled circuit to achieve semi-honest 2-party computation for any function. Then, with the cut-and-choose with commitments, we can achieve malicious 2-party computation. We will discuss this next.
10+
11+
\begin{align*}
12+
\text{Semi-honest OT}\ & \underset{\text{Yao's Garbled Circuits}}{\implies}\ \text{Semi-honest 2PC for any function} \\
13+
& \underset{\text{Cut-and-choose with commitments}}{\implies}\ \text{Malicious 2PC for any function}
14+
\end{align*}
15+
16+
In the last part of this lecture, we will discuss how to use semi-honest OT with GMW to achieve semi-honest multi-party computation, which can be extended to malicious MPC.
17+
18+
\begin{align*}
19+
\text{Semi-honest OT} \ & \underset{\text{GMW}}{\implies} \text{Semi-honest MPC for any function}\\
20+
& \underset{\text{GMW Compiler with ZKP}}{\implies} \text{Malicious MPC for any function}
21+
\end{align*}
22+
23+
Recall the definition of Oblivious Transfer.
24+
25+
\begin{definition}[Oblivious Transfer]
26+
An \ul{oblivious transfer} is a protocol in which a sender, with messages $m_0, m_1\in\{0, 1\}^l$ gives a choice to the receiver to receive either $m_0, m_1$.
27+
28+
Given a choice bit from the receiver $b\in\{0,1\}$, the receiver gets $m_b$ and the sender also gets no information about the message transferred.
29+
30+
% \Graphic{images/2023-03-21/ot.png}{0.6}
31+
32+
\pseudocodeblock{
33+
\textbf{Sender} \< \< \textbf{Receiver}\\
34+
\text{Input: } m_0, m_1 \in \{ 0 , 1\}^{\ell} \< \< \text{Input: } b \in \{0, 1\}\\
35+
\< \sendmessageright*{ } \< \\
36+
\< \sendmessageleft*{ }\< \\
37+
\< \sendmessageright*{ }\< \\
38+
\< \sendmessageleft*{ } \< \\
39+
\text{Output: }\perp \< \< \text{Output: }m_b
40+
}
41+
\end{definition}
42+
43+
\subsection{GMW}
44+
45+
There is another method of multi-party computation that does not used garbled circuits called the Goldreich-Micali-Wigderson (GMW) protocol.
46+
47+
Throughout the protocol, we keep the invariant that for each wire $w$, if the value of the wire is $v^w \in\{0, 1\}$, then the parties hold an \ul{additive secret share} of $v^w$. Each party $P_i$ holds a random share $v_i^w\in\{0,1\}$ such that
48+
\[\bigoplus_{i=1}^n v_i^w = v^w\]
49+
and we keep this invariant throughout the entire circuit. \footnote{Recall that $\oplus$ means addition modulo 2. You can check that this also gives the XOR operation.}
50+
51+
We need to be able to preserve this invariant throughout \textsf{AND} and \textsf{XOR} gates. The \textsf{XOR} case is easy, since \textsf{XOR} is completely commutative and associative, so each party can locally \textsf{XOR} their shares $c_i := a_i\oplus b_i$ for $c := a\oplus b$.
52+
53+
We'll address the \textsf{AND} case later, but we can do this. We'll proceede gate-by-gate for everyone to compute the result. Each party will publish their local shares, and everyone will \textsf{XOR} the result together to get the final result.
54+
55+
\begin{remark}
56+
\textbf{(Frequently asked)} Why do we only consider AND and XOR gates? This is because every other gate (NOT, OR, NAND) can be constructed using only AND and XOR gates. Gates like this are considered \textbf{complete}.
57+
\end{remark}
58+
59+
\subsubsection{AND Gates}
60+
We now address the \textsf{AND} gates. We have $\bigoplus^n_{i=1}a_i = a$ and $\bigoplus^n_{i=1}b_i = b$.
61+
62+
We want a set of $\left\{ c_i \right\}$ s.t. $\bigoplus^n_{i=1}c_i = c = a \cdot b$ (multiplication of bits is \textsf{AND}). But
63+
\begin{align*}
64+
a\cdot b
65+
& = \left( \sum^n_{i=1}a_i \right)\cdot \left( \sum^n_{i=1}b_i \right)\pmod{2} \\
66+
& = \left( \sum^n_{i=1}a_i \cdot b_i \right) + \left( \sum_{i\neq j}a_i \cdot b_j \right)\pmod{2}
67+
\end{align*}
68+
The first sum is easy and computed locally, but the second sum requires parties to communicate. We do something called \ul{resharing}.
69+
70+
\textbf{Goal:} Between $P_i, P_j$, we want random $r_i, r_j\in\{0, 1\}$ such that $r_i + r_j = a_i \cdot b_j \pmod{2}$.
71+
72+
$P_i$ will randomly sample $r_i\sampledfrom \left\{ 0, 1 \right\}$. We can use OT to allow $P_j$ to learn $r_j$ such that $r_i + r_j = a_i\cdot b_j\pmod{2}$ without revealing $a_i$ or $r_i$.
73+
74+
$P_i$ will be the sender, $P_j$ is the receiver. $P_j$'s choice bit is $b_j$. Then the messages will be
75+
\begin{align*}
76+
m_0 & = (a_i\cdot 0) - r_i = r_i \mod 2\\
77+
m_1 & = (a_i\cdot 1) - r_i = a_i + r_i \mod 2
78+
\end{align*}
79+
such that $r_i, r_j$ are two shares of $a_i\cdot b_j$.
80+
81+
\pseudocodeblock{
82+
\textbf{Party i} \< \< \textbf{Party j}\\
83+
\text{Input: } a_i \in \{ 0 , 1\} \< \< \text{Input: } b_j \in \{0, 1\} \\
84+
r_i \sample \{0, 1\} \< \< \\
85+
\text{Prepare both possibilities for }r_j \< \< \\
86+
\< \sendmessageleft*{} \< \\
87+
\< \sendmessageright*{\text{Use OT with choice bit }b_j} \< \\
88+
\< \< \text{Receive } r_j\\
89+
\text{Output: }r_i \in \{0, 1\}\< \< \text{Output: }r_j \in \{0, 1\}
90+
}
91+
92+
\subsubsection{Complexities}
93+
Computational complexity is $O(\#\mathsf{AND}\cdot n)$ for each party, since each XOR gate takes constant number of operations and each AND gates requires a constant number of operations for each other party.
94+
95+
For communication complexity, each party needs to communicate to every other party for every \textsf{AND} gate. For each XOR gate, we do not need to communicate. So the communication complexity is $O(n \cdot \#\mathsf{AND})$ per party.
96+
97+
The round complexity is the depth of the AND gates in circuit. Each party needs to communicate to every other party for each AND gate, but some of these AND gates can be done in parallel (if they do not depend on each other). Thus, the round complexity is $O(\text{depth of AND gates})$.
98+
99+
\begin{center}
100+
\begin{tabular}{c|c}
101+
Computational Complexity & $O(\#\mathsf{AND}\cdot n)$ per party\\
102+
Communication Complexity & $O(n^2\cdot \#\mathsf{AND})$\\
103+
Round Complexity & $O(\text{depth of AND gates})$
104+
\end{tabular}
105+
\end{center}

0 commit comments

Comments
 (0)