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

From Secrecy to Soundness: Efficient Verification via Secure Computation

Benny Applebaum WeizmannYuval Ishai Technion/UCLAEyal Kushilevitz Technion

Delegating Computation

computationally weak

Input: x

Goal: compute y=f(x)

xClient Provider

y=f(x)

y

Delegating Computation

computationally weak

Input: x

Goal: compute y=f(x)

xClient Provider

yf(x)

y

Verifiable Computation: Client detects cheating

Correctable Computation: Client corrects “random” errors

y=f(x)

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,…]

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

Plan

• Formal definitions

• Techniques (only for VC)

- Classical approach

- Our approach

• Applications

• Correctable Computation

Verifiable Computation (VC)

x

Client Honest Provider

output

•Correctness: If P is honest:x, output=f(x)

y

z=P(y)

VC for f

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

zP(y)

VC for f

Plan

• Formal definitions

• Techniques (only for VC)

- Classical approach

- Our approach

• Applications

• Correctable Computation

Secrecy Soundness: The classical way

Tools:

1. Random self-reducibility:

- randomization: h random h’

- recovery: Given DLOG(h’) DLOG(h)

Secrecy Soundness: The classical way

h

Client ProviderVC for DLOG [BLR]

Given h find e s.t ge=h

taken from cyclic group G with generator g

=hgr where r is random

= DLOG(h’) - r

Tools:

1. Random self-reducibility

2. Generate Random Solved Instance: (gs,s) where s is random

Secrecy Soundness: The classical way

h

Client ProviderVC for DLOG [BLR]

Given h find e s.t ge=h

taken from cyclic group G with generator g

• Soundness: If pair is randomly permuted then cheater is detected w.p ½.

• Amplify soundness via parallel repetition

Secrecy Soundness: The classical way

h

Client ProviderVC for DLOG [BLR]

hgr

(a, b)=DLOG(hgr, gs)

Given h find e s.t ge=hIf bs output ; otherwise, output a-r.

gs( , )

• Soundness: If pair is randomly permuted then cheater is detected w.p ½.

• Amplify soundness via parallel repetition

Secrecy Soundness: The classical way

h

Client ProviderVC for DLOG [BLR]

If “dummies” are consistent then recover real

Solved InstancesRerandomization

• 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 ProviderVC for DLOG [BLR]

If “dummies” are consistent then recover real

Solved InstancesRerandomization

Our Approach

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)

Tool 1: Randomized Encoding

x

Client ProviderRandomized 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)

Tool 1: Randomized Encoding

x

Client ProviderRandomized 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)

Tool 2: Message Authentication CodeSigner Forger

Goal: new pair (w, MACk(w))

• MAC: (key k, message y) signature MACk(y)

• 1-time security: given (y,MACk(y)) can’t forge new pair

• E.g., pair-wise independent hash function

MACk(y)

y

MACk

RE+MAC VC

x

Client Provider

a=f(x), b=Dec(g(x,k;r)(

If b=MACk(a) output a

x, g(x,k;r)

• Idea: Ask P to compute f(x) + signature MACk(f(x)) and verify consistency

• P should not know the key k !

• Define the the mapping (x,k)MACk(f(x))

• Let g(x,k;r) be an RE of this mapping

Choose k

Encodes MACk(f(x))

RE+MAC VC

x

Client Provider

a=f(x), b=Dec(g(x,k;r)(

If b=MACk(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 MACk(f(x))

RE+MAC VC

x

Client Provider

af(x), b=MACk(a)

If b=MACk(a) output a

x, g(x,k;r)

Encodes MACk(f(x))

• Correctness: follows from correctness of RE

• Soundness: If P is able to cheat then can forge the MAC

MACk(y)Encodes MACk(f(x))

RE+MAC VC

x, y=f(x),

Provider

af(x), b=MACk(a)

(a,b)

x, g(x,k;r)Sim(MACk(y))

x

MACk

• Correctness: follows from correctness of RE

• Soundness: If P is able to cheat then can forge the MAC

Our Approach vs. Classical Approach

f(x), MACk(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

Applications

Application 1: VC for Arithmetic Computation

First VC for Arithmetic computation

– f:Fn 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

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

Correctable Computation

Correctable Verifiable Computation (CVC)

x

ClientBuggy Provider

output

•Correctness+ Soundness + Correctability:

•If P* is usually correct Client does well on all inputs

•[BLR90] Program correction: 1/3-faulty programBPP-program

y

zP(y) whp

CVC for f

Correctable Verifiable Computation (CVC)

x

ClientBuggy 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

zP(y) whp

CVC for f

If P=f then CVC is program tester/corrector [BLR90]

Parallel Program Verification/Correction

Q: What is the parallel-complexity of verification/correction?

input

output

NC0

constant-depth circuits

bounded fan-in

AC0

constant-depth circuits

unbounded fan-in ANDs

Verification Correction

Many non-trivial

functions [Rubinfeld96]

Any L complete for

NC1, LOG-SPACE

[GGHKR07]

Any L complete for

NC1, LOG-SPACE

[GGHKR07]

Any L complete for

NC1, LOG-SPACE

This work

non-adaptively

O(1) queriesnon-adaptively

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!