When encrypting the plaintext request in Dual Execution 2PC, the User can avoid the inherent 1-bit leakage of her plaintext by having the Notary give up his private inputs at the end of the TLSNotary session and also introducing some correctness checks. The technical steps of this approach are given below.


The User wants to encrypt a TLS request with some server, but she doesn't have the encryption key. Rather she has just one share of the key. The Notary has the other share. The Notary needs to know that the only ciphertext sent to the TLS server is the ciphertext he has seen (it would be bad, e.g., if the User had the full key because she'd lie to the Notary about the request she sent). We want a 2PC scheme that will allow the User and Notary to collaboratively compute the ciphertext such that: the User does not reveal her plaintext or key share, and the Notary does not reveal his key share.


We make two observations. Firstly, a small amount of keyshare leakage is tolerable. For example, if the Notary leaks 3 bits of their keyshare, it gives the User no meaningful advantage in any attack, as she could have simply guessed the bits correctly with % probability and mounted the same attack.

Secondly, we observe that the Notary's keyshare is an ephemeral secret: it is only private for the duration of the User's TLS session. This implies two things:

  1. The User is free to learn the encryption key after she has received and committed to the TLS response. Thus, if the parties wait until the end of the TLS session to do maliciousness checks, then they can reap the benefits of the Notary having no private inputs.
  2. Since the encryption key is not a long-term secret, it is okay if a malicious User prematurely learns the entire key, so long as it is detected. Thus, the parties are free to engage in potentially leaky MPC early on, so long as checks are performed at some point.


  • is the User's plaintext request
  • is the AES key
  • and are the User's and Notary's AES keyshares, respectively. That is, .
  • denotes the encryption algorithm used by the TLS session
  • denotes a pseudorandom generator
  • denotes a binding commitment to the value

Ideal functionality

We define the ideal functionality we wish to instantiate. In words, the functionality uses the parties' keyshares to encrypt the User's TLS request, and send the ciphertext to both parties. The functionality then waits for the user to get and commit to the TLS response, and then releases the encryption key to the User.

Ideal functionality for ONESHOTENC:

  1. User → ℱ:
  2. Notary → ℱ:
  3. ℱ → User:
  4. ℱ → Notary:
  5. User → ℱ:
  6. ℱ → User:
  7. ℱ → Notary:


We now describe the protocol at a high level. It is based on Figure 1 of the Dual-Execution (DualEx) technique with a relaxation (see Step 3 below). We overcome DualEx's inherent leakage by introducing a consistency check which the User performs on the Notary, thus removing the ability to leak the User's input. It is still possible for a malicious User to leak the Notary's input (i.e. the AES key share), but it gives her no meaningful advantage as per the first observation above.

Part 1

To set up for dual-execution, the parties set up the OTs. Because we have a privacy-free step later, the Notary's OT needs to be opened up later, so we have the notary do a "committed OT" (see section 2 of JKO13), so that he can be forced to open the labels later on.

In the first step of the protocol, the User has to get her AES ciphertext from the Notary. The User does not trust the Notary (for privacy or integrity), and the User's data is far more sensitive to leakage than the Notary's. So the parties do an ordinary DualEx:

  1. The User and Notary both garble a copy of the encryption circuit, and do OTs for each other. For committed OT the Notary constructs the input wire labels and OT encryption keys as where is a randomly sampled PRG seed, and sends to the User after the OT is done.

  2. The User sends her garbled encryption circuit and garbled wires for and . She also sends the output decoding information.

  3. The Notary uses his OT values to evaluate the circuit on . He derives the encoded ciphertext and decodes it into ciphertext using output decoding information.1

    Since the encoding itself may leak the Notary's private input, we need to briefly describe how the encoding is constructed and how we prevent the leakage.

    In garbled circuits, the garbler assigns a pair of encodings (called "labels") to each output bit : the "zero label" when is 0 and the "one label" when is 1. Upon the evaluation, the evaluator will learn only one of those two labels - the so-called evaluator's "active label".

    To prevent the leakage, the Notary will receive from the User a hash commitment to each label. Then the Notary will hash his active label and check that the hash matches one of the two commitments for that output bit. Note that this commitment approach leaks Notary's input bits (the input is the keyshare) with probability , which is acceptable for our case as explained in the first observation above.

  4. The Notary sends to the User.2

    Step 3 is a relaxation of DualEx. In DualEx, the User would not learn the Notary's evaluation output at this point. As mentioned earlier, in TLSNotary protocol's setting, we are not worried that may leak the Notary's input, as long as this behaviour will be detected later. Also we are not worried about DualEx's inherent 1-bit leakage since it gives no meaningful advantage to the User as explained earlier.

    There is no wiggle room for the User to exploit this relaxation because she is locked into using the inputs she received via OT in Step 0 and she has to pass the DualEx equality check which will follow later in Step 14.

  5. As per DualEx, now the Notary knows what the User's encoded output should be, so the Notary computes and keeps it.

  6. The User decodes and derives the ciphertext .


Note that it is in keeping with the DualEx paper to allow a party to send the wrong output decoding information, or to provide different inputs to the two circuit evaluations. This does not affect the security of DualEx.


A question may arise at this point re Step 3: why doesn't the Notary simply send to the User. The reason is that the Notary could send a maliciously crafted : the Notary could flip a bit in (which translates into flipping a bit in the plaintext). The User would then forward the malicious to the server.

At this point, the Notary (even if malicious) has learned nothing about the key or the plaintext. He has only learned the ciphertext.

Also at this point, the User has learned the ciphertext, and, if malicious, has potentially learned the entire key . As mentioned in the second observation above, it is okay if the User was malicious and learned , but the Notary has to detect it and then abort the rest of the TLSNotary protocol. Before this step, the Notary waits for the User to complete their TLS session:

Part 2

  1. The User completes her TLS session and sends

Part 3

Now that the session is over and is no longer secret, the Notary can switch to privacy-free garbling for the second part of DualEx.

  1. The Notary sends his garbled encryption circuit to the User, as well as the garbled wires for . He also sends the output decoding information.

  2. The User evaluates the circuit on and , using the OT values from step 0, derives the encoded ciphertext and decodes it into ciphertext using output decoding information.

  3. As per DualEx, she computes and sends a commitment to the Notary.

    Note that at this stage the Notary could reveal and the User would make sure that . Then likewise the User would reveal and the Notary would make sure that . As per the DualEx's inherent 1-bit leakage, the very act of performing the equality check would leak 1 bit of the User's input to a malicious Notary. To avoid the leakage, the User must first check the consistency of the Notary's OT and garbled circuits:

  4. The Notary reveals all the wire labels and OT encryption keys by opening .

  5. The User checks that the opening is correct, and that is consistent with the OT ciphertexts sent earlier by the Notary. On success, she opens her commitment, sending and the commitment's randomness to the notary.

    With the consistency check passed, the parties resume the DualEx's equality check:

  6. The Notary send .

  7. The User asserts that . The User decommits by sending .

  8. The Notary checks the decommitment and asserts that .