Presentation is loading. Please wait.

Presentation is loading. Please wait.

Making proof-based verified computation almost practical Michael Walfish The University of Texas at Austin.

Similar presentations


Presentation on theme: "Making proof-based verified computation almost practical Michael Walfish The University of Texas at Austin."— Presentation transcript:

1 Making proof-based verified computation almost practical Michael Walfish The University of Texas at Austin

2 The motivation is 3 rd party computing: cloud, volunteers, etc. We desire the following properties in the above exchange: 1. Unconditional, meaning no assumptions about the server 2. General-purpose, meaning not specialized to a particular f 3. Practical, or at least conceivably practical soon “f”, x y, aux. clientserver check whether y = f(x), without computing f(x) By verified computation, we mean the following:

3 REJECTACCEPT Unfortunately, the constants and proof length are outrageous. “f”, x y clientserver y’... Theory can supposedly help. Consider the theory of Probabilistically Checkable Proofs (PCPs). [ ALMSS 92, AS 92 ] Using a naive PCP implementation, verifying multiplication of 500×500 matrices would take 500+ trillion CPU years (seriously).

4 We have reduced the costs of a PCP-based argument system [Ishai et al., CCC07] by 20+ orders of magnitude, with proof. We have implemented the refinements in a system that is not ready for prime time but is practical in some cases. We believe that PCP-based machinery will be a key tool for building secure systems in the near future.  S. Setty, B. Braun, V. Vu, A. J. Blumberg, B. Parno, and M. Walfish. Resolving the conflict between generality and plausibility in verified computation. Cryptology ePrint 622, November  S. Setty, V. Vu, N. Panpalia, B. Braun, A. J. Blumberg, and M. Walfish. Taking proof-based verified computation a few steps closer to practicality. Usenix Security, August  S. Setty, R. McPherson, A. J. Blumberg, and M. Walfish. Making argument systems for outsourced computation practical (sometimes). Network and Distributed Systems Security Symposium (NDSS), February  S. Setty, A. J. Blumberg, and M. Walfish. Toward practical and unconditional verification of remote computations. Workshop on Hot Topics in Operating Systems (HotOS), May 2011.

5 (1) The design of P EPPER (2) Experimental results, limitations, and outlook

