refactor: deap functionality #123
Conversation
There was a problem hiding this comment.
Looking good. I have not yet reviewed the functionality box, because I was hoping there is a chance that we can have a little more explanation what the symbols and their meanings are.
Currently I feel that there is a little disconnect between the binary_arithmetic.md which is less formal and the functionality box which is very formal.
Maybe it makes sense to have a small informal text going through the steps of the functionality and mentioning the symbols and their meaning.
|
|
||
| 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: |
There was a problem hiding this comment.
I think it would be helpful to have an intuitive understanding what many of those symbols are. This does not have to be part of the functionality box but could be placed into the text of binary_arithmetic.md
There was a problem hiding this comment.
Yeah a notation section makes sense
|
|
||
| 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. |
There was a problem hiding this comment.
Is it really a sacrifice? Can't we call it an optimization because privacy is only required in one direction?
This PR updates our documentation on DEAP.
Rendered