# Dual Execution with Asymmetric Privacy - tlsn-docs

# 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] [HKE12], 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].

### 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 Enc(x,[X])=[x].
- comx​ denotes a binding commitment to x
- G denotes a garbled circuit for computing f(x,y)=v, where:
  - Gb([X],[Y])=G
  - Ev(G,[x],[y])=[v].
- d denotes output decoding information where De(d,[v])=v
- Δ denotes the global offset of a garbled circuit where ∀i:[x]i1​=[x]i0​⊕Δ
- PRG denotes a secure pseudo-random generator
- 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 GA​ with corresponding input labels ([X]A​,[Y]A​), and output label commitment com[V]A​​.
2. Bob creates a garbled circuit GB​ with corresponding input labels ([X]B​,[Y]B​).
3. For committed OT, Bob picks a seed ρ and uses it to generate all random-tape for his OTs with PRG(ρ). Bob sends comρ​ 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 GA​, [x]A​, dA​ and com[V]A​​ to Bob.
7. Bob sends GB​, [y]B​, and dB​ to Alice.

### Execution

Both Alice and Bob can execute this phase of the protocol in parallel as described below:

#### Alice

8. Evaluates GB​ using [x]B​ and [y]B​ to acquire [v]B​.
9. Decodes [v]B​ to vB using dB​ which she received earlier. She computes H([vB]A​,[v]B​) which we will call checkA​.
10. Computes a commitment Com(checkA​,r)=comcheckA​​ where r is a key only known to Alice. She sends this commitment to Bob.
11. Waits to receive [v]A​ from Bob1.
12. Checks that [v]A​ is authentic, aborting if not, then decodes [v]A​ to vA using dA​.

At this stage, if Bob is malicious, Alice could detect that vA=vB. However, Alice must not react in this case. She proceeds with the protocol regardless, having the authentic output vA.

#### Bob

13. Evaluates GA​ using [x]A​ and [y]A​ to acquire [v]A​. He checks [v]A​ against the commitment com[V]A​​ which Alice sent earlier, aborting if it is invalid.
14. Decodes [v]A​ to vA using dA​ which he received earlier. He computes H([v]A​,[vA]B​) which we'll call checkB​, and stores it for the equality check later.
15. Sends [v]A​ to Alice1.
16. Receives comcheckA​​ from Alice and stores it for the equality check later.

Bob, even if malicious, has learned nothing except the purported output vA 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]. 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 for more detail.

### Equality Check

17. Bob opens his garbled circuit and OT by sending ΔB​, y and ρ to Alice.
18. Alice, can now derive the purported input labels to Bob's garbled circuit ([X]B∗​,[Y]B∗​).
19. Alice uses ρ to open all of Bob's OTs for [x]B​ and verifies that they were performed honestly. Otherwise she aborts.
20. Alice verifies that GB​ was garbled honestly by checking Gb([X]B∗​,[Y]B∗​)==GB​. Otherwise she aborts.
21. Alice now opens comcheckA​​ by sending checkA​ and r to Bob.
22. Bob verifies comcheckA​​ then asserts checkA​==checkB​, aborting otherwise.

Bob is now convinced that vA is correct, ie f(x,y)=vA. 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] is recommended reading on this topic.

During the first execution, Alice has some degrees of freedom in how she garbles GA​. 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 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 GA​.

[DPB18] shows that any undetectable corruption made to GA​ is constrained to the arbitrary insertion or removal of NOT gates in the circuit, such that GA​ computes fA​ instead of f. Note that any corruption of dA​ 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 GA​ matches the output of GB​, or more specifically:

fA​(x1​,y1​)==fB​(x2​,y2​)

For the moment we'll assume Bob garbles honestly and provides the same inputs for both evaluations.

fA​(x1​,y)==f(x2​,y)

In the scenario where Bob reveals the output of fA​(x1​,y) prior to Alice committing to x2​ there is a trivial adaptive attack available to Alice. As an extreme example, assume Alice could choose fA​ such that fA​(x1​,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 x2​ where f(x2​,y)=y in order to pass the equality check.

To address this, Alice is forced to choose fA​, x1​ and x2​ prior to Bob revealing the output. In this case it is obvious that any valid combination of (fA​,x1​,x2​) 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.

### Malicious Bob

Zero-Knowledge Using Garbled Circuits [JKO13] is recommended reading on this topic.

The last stage of our variant is functionally equivalent to the protocol described in [JKO13]. After Alice evaluates GB​ 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.