Download presentation

Presentation is loading. Please wait.

Published byKeenan Marksbury Modified about 1 year ago

1
From Secrecy to Soundness: Efficient Verification via Secure Computation Benny Applebaum Weizmann Yuval Ishai Technion/UCLA Eyal KushilevitzTechnion

2
Delegating Computation computationally weak Input: x Goal: compute y=f(x) x Client Provider y=f(x) y

3
Delegating Computation computationally weak Input: x Goal: compute y=f(x) x Client Provider y f(x) y Verifiable Computation: Client detects cheating Correctable Computation: Client corrects “random” errors y=f(x)

4
Verifiable/Correctable Computation Old problem - Interactive proofs [Bab,GMR85], program checking [BK89,BLR90,Lip91] New motivation - Weak devices are common (e.g., smart phones, netbooks) - Strong servers are available (e.g., cloud computing, SETI@Home) - Relevant for functions in poly-time General framework with many variants - Complexity of the client, provider, adversary, interaction,… - Many works [Micali94, GGHKR07/8, GKR08, GGP10,CKV10,…]

5
Our Contribution New generic approach: verifiable/correctable computation from secure multiparty computation (MPC) Get soundness from secrecy Applications of generic approach: - New VC/CVC protocols - Simplification & generalization of old protocols

6
Plan Formal definitions Techniques (only for VC) - Classical approach - Our approach Applications Correctable Computation

7
Verifiable Computation (VC) x Client Honest Provider output Correctness: If P is honest: x, output=f(x) y z=P(y) VC for f

8
Verifiable Computation (VC) x Client Cheating Provider Correctness: If P is honest: x, output=f(x) Soundness: cheating P*, x Pr[output {f(x), }]> 1-2 -t y z P(y) VC for f

9
Plan Formal definitions Techniques (only for VC) - Classical approach - Our approach Applications Correctable Computation

10
Secrecy Soundness: The classical way

11
Tools: 1. Random self-reducibility: - randomization: h random h ’ - recovery: Given DLOG(h ’ ) DLOG(h) Secrecy Soundness: The classical way h Client Provider VC for DLOG [BLR] Given h find e s.t g e =h taken from cyclic group G with generator g = h g r where r is random = DLOG(h ’ ) - r

12
Tools: 1. Random self-reducibility 2. Generate Random Solved Instance: (g s,s) where s is random Secrecy Soundness: The classical way h Client Provider VC for DLOG [BLR] Given h find e s.t g e =h taken from cyclic group G with generator g

13
Soundness: If pair is randomly permuted then cheater is detected w.p ½. Amplify soundness via parallel repetition Secrecy Soundness: The classical way h Client Provider VC for DLOG [BLR] hgrhgr (a, b)=DLOG(h g r, g s ) Given h find e s.t g e =h If b s output ; otherwise, output a-r. gsgs (, )

14
Soundness: If pair is randomly permuted then cheater is detected w.p ½. Amplify soundness via parallel repetition Secrecy Soundness: The classical way h Client Provider VC for DLOG [BLR] If “dummies” are consistent then recover real Solved Instances Rerandomization

15
Soundness: If pair is randomly permuted then cheater is detected w.p ½. Amplify soundness via parallel repetition Generally: Random-Self-Reducibility+ Solved Instance Generator (SIG) More Generally: Instance Hiding Protocol + SIG Specific instantiations used by [BLR90,Feig93,GGHKR07,08,CKV10] Secrecy Soundness: The classical way h Client Provider VC for DLOG [BLR] If “dummies” are consistent then recover real Solved Instances Rerandomization

16
Our Approach

17
Tool 1: Randomized Encoding x Client Provider Goal: Provider should learn f(x) without learning x Non-Trivial if Client is too weak to compute f(x) a f(x)

18
Tool 1: Randomized Encoding x Client Provider Randomized Encoding [IK00] Dec(a)=f(x) The distribution of a=g(x;r) ”encodes” f(x) Correctness: there exists a decoder Dec s.t Dec(a)=f(x) Secrecy: The distribution of a depends only on f(x) - There exists a simulator Sim s.t Sim(f(x)) a a=g(x;r) f(x) g(x;r)

19
Tool 1: Randomized Encoding x Client Provider Randomized Encoding [IK00] Dec(a)=f(x) The distribution of a=g(x;r) ”encodes” f(x) [IK00] RE useful tool for secure multiparty computation Many MPC protocols implicitly/explicitly give RE a=g(x;r) f(x) g(x;r)

