refactor: deap functionality

src/SUMMARY.md

@@ -25,10 +25,9 @@
 
 # MPC
 
-- [Key Exchange](./mpc/key_exchange.md)
+- [Binary Arithmetic](./mpc/binary_arithmetic.md)
 - [Finite-Field Arithmetic](./mpc/ff-arithmetic.md)
-- [Dual Execution with Asymmetric Privacy](./mpc/deap.md)
-- [Encryption](./mpc/encryption.md)
+- [Key Exchange](./mpc/key_exchange.md)
 - [MAC](./mpc/mac.md)
 - [Commitments](./mpc/commitments.md)
 

src/mpc/binary_arithmetic.md

@@ -0,0 +1,61 @@
+# Binary Arithmetic
+
+TLS includes cryptographic algorithms which are most efficiently computed over the binary field such as the SHA-256 and AES-128 block ciphers.
+
+Computing such algorithms using MPC can be quite expensive even when employing state-of-the-art protocols. To achieve practical efficiency TLSNotary leverages Dual Execution with Asymmetric Privacy (DEAP) as defined by the $\mathcal{F}_{\text{DEAP}}$ functionality presented below. This functionality is weaker than a perfectly secure functionality and thus can be efficiently realized using existing performant protocols such as garbled circuits in conjunction with a zero-knowledge protocol.
+
+## Introduction
+
+Malicious secure MPC typically comes at the expense of dramatically lower efficiency compared to the semi-honest setting. One technique, called Dual Execution [\[MF06\]](https://www.iacr.org/archive/pkc2006/39580468/39580468.pdf) [\[HKE12\]](https://www.cs.umd.edu/~jkatz/papers/SP12.pdf), achieves malicious security with a minimal 2x overhead. However, it comes with the concession that a malicious adversary may learn $k$ bits of the other's input with probability $2^{-k}$ of the leakage going undetected.
+
+We present a variant of Dual Execution with a weaker security notion in favor of performance, while still satisfying the rather niche security requirements for TLSNotary. Our variant ensures perfect privacy _for one party_, by sacrificing privacy entirely for the other. Hence the name, Dual Execution with Asymmetric Privacy (DEAP). This is a distinct notion from zero-knowledge where only one party provides private inputs. In DEAP both parties can provide private inputs until the finalization procedure.
+
+## Dual Execution with Asymmetric Privacy
+
+Figure 1 defines a functionality $\mathcal{F}_{\text{DEAP}}$ which runs between parties $P_A$ and $P_B$, and an adversary $\mathcal{A}$. The functionality provides an interface akin to a virtual machine, including persistent memory and the ability to execute arbitrary boolean functions.
+
+<div style="text-align: center">
+<table>
+ <tr><td><img src="../diagrams/f_deap.svg"></td></tr>
+ <tr><td>Figure 1: Functionality $\mathcal{F}_{\text{DEAP}}$</td></tr>
+</table>
+</div>
+
+For $P_A$ the functionality provides perfect security with aborts, while $P_B$ receives significantly weaker guarantees.
+
+The adversary is assumed to only corrupt one of the parties, and upon doing so is granted a number of affordances. Despite these affordances, $\mathcal{F}_{\text{DEAP}}$ maintains some key properties.
+
+### Privacy
+
+The functionality provides perfect privacy for the inputs of $P_A$ in the presence of a corrupted $P_B$. Upon corrupting $P_B$ the adversary can at most provide inconsistent inputs in the **Input** procedure. However, $\mathcal{A}$ can not learn any information about $P_A$ inputs as the functionality enforces consistency during the **Finalize** routine prior to performing an equality check on output values.
+
+If $P_A$ is corrupted the inputs of $P_B$ are vulnerable to selective failure attacks by $\mathcal{A}$ prior to calling **Finalize**. The adversary may sample information about inputs provided by $P_B$ during the **Call** procedure using an arbitrary predicate $\text{P}$ at risk of causing an abort. In other words, for every **Call** invocation, $\mathcal{A}$ may sample $k$ input bits provided by $P_B$ with probability $2^{-k}$ of this leakage going undetected.
+
+### Correctness
+
+A key security notion to consider is that of _correctness_, which, loosely speaking, is whether upon receiving a function $f$ in the **Call** routine the functionality correctly computes $f$ and not some alternate function $f'$.
+
+The functionality provides correctness to $P_A$ in the presence of a corrupted $P_B$. As mentioned earlier, the adversary may only replace the inputs of $P_B$ which is of no consequence regarding correctness.
+
+$P_B$ does not enjoy the same notion of correctness if $P_A$ is corrupted. Rather, the adversary is permitted to provide an _arbitrary_ alternate function $f'$ in the **Call** procedure in addition to flipping output values in invocations of **Output**. It is in the **Finalize** procedure that $P_B$ can detect corruptions introduced by $\mathcal{A}$.
+
+### Finalization
+
+The **Finalize** procedure reveals all inputs provided by $P_B$ to $P_A$ and ensures that the adversary $\mathcal{A}$ can not learn any information of $P_A$ inputs by providing inconsistent inputs used in **Call**.
+
+For example, if $P_B$ is corrupted and the adversary causes the input vectors $\bold{\mathbb{x}}_1$ and $\bold{\mathbb{x}}_2$ in **Call** to be inconsistent by exploiting the **Input** procedure, $\mathcal{A}$ could learn if $f(\bold{\mathbb{x}}_1) = f(\bold{\mathbb{x}}_2)$ in Step 4 of **Finalize**. Aborting beforehand if the inputs are inconsistent mitigates this possibility.
+
+As mentioned [earlier](#correctness), $P_B$ is not provided any correctness guarantees in the presence of a corrupted $P_A$ prior to finalization. In leau of that, $P_B$ learns if any _output values_ are inconsistent via an equality check in Step 4. This significantly constrains the adversary while choosing alternate functions in **Call**. To illustrate this consider the following:
+
+Suppose an honest $P_B$ expects to compute the function $f(x, y)$ where $x$ and $y$ are inputs provided by $P_A$ and $P_B$ respectively. Recall that an adversary corrupting $P_A$ may provide inconsistent input values $x_1$ and $x_2$ and an alternate function $f'$:
+
+$$z_1 = f'(x_1, y)$$
+$$z_2 = f(x_2, y)$$
+
+In the extreme case, $\mathcal{A}$ may choose $f'$ such that it simply outputs $y$ and thus learning the input of $P_B$ directly. Indeed this is allowed, however such a corruption will be detected in Step 4 of **Finalize** which notifies $P_B$ if $z_1 \neq z_2$. Given that $\mathcal{A}$ must choose $x_1$, $x_2$ and $f'$ prior to learning the output, for the adversary to avoid detection they must satisfy all constraints on $y$ a priori. Put simply, the adversary may guess $k$ bits of $y$ with probability $2^{-k}$ of it going undetected.
+
+To summarize the above, the finalization procedure ensures a probabilistic leakage bound on the inputs of $P_B$ and also enforces correctness albeit with potentially inconsistent inputs from $P_A$.
+
+## Usage in TLSNotary
+
+TLSNotary uses $\mathcal{F}_{\text{DEAP}}$ such that the `Prover` and `Verifier` are $P_A$ and $P_B$ respectively. This ensures that a corrupted `Verifier` can not extract any private information of the `Prover` nor can it affect the correctness of any of the computations which could lead to malicious state updates in an application. Conversely, a corrupted `Prover` can not prematurely learn the inputs of the `Verifier` nor break correctness in any meaningful way without detection.

src/mpc/deap.md

@@ -1,136 +1 @@
 # Dual Execution with Asymmetric Privacy
-
-TLSNotary uses the `DEAP` protocol described below to ensure malicious security of the overall protocol.
-
-When using DEAP in TLSNotary, the `User` plays the role of Alice and has full privacy and the `Notary` plays the role of Bob and reveals all of his private inputs after the TLS session with the server is over. The Notary's private input is his TLS session key share.
-
-The parties run the `Setup` and `Execution` steps of `DEAP` but they defer the `Equality Check`.
-Since during the `Equality Check` all of the `Notary`'s secrets are revealed to User, it must be deferred until after the TLS session with the server is over, otherwise the User would learn the full TLS session keys and be able to forge the TLS transcript.
-
-## Introduction
-
-Malicious secure 2-party computation with garbled circuits typically comes at the expense of dramatically lower efficiency compared to execution in the semi-honest model. One technique, called Dual Execution [\[MF06\]](https://www.iacr.org/archive/pkc2006/39580468/39580468.pdf) [\[HKE12\]](https://www.cs.umd.edu/~jkatz/papers/SP12.pdf), achieves malicious security with a minimal 2x overhead. However, it comes with the concession that a malicious adversary may learn $k$ bits of the other's input with probability $2^{-k}$.
-
-We present a variant of Dual Execution which provides different trade-offs. Our variant ensures complete privacy _for one party_, by sacrificing privacy entirely for the other. Hence the name, Dual Execution with Asymmetric Privacy (DEAP). During the execution phase of the protocol both parties have private inputs. The party with complete privacy learns the authentic output prior to the final stage of the protocol. In the final stage, prior to the equality check, one party reveals their private input. This allows a series of consistency checks to be performed which guarantees that the equality check can not cause leakage.
-
-Similarly to standard DualEx, our variant ensures output correctness and detects leakage (of the revealing parties input) with probability $1 - 2^{-k}$ where $k$ is the number of bits leaked.
-
-## Preliminary
-
-The protocol takes place between Alice and Bob who want to compute $f(x, y)$ where $x$ and $y$ are Alice and Bob's inputs respectively. The privacy of Alice's input is ensured, while Bob's input will be revealed in the final steps of the protocol.
-
-### Premature Leakage
-
-Firstly, our protocol assumes a small amount of premature leakage of Bob's input is tolerable. By premature, we mean prior to the phase where Bob is expected to reveal his input.
-
-If Alice is malicious, she has the opportunity to prematurely leak $k$ bits of Bob's input with $2^{-k}$ probability of it going undetected.
-
-### Aborts
-
-We assume that it is acceptable for either party to cause the protocol to abort at any time, with the condition that no information of Alice's inputs are leaked from doing so.
-
-### Committed Oblivious Transfer
-
-In the last phase of our protocol Bob must open all oblivious transfers he sent to Alice. To achieve this, we require a very relaxed flavor of committed oblivious transfer. For more detail on these relaxations see section 2 of [Zero-Knowledge Using Garbled Circuits \[JKO13\]](https://eprint.iacr.org/2013/073.pdf).
-
-### Notation
-
-* $x$ and $y$ are Alice and Bob's inputs, respectively.
-* $[X]_A$ denotes an encoding of $x$ chosen by Alice.
-* $[x]$ and $[y]$ are Alice and Bob's encoded _active_ inputs, respectively, ie $\mathsf{Encode}(x, [X]) = [x]$.
-* $\mathsf{com}_x$ denotes a binding commitment to $x$
-* $G$ denotes a garbled circuit for computing $f(x, y) = v$, where:
-  *  $\mathsf{Gb}([X], [Y]) = G$
-  *  $\mathsf{Ev}(G, [x], [y]) = [v]$.
-* $d$ denotes output decoding information where $\mathsf{De}(d, [v]) = v$
-* $\Delta$ denotes the global offset of a garbled circuit where $\forall i: [x]^{1}_i = [x]^{0}_i \oplus \Delta$
-* $\mathsf{PRG}$ denotes a secure pseudo-random generator
-* $\mathsf{H}$ denotes a secure hash function
-
-## Protocol
-
-The protocol can be thought of as three distinct phases: The setup phase, execution, and equality-check.
-
-### Setup
-
-1. Alice creates a garbled circuit $G_A$ with corresponding input labels $([X]_A, [Y]_A)$, and output label commitment $\mathsf{com}_{[V]_A}$.
-2. Bob creates a garbled circuit $G_B$ with corresponding input labels $([X]_B, [Y]_B)$.
-3. For committed OT, Bob picks a seed $\rho$ and uses it to generate all random-tape for his OTs with $\mathsf{PRG}(\rho)$. Bob sends $\mathsf{com}_{\rho}$ to Alice.
-4. Alice retrieves her active input labels $[x]_B$ from Bob using OT.
-5. Bob retrieves his active input labels $[y]_A$ from Alice using OT.
-6. Alice sends $G_A$, $[x]_A$, $d_A$ and $\mathsf{com}_{[V]_A}$ to Bob.
-7. Bob sends $G_B$ and $[y]_B$ to Alice.
-
-### Execution
-
-Both Alice and Bob can execute this phase of the protocol in parallel as described below:
-
-#### Alice
-
-8. Evaluates $G_B$ using $[x]_B$ and $[y]_B$ to acquire $[v]_B$.
-9. Defines $\mathsf{check}_A = [v]_B$.
-10. Computes a commitment $\mathsf{Com}(\mathsf{check}_A, r) = \mathsf{com}_{\mathsf{check}_A}$ where $r$ is a key only known to Alice. She sends this commitment to Bob.
-11. Waits to receive $[v]_A$ from Bob[^1].
-12. Checks that $[v]_A$ is authentic, aborting if not, then decodes $[v]_A$ to $v^A$ using $d_A$.
-
-At this stage, a malicious Bob has learned nothing and Alice has obtained the output $v^A$ which she knows to be authentic.
-
-#### Bob
-
-13. Evaluates $G_A$ using $[x]_A$ and $[y]_A$ to acquire $[v]_A$. He checks $[v]_A$ against the commitment $\mathsf{com}_{[V]_A}$ which Alice sent earlier, aborting if it is invalid.
-14. Decodes $[v]_A$ to $v^A$ using $d_A$ which he received earlier. He defines $\mathsf{check}_B = [v^A]_B$ and stores it for the equality check later.
-15. Sends $[v]_A$ to Alice[^1].
-16. Receives $\mathsf{com}_{\mathsf{check}_A}$ from Alice and stores it for the equality check later.
-
-Bob, even if malicious, has learned nothing except the purported output $v^A$ and is not convinced it is correct. In the next phase Alice will attempt to convince Bob that it is.
-
-Alice, if honest, has learned the correct output $v$ thanks to the authenticity property of garbled circuits. Alice, if malicious, has potentially learned Bob's entire input $y$.
-
-[^1]: This is a significant deviation from standard DualEx protocols such as [\[HKE12\]](https://www.cs.umd.edu/~jkatz/papers/SP12.pdf). Typically the output labels are _not_ returned to the Generator, instead, output authenticity is established during a secure equality check at the end. See the [section below](#malicious-alice) for more detail.
-
-### Equality Check
-
-17. Bob opens his garbled circuit and OT by sending $\Delta_B$, $y$ and $\rho$ to Alice.
-18. Alice, can now derive the _purported_ input labels to Bob's garbled circuit $([X]^{\\*}_B, [Y]^{\\*}_B)$.
-19. Alice uses $\rho$ to open all of Bob's OTs for $[x]_B$ and verifies that they were performed honestly. Otherwise she aborts.
-20. Alice verifies that $G_B$ was garbled honestly by checking $\mathsf{Gb}([X]^{\\*}_B, [Y]^{\\*}_B) == G_B$. Otherwise she aborts.
-21. Alice now opens $\mathsf{com}_{\mathsf{check}_A}$ by sending $\mathsf{check}_A$ and $r$ to Bob.
-22. Bob verifies $\mathsf{com}_{\mathsf{check}_A}$ then asserts $\mathsf{check}_A == \mathsf{check}_B$, aborting otherwise.
-
-Bob is now convinced that $v^A$ is correct, ie $f(x, y) = v^A$. Bob is also assured that Alice only learned up to k bits of his input prior to revealing, with a probability of $2^{-k}$ of it being undetected.
-
-## Analysis
-
-### Malicious Alice
-
-[On the Leakage of Corrupted Garbled Circuits \[DPB18\]](https://eprint.iacr.org/2018/743.pdf) is recommended reading on this topic.
-
-During the first execution, Alice has some degrees of freedom in how she garbles $G_A$. According to \[DPB18\], when using a modern garbling scheme such as \[ZRE15\], these corruptions can be analyzed as two distinct classes: detectable and undetectable.
-
-Recall that our scheme assumes Bob's input is an ephemeral secret which can be revealed at the end. For this reason, we are entirely unconcerned about the detectable variety. Simply providing Bob with the output labels commitment $\mathsf{com}_{[V]_A}$ is sufficient to detect these types of corruptions. In this context, our primary concern is regarding the _correctness_ of the output of $G_A$.
-
-\[DPB18\] shows that any undetectable corruption made to $G_A$ is constrained to the arbitrary insertion or removal of NOT gates in the circuit, such that $G_A$ computes $f_A$ instead of $f$. Note that any corruption of $d_A$ has an equivalent effect. \[DPB18\] also shows that Alice's ability to exploit this is constrained by the topology of the circuit.
-
-Recall that in the final stage of our protocol Bob checks that the output of $G_A$ matches the output of $G_B$, or more specifically:
-
-$$f_A(x_1, y_1) == f_B(x_2, y_2)$$
-
-For the moment we'll assume Bob garbles honestly and provides the same inputs for both evaluations.
-
-$$f_A(x_1, y) == f(x_2, y)$$
-
-In the scenario where Bob reveals the output of $f_A(x_1, y)$ prior to Alice committing to $x_2$ there is a trivial _adaptive attack_ available to Alice. As an extreme example, assume Alice could choose $f_A$ such that $f_A(x_1, y) = y$. For most practical functions this is not possible to garble without detection, but for the sake of illustration we humor the possibility. In this case she could simply compute $x_2$ where $f(x_2, y) = y$ in order to pass the equality check.
-
-To address this, Alice is forced to choose $f_A$, $x_1$ and $x_2$ prior to Bob revealing the output. In this case it is obvious that any _valid_ combination of $(f_A, x_1, x_2)$ must satisfy all constraints on $y$. Thus, for any non-trivial $f$, choosing a valid combination would be equivalent to guessing $y$ correctly. In which case, any attack would be detected by the equality check with probability $1 - 2^{-k}$ where k is the number of guessed bits of $y$. This result is acceptable within our model as [explained earlier](#premature-leakage).
-
-### Malicious Bob
-
-[Zero-Knowledge Using Garbled Circuits \[JKO13\]](https://eprint.iacr.org/2013/073.pdf) is recommended reading on this topic.
-
-The last stage of our variant is functionally equivalent to the protocol described in \[JKO13\]. After Alice evaluates $G_B$ and commits to $[v]_B$, Bob opens his garbled circuit and all OTs entirely. Following this, Alice performs a series of consistency checks to detect any malicious behavior. These consistency checks do _not_ depend on any of Alice's inputs, so any attempted selective failure attack by Bob would be futile.
-
-Bob's only options are to behave honestly, or cause Alice to abort without leaking any information.
-
-### Malicious Alice & Bob
-
-They deserve whatever they get.