Quid-Pro-Quo-tocols Strengthening Semi-Honest Protocols with Dual Execution

Quid-Pro-Quo-tocolsStrengthening Semi-Honest Protocols with Dual ExecutionYan Huang1, Jonathan Katz2, David Evans11. University of Virginia2. University of Maryland

Picture logos instead of footnotesMy talk is about our investigation on using two symmetric executions of Yaos circuit to attain good tradeoffs between security and efficiency.1

Secure Two-Party Computation2

AliceBob

Bobs Genome: ACTGMarkers (~1000): [0,1, , 0]Alices Genome: ACTGMarkers (~1000): [0, 0, , 1]Can Alice and Bob compute a function of their private data, without exposing anything about their data besides the result?Secure computation has been a long-term goal of cryptographers. It enables multiple parties to do arbitrary joint computation over their respective secret inputs. It has various applications in privacy-aware computing such as computational genomics, voting, auction, etc. At present, one big hurdle of its wide deployment is its efficiency.2Encx00, x11(x21)Encx01,x11(x21)Encx01,x10(x21)Encx20, x21(x30)Encx21,x21(x30)Encx21,x20(x31)Encx20, x31(x41)Encx21,x31(x41)Encx21,x30(x40)Encx40, x31(x51)Encx41,x31(x50)Encx41,x30(x50)Encx40, x51(x61)Encx41,x51(x60)Encx41,x50(x60)Encx30, x61(x71)Encx31,x61(x70)Encx31,x60(x71)Faster Garbled Circuits (Semi-honest)3Circuit-Level ApplicationGC Framework(Evaluator)GC Framework (Generator)Circuit StructureCircuit StructurePipelining: gates evaluated as they are generated

Garbled evaluation can be combined with normal execution

Circuit-level optimizationsIn prior work, we applied several effective techniques to boost the performance. Specifically, the idea of pipelining is to require the parties to work on the gates in topologic order and dismiss the memory resource allocated for a gate as soon as it is done. Second, we make the circuit execution use public data whenever it is available. Last, we proposed a framework that facilitates the creation of highly customizable circuit designs.3Results for Semi-honest ProtocolsPerformanceScalability4Applicationsbiometric identification (5x speedup) [NDSS 2011] Hamming distance (4000x), Edit distance (30x), Smith-Waterman,AES Encryption (16x) [USENIX Sec 2011]private set intersection (faster than best custom protocols) [NDSS 2012]Non-free gates per millisecondLargest circuit executed (non-free gates)We found that, in the semi-honest model, with pipelined execution and highly customizable circuit design, we can execute circuits of arbitrary sizes at a speed close to one hundred thousand non-free gates per second over a LAN. The details of general optimizations were published at USENIX Security last year, while some interesting applications presented in our NDSS papers.4Standard Threat ModelsSemi-Honest: Adversary follows the protocol as specified, but tries to learn more from the protocol execution transcript

Malicious: Adversary can do anything, guarantees correctness and privacyReasonable performance, unreasonable assumptionsReasonable assumptions, unreasonable performance5However, one caveat of those results are that they all assumed honest-but-curious adversaries, who followed the protocol specification faithfully. In more realistic settings, people often want the same security guarantee without making this strong adversary assumption. Standard techniques to convert any semi-honest protocols to malicious protocols exist, but incurring prohibitive performance overhead due to ZK proofs or cut-and-choose. On the other hand, some optimization techniques, especially the pipelining technique, that we applied to the semi-honest model might not work directly in presence of malicious adversaries.

In this work, we are going to report our findings on a third threat model that lies in between. The new model does not assume the adversary sticks to the protocol, but provides much better performance than fully-malicious protocols at the cost of leaking a single extra bit of information.5Security PropertiesPrivacyNothing is revealed other than the outputCorrectnessThe output of the protocol is indeed f(x,y)GeneratorEvaluatorMalicious-resistant OTSemi-Honest GCHow can we get both correctness, while maintaining privacy?6Before presenting the solution, lets move one step back to examine more closely the semi-honest garbled circuit protocol.

First, the harmfulness of the two roles are asymmetric in presence of fully malicious adversaries. Lets setup the protocol in such a way that maliciously secure OT is used before garbled circuit execution and that the generator doesnt get anything back from the evaluator. In this setting, the evaluator is really helpless in launching any attacks since it has no influence over the generator. On the contrary, the generator can be much more harmful --- including multiple ways to affect the correctness. For example, cooking an incorrect output for the evaluator is easy, just sending a false mapping of the wire labels. With respect to privacy, the generator actually cant do any harm because it doesnt receive anything from the evaluator. Note that this assumes not information at all goes back, not even an indication if the protocol failed.

