Input-Indistinguishable Computation

1. Input-IndistinguishableComputation • Silvio Micali MIT • Rafael Pass Cornell • Alon Rosen Harvard

2. Definitions vs. Protocols x • Crypto in the 20th century – protocols -> definitions • Crypto in the 21st century – definitions -> protocols • This talk: • New definition (input-indistinguishable computation) • For secure two-party computation (malicious). • Definition is“simulation free.” • Inspired bywitness indistinguishability. • New protocol • Concurrency without trustedset-up. • Standard complexity assumptions. • Our motivation is “protocol driven.’’ • We do not achieve “holy grail” of cryptography (yet)… x

3. Delicate balance Modern Crypto Methodology Define security (what it means to break the scheme). Specify adversary in terms of: • computational power, • access to scheme. Construct scheme and prove that breaking it implies solving (assumed) computationally hard problem (e.g. factoring). To reach balance: • Establish feasibility. • Improve efficiency. • Weaken hardness assumption. See if can satisfy a stronger definition (stronger adversary)... Need to convince that: • Definition is meaningful. • Adversary is realistic. • Assumption is reasonable.

4. Alice Alice Bob Bob   PPT B*  PPT S Secure Two-Party Computation REAL IDEAL … YES WELL… If you believe Factoring/DL are hard. • Is definition meaningful? • Is adversary realistic? • Is assumption reasonable? Theorem[Yao, GMW,Kil]: Assuming OT protocol, every efficient two-party function can be securely computed.

5. B B B B B B B B A A A A A A A A A A  UC/General/Self Composition [C,L03,L04] REAL IDEAL • Is definition meaningful? • Is adversary realistic? • Is assumption reasonable? YES YES Maybe, if we just had a protocol… Theorem[CKL, L03, L04]: For most “interesting’’ functions definitions of UC/General/Self composition cannot be achieved.

6. Reference String B B B B A A A A A A  Set-Up Assumptions REAL IDEAL Theorems[CLOS, BCNP, CDPW]: Assuming OT, every efficient two-party function can be securely (UC) computed with some form of trusted set-up. • Meaningful? • Realistic?

7. B B B B B B B B A A A A A A A A A A  Super-Polynomial Time Simulation [P03] REAL IDEAL  PPT B*  PsuperPTS Theorems[PS,BS]: Assuming subexp-hardness (and OT), every eff. two-party function can be securely computed with quasi-poly simulator. • Is definition meaningful? • Is adversary realistic? • Is assumption reasonable? YES in many cases [BS] very sensitive to security parameters [PS] non-standard assumptions

8. Super-Polynomial Time Simulation Super-polynomial time simulation (SPS) is very appealing: • Yields meaningful security guarantee. • Handles a realistic adversary. • Has the potential of being realized • Under standard assumptions. • Without constraints on security parameters. But coming up with such a protocol is still open. We give a definition that can be realized: • Under standard assumptions. • Without constraints on security parameters. • In face of unbounded number of concurrent executions. Definition: Any protocol (A,B) is secure. d.Is (arguably) meaningful for many interesting functions. e. May lead to solution that admits unbounded simulation.

9. Input-Indistinguishable Computation • Correctness. • Input-Independence Privacy Input-Indistinguishability Consider • honestA with input x • malicious B* with input y • B* should get output. ALL inputs of A compatible with output of B* “EQUALLY LIKELY” To distinguish x0,x1must use y* s.t.F(x0,y*) ≠ F(x1,y*) • Trivial if single-input per output • Generalization of Witness-Indist [FS90] What is y*? Implicit input function IN(viewB*) = y*

10. Prover Verifier Witness Indistinguishability [FS90] view(w) = V*’s view of the interaction when P uses w Witness Indistinguishability: for  PPT V*, w0, w1 view(w0)  view(w1) WI property “well-behaved’’ under concurrent composition

11. A P V* B* Interactive Proofs vs. Two-Party Computation • V* has no input B* has input y • V* output is 0/1 B* output is F(x,y*) • P input “hard” to compute A input can be finite

12. Implicit Input Function • Implicit input function INB: • defined on B*’s view of the interaction. • Wlog view depends only on x and on randomness of A • Well defined for all possible views. • Notation: for  PPT B*, x • y* <- INB(view(x)) • Consistency: Output of A = F(x,y*) • Output delivery message: there exists a round in protocol s.t. • Implicit input is fully defined from view so far, but • no “information’’ about output has been released yet. • Implicit input and output round are implicit in ideal/real like definitions, but not required explicitly!