20
Tool 2: Message Authentication Code Signer Forger Goal: new pair (w, MAC k (w)) MAC: (key k, message y) signature MAC k (y) 1-time security: given (y,MAC k (y)) can’t forge new pair E.g., pair-wise independent hash function MAC k (y) y MAC k

21
RE+MAC VC x Client Provider a=f(x), b=Dec(g(x,k;r)( If b=MAC k (a) output a x, g(x,k;r) Idea: Ask P to compute f(x) + signature MAC k (f(x)) and verify consistency P should not know the key k ! Define the the mapping (x,k) MAC k (f(x)) Let g(x,k;r) be an RE of this mapping Choose k Encodes MAC k (f(x))

22
RE+MAC VC x Client Provider a=f(x), b=Dec(g(x,k;r)( If b=MAC k (a) output a x, g(x,k;r) Correctness: follows from correctness of RE Soundness: If P is able to cheat then can forge the MAC Choose k Encodes MAC k (f(x))

23
RE+MAC VC x Client Provider a f(x), b=MAC k (a) If b=MAC k (a) output a x, g(x,k;r) Encodes MAC k (f(x)) Correctness: follows from correctness of RE Soundness: If P is able to cheat then can forge the MAC

24
MAC k (y) Encodes MAC k (f(x)) RE+MAC VC x, y=f(x), Provider a f(x), b=MAC k (a) (a,b) x, g(x,k;r) Sim(MAC k (y)) x MAC k Correctness: follows from correctness of RE Soundness: If P is able to cheat then can forge the MAC

25
Our Approach vs. Classical Approach f(x), MAC k (f(x)) Compute MAC x, RE(MAC(f(x)) Secrecy: used to hide MAC’s key Efficiency: Good soundness at low cost Requirements: - Pro: doesn’t need SIG -Con: RE is “harder” to achieve than IH Compare t values IH SIG IH… Secrecy: used to hide inputs Efficiency: Big overhead - 2 -t soundness requires t repetitions Requirements: -Con: SIG may be hard to get [G+08] - Pro: IH is quite liberal

26
Applications

27
Application 1: VC for Arithmetic Computation First VC for Arithmetic computation –f:F n F where F is field/ring –f represented as an arithmetic branching program –Previous works: Convert to Boolean circuit expensive ! –Our protocol: treats F as a black-box

28
Application 2: VC for Boolean Circuits Thm. VC for any Boolean circuit C:{0,1} n {0,1} m soundness error negl(t) where t is security parameter offline complexity |C|t online complexity nt+m |C|t nt+mt [GGP] This work |C|t (only computation) nt+mt [CKV] output offline y z x

29
Correctable Computation

30
Correctable Verifiable Computation (CVC) x Client Buggy Provider output Correctness+ Soundness + Correctability: If P* is usually correct Client does well on all inputs i.e., Pr[P*(Y)=P(Y)]> 2/3 x Pr[output =f(x)]> 0.99 y z P(y) whp CVC for f If P=f then CVC is program corrector [BLR90]

31
Correctable Verifiable Computation (CVC) x Client Buggy Provider output Correctness+ Soundness + Correctability: If P* is usually correct Client does well on all inputs [BLR90] Program correction: 1/3-faulty program BPP-program y z P(y) whp CVC for f

32
Correctable Verifiable Computation (CVC) x Client Buggy Provider output Classical Approach for CVC from IH+SIG In some cases SIG is a bottleneck We use RE+one-time pad to get rid of SIG(See paper) y z P(y) whp CVC for f If P=f then CVC is program tester/corrector [BLR90]

33
Parallel Program Verification/Correction Q: What is the parallel-complexity of verification/correction? input output NC 0 constant-depth circuits bounded fan-in AC 0 constant-depth circuits unbounded fan-in ANDs Verification Correction Many non-trivial functions [Rubinfeld96] Any L complete for NC 1, LOG-SPACE [GGHKR07] Any L complete for NC 1, LOG-SPACE [GGHKR07] Any L complete for NC 1, LOG-SPACE This work non-adaptively O(1) queries non-adaptively

34
Conclusion New modular approach for VC/CVC Leads to simplifications, generalizations and improvements More applications? Combine with PCP based approaches? Construct practical protocols for specific tasks Future Directions Thank you!

Similar presentations

© 2017 SlidePlayer.com Inc.

All rights reserved.

Ads by Google