In the next few slides, we will look at how to resolve the correctness issue.6How about Dual Execution?

We investigate the approach where the two parties switch roles in garbled circuit execution, so that each party obtains in turn the final result. (although in reality, this model doesnt make much sense because probably no executer would love to switch roles)7Dual Execution Protocol[Mohassel and Franklin, PKC06]AliceBobfirst round execution (semi-honest)generatorevaluatorgeneratorevaluatorsecond round execution (semi-honest)fully-secure equality testBasically, Alice and Bob each will execute a special semi-honest garbled circuit protocol twice. Each time the protocol is executed, the two parties will play a different role. Note the semi-honest garbled circuit is special in that a maliciously-secure oblivious transfer protocol is used.

After the first 2 steps of alternating semi-honest execution, each party gets an output v as an evaluator. So in the 3rd step, they engage themselves in a maliciously-secure equality test protocol to ensure the correctness of previous protocol executions. Notably, this equality test protocol not only needs to be secure against fully malicious adversaries, but also requires the inputs are authenticated to prevent cheating on the inputs vs.

This protocol was first noticed by Mohassel and Franklin back in 2006. In this work, we further fleshed the idea out with some enhancements and a concrete implementation, and gave a security proof.8Security PropertiesCorrectness: guaranteed by authenticated, secure equality testPrivacy: Leaks one (extra) bit on averageadversarial circuit generator provides a circuit that fails on of inputsMalicious generator can achieve either one of the following, but not both 1. Decrease likelihood of being caught, 2. Increase information leaked when caught On average, it is a 1-bit leak.9Now with the protocol overview in mind, it is relatively straightforward to see the security guarantees it provides. We can see as long as the secure equality test passes, a honest party should be confident with the correctness of the his computation output. However, with respect to privacy, we sacrificed one extra bit on average due to revelation of the equality test. Note that, although the outcome could either be that a malicious attacker is caught with an arbitrarily small probability, or becomes very, very certain on its peers secret input, in no circumstances do both occur at the same time.9Equality Test

By comparing the hashes, we guarantee that no one can cheat on their output value got from the circuit execution.10One-sided Equality TestAllows Bob to convince Alice that they share the same secret valueNeed to run this 2-round protocol twice (parallelizable as well) to accomplish the full equality test.

An attacker only gets to guess the initial hash value, but wouldnt be able to cheat an honest party into believing some incorrect output with non-negligible probability.

Can we get rid of the r?11Proving Security: Malicious12ABIdeal WorldyxReceives:f (x, y)Trusted Party in Ideal WorldStandard Malicious Model: cant prove this for Dual ExecutionReal WorldAByxShow equivalenceCorrupted party behaves arbitrarilySecure Computation Protocol12Proof of Security: One-Bit Leakage13ABIdeal Worldyxg R {0, 1}g is an arbitrary Boolean function selected by malicious adversary AAdversary receives:g(x, y) and optionally f (x, y) Trusted Party in Ideal WorldCan prove equivalence to this for Dual Execution protocols1-bit LeakCircuit structure can be checked by evaluator (including free XORs)

Design circuit to limit malicious generators ability to partition input space.

Challenge: can lie about inputs also

14Can we have more confidence on which one bit is not leaked?Open Question:14Delayed RevelationGoal: do not reveal output to either party, unless the equality test passes15

Solution: check equality of output wires using a secure circuit that outputs resultsThis circuit is also executed as a Dual Execution protocol!Dual Execution ProtocolAliceBobfirst round execution (semi-honest)generatorevaluatorgeneratorevaluatorsecond round execution (semi-honest)Recall: work to generate is 3x work to evaluate!16fully-secure equality test16Performance17Circuits of arbitrary sizes can be done this way [Kreuter et al., USENIX Security 2012]17Summaryfirst round execution (semi-honest)second round execution (semi-honest)fully-secure, authenticated equality testProvides full correctness and maximum one-bit average leakage against fully malicious adversaries (formal proof using ideal/real world model)

With pipelining framework, almost free with dual-core, 40-50% over semi-honest protocol with one core.18www.MightBeEvil.org18