13. Input-Indistinguishable Computation • (A,B) securely computes F w.r.t A if  implicit input function INB s.t. • Completeness: in honest execution of (A,B) • inputs = x,y output = F(x,y) • Input-Independence: for  PPT B*, x0, x1 • INB(view(x0))  INB(view(x1)) • Input-Indistinguishability: for  PPT B*, x0, x1 • y* <- INB(view) • B* can only “distinguish” x0 and x1 when • F(x0,y*) ≠ F(x1,y*) • B* received output in the protocol

14. Input-Indistinguishable Computation (A,B) securely computes F w.r.t A if  implicit input function INB s.t. Completeness: in honest execution of (A,B) inputs = x,y output = F(x,y) Input-Indist. and Indep.: For  PPT B*, x0, x1 Expt0(x0, x1)  Expt1(x0, x1) Expti(x0,x1): view<-view of B* in execution with A(xi) y*<-INB(view) If output = trueand F(x0,y*) ≠ F(x1,y*)  Otherwise (y*,view)

15. Example • Oblivious transfer function. • F((s0,s1),c) = sc • (So x= (s0,s1) and y=c.) • Input independence: c is (computationally) independent of (s0,s1). • Input indistinguishability: Given sc* as output, and view((s0,s1)), the input s1-c* could take any value. • Very meaningful.

16. Concurrent Input Indistinguishable Computation (A,B) securely computes F w.r.t A if  implicit input function INB s.t. Completeness: in honest execution of (A,B) inputs = x,y output = F(x,y) ConcurrentInp-Indist. and Indep.: For  PPT B*, x0, x1 Expt0(x0, x1)  Exp1(x0, x1) Basic Concurrency: • Same Protocol (self composition) •  fixed inputs sequences • Can be extended to handle arbitrary corruptions.

17. Composibility • Unlike WI (and UC) input-indistiguishability does not compose in general. • There exist protocols that are • stand-alone input indistinguishable, but • not concurrent input indistinguishable (even for two executions). • The problem is the potential malleability of (A,B). • Any solution must take malleability into consideration. • Turns out that insuring non-malleability is sufficient!

18. Main Theorem • Theorem:Suppose there exist (trapdoor) claw-free permutations. Then for any efficient 2-party function F, there exists a concurrent input-indistinguishable protocol for computing F. • Trapdoor claw-free permutations: • Required for OT, CRH, perfectly hiding commitments. • Follow from hardness of Factoring/DL.

19. High-Level Idea of Protocol Yao’s protocol secure against honest-but-curious. Compile a’ la GMW, but: • Instead of normal ZK, NMZK protocols of [P04][PR05] • Instructions of NMZK depend on identity of prover. • Different provers have different identities. • Provable Determinism[LMS04]: once first message sent, only one possible continuation (except for ZK). • And some more… Let (A,B) denote resulting protocol.

20. Analysis Lemma: (A,B) is (stand-alone) ideal/real secure. Lemma: Stand-alone ideal/real -> stand-alone inp.-ind. • Implicit input is the value fed to trusted party. • Requires augmenting outputs of ideal/real w/ input of B*. • Relies on existence of output delivery message. • B*,D breaking inp.-ind. -> B**,D breaking ideal/real. Lemma: (A,B) stand-alone inp.-ind. -> (A,B) conc. inp.-ind. • Implicit inputs same as in stand-alone. • Interplay between Hybrid argument and Simulation • Mixture of Black-box and Non black-box [PR05].

21. S ~ ~ ~ w2 wm w1 ZKIDm ZKID2 ZKID1 ~ ~ ~ One-many Simulation-Extractable ZK [PR05] • Left interaction: simulate only one ZK execution. • Right interaction: concurrently extract witnesses from many executions. B* ZKID

22.  Concurrent -> Stand-Alone • Assume existence of concurrent adversary B*, and x, x s.t. corresponding EXPT can be distinguished. • Construct B** that violates stand-alone inp.-ind. Of (A,B). } x1 x1 B* x2 x2 (view,y*) - (view,y*) xm xm

23. B** Concurrent -> Stand-Alone x1 M xi or xi xm Using a hybrid argument. Only need to simulate the ZK proof in the ith execution. Requires to extract all y*.

24. Comparison

25. Summary • Zero-knowledge (simulation paradigm) seems to have “hit the wall” with respect to protocol composition. • Maybe [Goldreich Micali Wigderson87] has made us “too ambitious…” • Perhaps we should • Give up in meaningfulness of definitions. • Super polynomial-time simulators [P03, PS04, BS05]. • Based on indistinguishability [FS90]. • Give up in generality of definitions. • Be meaningful only in specific cases. • Secure protocols for specifictasks [PR05,BPS06].

26. Thank You!