6 ACCEPT / R EJECT “f”, x clientserver y... The proof is not drawn to scale: it is far too long to be transferred. Pepper incorporates PCPs but not like this: (Even the asymptotically short PCPs [BGHSV CCC05, BGHSV SIJC06, Dinur JACM07, Ben-Sasson & Sudan SIJC08] seem to have high constants.) We move out of the PCP setting: we make computational assumptions. (And we allow # of query bits to be superconstant.)

7 client server... [IKO CCC07 ]... server client commit request commit response q 1  w q 2  w q 3  w … Pepper uses an efficient argument [Kilian CRYPTO 92,95] : Instead of transferring the PCP … q 1, q 2, q 3, … PCPQuery(q){ return ; } ACCEPT / REJECT efficient checks [ALMSS JACM98 ] queries

8 The server’s vector w encodes an execution trace of f(x). w f ( ) What is in w ? (1)An entry for each wire; and (2)An entry for the product of each pair of wires. x x0x0 x1x1 xnxn … y0y0 y1y [ALMSS JACM98]

9 [IKO CCC07 ]... server client commit request commit response q 1  w q 2  w q 3  w Pepper uses an efficient argument [Kilian CRYPTO 92,95] : q 1, q 2, q 3, … PCPQuery(q){ return ; } ACCEPT / REJECT [ALMSS JACM98 ] queries This is still too costly (by a factor of ), but it is promising. efficient checks

10 “f” y client server w commit request commit response, x query vectors: q 1, q 2, q 3, … response scalars: q 1  w, q 2  w, q 3  w, … ACCEPT / REJECT checks queries P EPPER incorporates refinements to [IKO CCC07], with proof.

11 query vectors: q 1, q 2, q 3, … w1w2w3w1w2w3 client server The client amortizes its overhead by reusing queries over multiple runs. Each run has the same f but different input x.

12 “f” y client server response scalars: q 1  w, q 2  w, q 3  w, … w commit request commit response, x query vectors: q 1, q 2, q 3, … ACCEPT / REJECT checks queries ✔

13 Boolean circuit Arithmetic circuit Arithmetic circuit with concise gates × × × × abab  abab abab something gross Unfortunately, this computational model does not really handle fractions, comparisons, logical operations, etc.

14 If the output is 7 … … there is a solution An incorrect input/output pair results in unsatisfiable constraints. 0 = X = Y - (X + 1) 0 = Y - 7 We now work with (degree-2) constraints over a finite field. Increment(X) Y=X = X -, 0 = Y - (X+1), 0 = Y - As an example, suppose the input above is 6. If the output is 8 … … there is no solution 0 = X = Y - (X + 1) 0 = Y - 8

15 This formalism represents general-purpose program constructs concisely: if/else, !=,, ||, &&, floating-point, … “Z 1 != Z 2 ” 1 = (Z 1 – Z 2 )  M if (bool X) Y=3 else Y=4 0 = X - M Y = M  3 + (1-M)  4 We have a compiler that does this transformation; it is derived from Fairplay [Malkhi et al. Usenix Security04]. This work should apply to other protocols.

16 Z 1 =23, Z 2 =187, …, w w The proof vector now encodes the assignment that satisfies the constraints. Take-away: constraints are general-purpose, (relatively) concise, and accommodate the verification machinery = (Z 1 – Z 2 )  M 0 = Z 3 − Z 4 0 = Z 3 Z 5 + Z 6 − 5 The savings from the change are enormous (though the new model is not perfect – loops are still unrolled).

17 “f” y client server w commit request commit response, x query vectors: q 1, q 2, q 3, … ✔ response scalars: q 1  w, q 2  w, q 3  w, … ACCEPT / REJECT checks queries ✔

18 w server We (mostly) eliminate the server’s PCP-based overhead. before: # of entries quadratic in computation size after: # of entries linear in computation size Now, the server’s overhead is mainly in the cryptographic machinery and the constraint model itself. The client and server reap tremendous benefit from this change.

19 |w|=|Z| 2 PCP verifier This resolves a conjecture of Ishai et al. [ IKO CCC07 ] For any computation, there exists a linear PCP whose proof vector is (quasi)linear in the computation size. [Gennaro et al. 2012] linearity test quad corr. test circuit test commit request commit response queries responses π(q 1 ), …, π(q u ) π(  )= q 1, q 2, …, q u (z, z ⊗ z) (z, h) server client new quad.test |w|=|Z|+|C| w w

20 “f”, x y client server commit request commit response query vectors: q 1, q 2, q 3, … w ✔ ✔ ✔ response scalars: q 1  w, q 2  w, q 3  w, … checks queries ACCEPT / REJECT

21 linearity test quad. test We prove: commitment primitive is (far) stronger than linearity test commit request commit response consistency test queries responses PCP verifier client We eliminate linearity tests. linearity: π(q 1 ) + π(q 2 ) = π(q 1 +q 2 ) Enc(r) consistency: t = r + α 1  q 1 + … + α u  q u π(t) = π(r) + α 1  π (q 1 ) + … + α u  π (q u ) ? ? Enc(π(r)) π(t) π(  ) q 1, q 2, …, q u server t π(q 1 ), …, π(q u ) ? We eliminate soundness amplification (repetition to reduce error). ≣

22 “f”, x y client server commit request commit response query vectors: q 1, q 2, q 3, … w ✔ ✔ ✔ response scalars: q 1  w, q 2  w, q 3  w, … checks queries ACCEPT / REJECT ✔ ✔

23 (1) The design of P EPPER (2) Experimental results, limitations, and outlook ✔

24 Our implementation of the server is massively parallel; it is threaded, distributed, and GPUed. Some details of our evaluation platform:  It uses a cluster at Texas Advanced Computing Center ( TACC )  Each machine runs Linux on an Intel Xeon 2.53 GHz with 48 GB of RAM.  For GPU experiments, we use NVIDIA Tesla M2070 GPU s (448 CUDA cores and 6 GB of memory)

25 To get a sense of the cost reduction, consider amortized costs for multiplication of 500×500 matrices: Under the theory, naively applied Under P EPPER client CPU time>100 trillion years<2.2 seconds server CPU time>100 trillion years6.5 hours However, this assumes a (fairly large) batch.

26 1.What are the break-even points? 2.At these points, is the server’s latency acceptable? # instances CPU time computation costs verification costs break-even point

27 break-even4100 inst.30,500 inst.24,500 inst. client CPU time2.5 hours27 minutes25 minutes server CPU time3.1 years10 months9.5 months break-even20 inst.1570 inst.990 inst. client CPU time44 sec.83 sec.60 sec. server CPU time5.4 days16 days11.9 days Consider outsourcing in two different regimes: (1) Verification work performed on CPU (2) If we had free crypto hardware for verification … mat. mult., m=500 insertion sort, m=256 PAM clustering, m=15, d=100

28 1 core 4 cores 60 cores (ideal) 1 core 4 cores 60 cores (ideal) 1 core 4 cores 60 cores (ideal) 1 core 4 cores 60 cores (ideal) matrix multiplication insertion sortPAM clustering all-pairs shortest paths 60 cores Parallelizing the server results in near-linear speedup

29 polynomial evaluation Hamming distanceroot finding Fannkuch benchmark 1 core 4 cores 60 cores (ideal) 1 core 4 cores 60 cores (ideal) 1 core 4 cores 60 cores (ideal) 1 core 4 cores 60 cores (ideal) 60 cores Parallelizing the server results in near-linear speedup

30 1.The client requires batching to break even. 2.The server’s burden is too high, still. 3.The computational model is still limited (looping is clumsy, etc.) P EPPER is not ready for prime time:

31 We describe the landscape in terms of our three goals. Gives up being unconditional or general-purpose  Replication [Castro & Liskov TOCS02], trusted hardware [Chiesa & Tromer ICS10, Sadeghi et al. TRUST10], auditing [Haeberlen et al. SOSP07, Monrose et al. NDSS99]  Special-purpose [Freivalds MFCS79, Golle & Mironov RSA01, Sion VLDB05, Benabbas et al. CRYPTO11, Boneh & Freeman EUROCRYPT11] Unconditional and general-purpose but not geared toward practice  Use fully homomorphic encryption [Gennaro et al., Chung et al. CRYPTO10]  Proof-based verified computation [GMR85, Ben-Or et al. STOC88, BFLS91, Kilian STOC92, ALMSS92, AS92, Goldwasser et al. STOC08, Ben-Sasson et al. ePrint12] Proof-based verified computation geared to practice  P EPPER [HotOS11, NDSS12, Usenix Security 12, ePrint12]  [Cormode et al. ITCS12, Thaler et al. HotCloud12] [Gennaro et al. ePrint12]

32 We have reduced the costs of a PCP-based argument system [ Ishai et al., CCC07] by 20+ orders of magnitude, with proof.  The refinements are in the PCP and the cryptography. We have made the computational model general-purpose.  This leads to cost savings and programmability …  … and yields a practical compiler. Take-away: Proof-based verified computation is now close to practical and will be a key tool in real systems.


Download ppt "Making proof-based verified computation almost practical Michael Walfish The University of Texas at Austin."

Similar presentations


Ads by Google