notes
+
+
+Table of Contents
+ +
+
+1 Protocols with Trusted Dealer (week 2 & 3)
+
+
+
+
+1.1 Curriculum
+
+
+-
+
- Model (trusted dealer). + +
- Protocols with passive security (One-time truth-tables, passive BeDOZa) and their security. + +
- Active attacks against OTTT/BeDOZa. + +
- Countermeasures (using information-theoretic MACs) and their security. + +
+
+1.2 Prelims
+
+
+-
+
- The whole passive security thing where we define views and that a simulator has to be computationally indistingushiable from the views of all parties. + +
- The views contain the party input, internal randomness (if any), and all the messages received during the protocol
+
-
+
- The messages sent do not need to be included, as these are a function of the randomness and the messages received + +
+
+
+1.3 Passively secure protocols
+
+
+-
+
- A trusted dealer is essentially just a third-party who we assume we can trust + +
+
+1.3.1 OTTT
+
+
+-
+
- This protocols allows two parties to compute any function over their inputs. Thus: \(f : \{0,1\}^n \times \{0,1\}^n \rightarrow \{0,1\}\). + +
- Rather than computing the function though, it's represented by a truth table (a matrix) $ T ∈ \{0,1\}2n × 2n $ where \(T[i,j] = f(i,j)\). + +
- The ideal functionality is: Alice inputs \(x \in \{0,1\}^{n}\) and Bob inputs \(y \in \{0,1\}^{n}\). The protocols allows Alice to learn \(z = f(x,y)\) and Bob should learn nothing. + +
- The protocol++
-
+
- The trusted dealer D does the following:
+
-
+
- Choose two shifts \(r \in \{0,1\}^n\) and \(s \in \{0,1\}^n\) uniformly at random + +
- Choose matrix \(M_B \in \{0,1\}^{2^n \times 2^n}\) uniformly at random + +
- Compute a matrix \(M_A\) s.t. \(M_A[i,j] = M_B[i,j] \oplus T[i-r \mod 2^n, j-s \mod 2^n]\) + +
- Output \((r,M_A)\) to Alice and \((s, M_B)\) to Bob. + +
+ - The actual protocol:
+
-
+
- Alice computes \(u = x+r \mod 2^n\) and sends \(u\) to Bob + +
- Bob computes \(v = y+s \mod 2^n\) and \(z_B = M[u,v]\) and sends \((v,z_B)\) to Alice + +
- Alice outs \(z = M_A[u,v] \oplus z_B\) + +
+ - Correctness: $$z = M_A[u,v] \oplus z_B = M_A[u,v] \oplus M_B[u,v] = T[u-r, v-s] = T[x,y] = f(x,y)$$ + +
+ - The trusted dealer D does the following:
+
- Security proof TODO: Figure out the simulator for Bob++
-
+
- We need to construct a simulator that, given the input and output, is computationally indistinguishable from the views. + +
- The views for OTTT are defined as: $$ view_A = \{x, (r,M_A), (v, z_B) \} $$ and $$ view_B = \{y, (s, M_B), u \}$$ + +
- According to the book, as this is a deterministic function, we can look at the distribution of outputs and the views separately. + +
- Alice:
+
-
+
- The simulator gets as input \(x \in \{0,1\}^n\) and \(z \in \{0,1\}\) + +
- Sample uniformly a random \(z_B \in \{0,1\}\), a random \(v \in \{0,1\}^n\) and a random \(r \in \{0,1\}^n\) + +
- Construct MA : ∀ (i,j) ≠ (x+r,v): choose \(M_A[i,j] \in \{0,1\}\) uniformly at random. Define \(M_A[x+r,v] = z \oplus z_B\). + +
+ - In both the simulated and real case, the values \(r, v\) and \(M_A[i,j]\) for all \((i,j) \neq (u,v)\) are chosen uni-randomly. + +
- The pair $(MA[u,v], zB) is in both cases a pair of random bits s.t. \(z = M_A[u,v] \oplus z_B\)
+
-
+
- This is an application of the "principle of deferred decision", i.e. it does not matter which order the random elements are sampled + +
+ - Has unconditional security, kind of the OTP of MPC + +
- Optimal round complexity, as it's only one message per party + +
- \(2n+1\) bits are send, which is \(1\) bit off the optimal communication complexity, which is \(2n\) + +
- Has a bad storage problem, as each party needs to receive an exponential of \(n\) bits from the trusted dealer
+
-
+
- One could gen \(M_B\) or \(M_A\) using a pseudorandom generator. This forces the protocol to only have computational security from the previous unconditional, but the storage complexity of one of the parties can be made small, while the other still needs exponential. + +
+
+
+1.3.2 BeDOZa
+
+
+-
+
- Circuit based, still using a trusted dealer + +
- More complicated, as it has to support different operations, XOR and AND. + +
- Has \(6\) different layers or wires!
+
-
+
- Input Wires: For each of the n wires belonging to Alice: Alice samples a random bit \(x_B \leftarrow \{0,1\}\), sets \(x_A = x \oplus x_B\) and then sends \(x_B\) to Bob. \(x\) is said to be "shared" or "x-in-a-box", using notation \([x] \leftarrow Share(A,x)\). Bob is symmetric to this. + +
- Output wires: If Alice (resp. Bob), is supposed to learn [x], Bob sends \(x_B\) to Alice who can then output \(x = x_A \oplus x_B\). \((x, \perp) \leftarrow OpenTo(A, [x])\). \(x \leftarrow OpenTo([x])\) is written, if both is to learn. + +
- XOR with Constant: Write \([z] = [x] \oplus c\) for a unary gate computing \(z = x \oplus c\) for some constant bit \(c \in \{0,1\}\). In reality, Alice computes \(z_A = x_A \oplus c\) while Bob simply sets \(z_B = x_B\). + +
- AND with Constant: \([z] = [x] \cdot c\). Same as above, kinda, but multiply. Both Alice and Bob multiplies their share by c now. \(z_{A,B} = x_{A,B} \cdot c\). + +
- XOR of Two Wires: \([z] = [x] \oplus [y]\). Alice computes \(z_A = x_A \oplus y_A\), Bob computes \(z_B = x_B \oplus y_B\). + +
- AND of Two Wires: The only part which requires a trusted dealer. \([z] \leftarrow EvalAnd([x], [y])\), computes \(z = x \cdot y\).
+
-
+
- Dealer outputs a random triple \([u], [v], [w]\) s.t. \(w = u \cdot v\). + +
- Run subprotocol: \([d] = [x] \oplus [u]\) + +
- Run subproto: \([e] = [y] \oplus [v]\) + +
- Run subproto: \(d \leftarrow Open([d])\) + +
- Run subproto: \(e \leftarrow Open([e])\) + +
- Run subproto: \([z] = [w] \oplus e \cdot [x] \oplus d \cdot [y] \oplus e \cdot e\) + +
+
+
+
+1.4 Active Security
+
+
+-
+
- Message authentication codes!! + +
+
+1.4.1 OTTT with MACs
+
+
+-
+
- A malicious Bob can deviate from the original OTTT protocol in a few ways:
+
-
+
- Bob can send the wrong value \(v'\), rather than \(v = y+s\). This means that Bob sends some arbitrary \(v' \in \{0,1\}^n\). However, this can be seen as input substitution, since it's based on \(y\), which is a value only Bob knows regardless.
+
-
+
- Since \(v' = (y+diff) + s\) s.t. \(y+diff = y'\), where \(y'\) could might as well have been the original input. + +
+ - Bob sends nothing or an invalid message. This will happen if Bob either does not send anything or Bob sends a pair which is not the right format; i.e. \((v', z'_B) \not\in \{0,1\}^n \times \{0,1\}\).
+
-
+
- The second condition can be checked by Alice and the first can be solved by adding a timer at which point Alice will time out. + +
- At this point, Bob has learned nothing but the value \(u\), which is just a random value, as such we will not consider this cheating. + +
- So we account for this by modifying the protocol in such a way that if Alice detects an invalid message or receives none, she simply outputs \(z = f(x, y_0)\) where \(y_0\) is just some default input. This can be computed efficiently in the simulated world by having the simulator give \(y_0\) to the ideal world. + +
+ - Bob sends a wrong value \(z'_B\). Since \(z_B\) is the value we XOR with in the end, if it's flipped, Alice will get the wrong result, but will not know this.
+
-
+
- Since \(z'_B = z_B \oplus 1\) must be true, Alice will output \(z' = z \oplus 1 = f(x,y) \oplus 1\). + +
- This is NOT input substitution. If Alice and Bob were to compute \(f(x,y) = 0\) for all values of \(x\) and \(y\), this would get fucked by Bob flipping his \(z_B\), as Alice would always end up XORing \(0\) and \(1\), giving \(1\) instead of \(0\) as the result. + +
+
+ - Bob can send the wrong value \(v'\), rather than \(v = y+s\). This means that Bob sends some arbitrary \(v' \in \{0,1\}^n\). However, this can be seen as input substitution, since it's based on \(y\), which is a value only Bob knows regardless.
+
- Does, we need to defend us against the third case! + +
- Intro to MACs++
-
+
- Message authenticaion code + +
- Has three algos: (gen, tag, ver), where gen produces a MAC key k which can then be used to compute a tag on messages: \(t = tag(k,m)\). The verification function ver(k,t,m) outputs accept if t is a valid tag for message m under key k and rejects otherwise.
+
-
+
- Security of a MAC is defined as a game between a challenger C and an adversary A. C samples a key k and then A is alllowed to query q times for tags t1,…,tq on messages x1, …., xq. The adversary then outputs a pair (t', x') for a message x' which he has not already queried for. A MAC scheme is then (q, eps) secure if the adversary is allowed <= q queries and his probability of t' being a valid tag for x' is >= eps. + +
+
+ - Enhancing OTTT++
-
+
- The dealer does the following:
+
-
+
- Choose two shifts \(r \in \{0,1\}^n\) and \(s \in \{0,1\}^n\) uniformly at random + +
- Choose matrix \(M_B \in \{0,1\}^{2^n \times 2^n}\) uniformly at random + +
- Compute a matrix \(M_A\) s.t. \(M_A[i,j] = M_B[i,j] \oplus T[i-r \mod 2^n, j-s \mod 2^n]\) + +
- Generate \(2^{2n}\) keys for a \((1, \epsilon)\)-secure MAC i.e. ∀ i,j ∈ {0,1}n define \(K[i,j] \leftarrow Gen()\). + +
- Generate MACs for values in \(M_B\); i.e. ∀ i,j ∈ {0,1}n define \(T[i,j] \leftarrow Tag(K[i,j], M_B[i,j])\). + +
- Output \((r, M_A, K)\) to Alice and \((s, M_B, T)\) to Bob. + +
+ - The protocol:
+
-
+
- Alice computes \(u = x+r \mod 2^n\) again and sends this to Bob + +
- Bob computes \(v = y+s \mod 2^n\), \(z_B = M_B[u,v]\) and \(t_B = T[u,v]\) and then sends \((v, z_B, t_B)\) to Alice + +
- If \(ver(z_B, t_B, K[u,v]) = reject\) or no valid message is received, Alice outputs \(f(x, y_0) = z\), else \(z = M_A[u,v] \oplus z_B\). + +
+
+ - The dealer does the following:
+
- Proving security++
-
+
- This is no longer strictly deterministic, most likely since the MAC scheme fails with probability epsilon, thus we have to show this works for the joint probability of the views and the output. + +
- The proof is a reduction to breaking the underlying MAC scheme, if we can break the OTTT protocol. + +
- The simulator:
+
-
+
- Sample random \(s, M_B\), generate keys \(K\) for the MAC scheme and compute MACs \(T = Tag(K, M_B)\) (for all entrances) and send \((s, M_B, T)\) to Bob (so the simulator replaces the trusted dealer). + +
- Sample a random \(u\) and send it to Bob (replacing the honest Alice) + +
- If Bob does not output anything or output an invalid message, or output a triple \((v', z'_B, t'_B)\) s.t. \(z'_B \neq M_B[u,v]\), the simulator inputs \(y_0\) to the ideal func. Else the sim inputs \(y = v' - s\) to the ideal func. + +
+ - Proof:
+
-
+
- The view of Bob is distributed as the normal scheme, since \(M_B, r\) are uni-random in both experiments and \(u = x+r\) with random \(r\) in the actual protocol, \(u\) is also random. + +
- The output of Alice is distributed identically, except for the case where corrupt Bob sends a triple s.t. \(ver(K[u,v], t'_B, z'_B) = accept\) meanwhile \(z'_B \neq M_B[u,v]\): in which case the real Alice would output \(f(x,y) \oplus 1\) as previously discussed, but the ideal Alice would output \(f(x,y_0)\). This Bob can however be turned into an adversary for the underlying MAC scheme, which is assumed to be secure, thus completing the proof. + +
+
+ - Possible MAC scheme++
-
+
- As Bob only sees a single MAC for each key, we can use a simple information theoretic MAC scheme which is simply a linear function:
+
-
+
- \(k \leftarrow Gen()\): Sample \(k = (\alpha, \beta) \leftarrow Z^2_p\) for a prime \(p\) + +
- \(t \leftarrow Tag(k, m)\): Compute a tag \(t\) on a message \(m\) with key \(k = (\alpha, \beta)\); \(t = \alpha \cdot m + \beta\) + +
- \(\{accept, reject\} \leftarrow ver(k,t,m)\): Output accept if \(t' = \alpha \cdot m + \beta\), reject ow. + +
+
- As Bob only sees a single MAC for each key, we can use a simple information theoretic MAC scheme which is simply a linear function:
+
+
+1.4.2 BeDOZa
+
+
+-
+
- Works with an \(m\)-homomorphic MAC scheme, so likely just bring this up for the last topic, which only has one paper otherwise! + +