next steps Srinath Setty Microsoft Research (Thanks to Michael - PowerPoint PPT Presentation

Implementations of probabilistic proofs for verifiable outsourcing: survey and next steps Srinath Setty Microsoft Research (Thanks to Michael Walfish for some of the slides.)

GMR 85 BCC 88 Kilian92 without executing f, Micali94 can check that: “y = f(x)” BG 02 more generally: “ prover knows w s.t. y = f(x,w )” GOS 06 IKO 07 GKR 08 CKV10 GGP 10 Groth10 Efficiency Lipmaa1 • 2 Privacy of w zero-knowledge • GGPR 12 BCCT 13 …

Practicality efficiency privacy for w

SBW 11 CMT 12 SMBW 12 TRMP 12 Running code; cost reductions of 10 20 vs. theory SVPBBW 12 • SBVBPW 13 VSBW 13 Compilers from C to protocol entities PGHR 13 • Thaler13 BCGTV 13 Stateful computations; remote inputs, outputs BFRSBW 13 • BFR 13 DFKP 13 Concretely efficient verifiers BCTV 14a • BCTV 14b BCGGMTV 14 FL 14 KPPSST 14 FGV 14 BBFR 14 Extreme expense: 10 6 x overhead vs. native • WSRHBW 15 CFHKKNPZ 15 CTV 15 Programming model is clumsy • WHGSW 16 DFKP 16 Useful only for special-purpose applications FFGKOP 16 • ZGKPP 17 WJBSTWW 17

[Castro & Liskov TOCS02] Intel SGX

Summar mmary y of s f sta tate te of th f the e art t im implementa plementati tions ons

front-end back-end (program translator) (probabilistic proof protocol) verifier main(){ ... x } y, π C program arithmetic circuit prover (non-det. input) General “processor” interactive proof [ GKR 08 ] Custom circuit interactive argument [ IKO 07 ] non-interactive argument [ Groth10, Lipmaa12 , GGPR 12 ]

Arguments Interactive Non-interactive Interactive proofs [IKO07, SBW11, SMBW12, … ] [Groth10, Lipmaa12, GGPR12, [GKR08, CMT12, … ] … ] Circuit type Deterministic Non- Non- deterministic deterministic #Rounds Lots Two One Assumptions None Simple, falsifiable Non-standard Prover expense 10 to 100x 10 6 x 10 6 x Verifier setup 0 or (10 to 100x) 10 6 x 10 6 x Zero-knowledge No No Yes Hardware impl. Yes Non-amenable Non-amenable [GGPR12]

Attempt 1: Use PCPs that are asymptotically short [ BGHSV 05, BGHSV 06, Dinur07, BS 08, Meir12, BCGT 13] [ ALMSS 92, AS92] prover verifier ... ... “short” PCP ACCEPT / REJEC T This does not meet the efficiency requirements (because |PCP| > running time of f).

Attempt 2: Use arguments or CS proofs [Kilian92, Micali94] prover verifier ... “short” PCP ACCEPT / REJEC T But the constants seem too high …

Attempt 3: Use long PCPs interactively [ IKO 07, SMBW 12, SVPBBW 12] prover verifier L(  ) = <  , v > z ⊗ z v ... z Hadamard ACCEPT / REJEC encoding of Z T Achieves simplicity, with good constants … … but pre-processing is required (because |q i |=|v|) … and prover’s work is quadratic; address that shortly

Attempt 4: Use long PCPs non- [ BCIOP 13] interactively prover verifier L(  ) = <  , v > z ⊗ z v ... z Hadamard ACCEPT / REJEC encoding of v T Query processing now happens “in the exponent” … pre-processing still required (again because |q i |=|v|) … prover’s work still quadratic; addressing that soon

Recap efficient arguments, arguments w/ SNARGs w/ (short) PCPs CS proofs preprocessing preprocessing who ALMSS 92, AS 92, Kilian92, IKO 07, SMBW 12, GGPR 12, BGSHV , Dinur, … Micali94 SVPBBW 12, BCIOP 13, … SBVBPW13 what classical PCP commit to commit to encrypt queries PCP by long PCP to a long PCP hashing using linearity security unconditional CRHFs linearly HE knowledge-of- exponent why/why not efficient constants simple simple, non- for V are interactive not unfavorable (Thanks to Rafael Pass.)

Final attempt: apply linear query structure to GGPR’s QAPs [Groth10, Lipmaa 12 , GGPR 12 ] prover L(  ) { return <  , v >; z ⊗ h } v z z z Addresses the issue of quadratic costs. PCP structure implicit in GGPR. Made explicit in [ BCIOP 13, SBVBBW 13] .

“ Zaatar ” “Pinocchio,” “ libsnark ” [ SBVBBW 13 ] [ PGHR 13 , BCTV 14a ] queries in plaintex exponent t interactive SNARG , zk- SNARK with pre- queries argument processing [ IKO 07] [Groth10, BCCT 12, GGPR 12] pre-processing QAPs avoidable in theory [ BCCT 13 , BCTV 14b , CTV 15 ] standard assumptions non-falsifiable assumptions • • amortize over batch amortize indefinitely • • interactive non- interactive, ZK, … • •

front-end back-end (program translator) (argument variants) verifier main(){ ... x y, π } QAPs [ GGPR 12] C program arithmetic circuit prover (non-det. input)

State of the art front- ends “General” processor fetch-decode-execute [TinyRAM] … Verbose circuits (costly)  MIPS C prog .exe Good amortization  CPU state Great programmability  circuit is unrolled CPU execution [ BCGTV 13 , BCTV 14a , BCTV 14b , CTV 1 5] Custom circuits C prog Concise circuits  Amortization worse  each line translates to gates How is programmability?  [ SBVBPW 13 , VSBW 13 , PGHR 13 , BFRSBW 13 , BCGGMTV 14 , BBFR 1 4, FL 14 , KPPSST 14 , WSRBW 15 , CFHKKNPZ 15]

Front-ends trade off performance and expressiveness applicable computations concrete genera function costs special-purpose pure stateful l loops pointers Thaler lower CRYPTO 13 CMT, TRMP ITCS , Hotcloud 12 Custom circuit Geppetto Zaatar Pepper, Ginger ? Buffet Oakland15 Eurosys13 NDSS 12, Security12 WSRHBW Trueset, Zerocash Pinocchio Pantry NDSS 15 Security14,Oakland15 Oakland13 SOSP 13 BCTV Security14 General higher BCGTV CRYPTO 13 “processor Proof-carrying data highest ” CRYPTO 14, Eurocrypt15 (still theory) Short PCPs Eurocrypt17

Summary of common framework: front-end back-end (program translator) (argument variants) “general processor” … verifier main(){ ... x y, π } QAPs [ GGPR 12] prover “custom circuit”

Summary of state of the art implementations Rea eality lity ch check eck wi with th a pe perfo formance rmance ev evaluatio luation

Back-end: libsnark i.e., BCTV’s optimized Pinocchio implementation Front-ends: implementations or re-implementations of  Zaatar (Custom circuit) [ SBVBPW Eurosys13]  BCTV (General processor) [Security14]  Buffet (Custom circuit) [ WSRHBW NDSS 15]

Landscape of front-ends (again) applicable computations concrete genera function costs special-purpose pure stateful l loops pointers Thaler lower CRYPTO 13 CMT, TRMP ITCS , Hotcloud 12 Geppetto Zaatar Pepper, Ginger Oakland15 Eurosys13 Buffet NDSS 12, Security12 Trueset, Zerocash Pinocchio NDSS 15 Pantry Security14, Oakland15 Oakland13 SOSP 13 BCTV Security14 higher BCGTV CRYPTO 13 Proof-carrying data highest CRYPTO 14, Eurocrypt15 (still theory) Short PCPs Eurocrypt17

Quick performance study Back-end: libsnark i.e., BCTV’s optimized Pinocchio implementation Front-ends: implementations or re-implementations of: Zaatar (Custom circuit) [ SBVBPW Eurosys13]  BCTV (General processor) [Security14]  Buffet (Custom circuit) [ WSRHBW NDSS 15]  Evaluation platform: cluster at Texas Advanced Computing Center ( TACC ) Each machine runs Linux on an Intel Xeon 2.7 GHz with 32 GB of RAM .

(1) What are the verifier’s costs? (2) What are the prover’s costs? Proof length 288 bytes V per-instance 6 ms + (|x| + |y|) ･ 3 µs V pre-processing |C| ･ 180 µs P per-instance |C| ･ 60 µs +|C|log |C| ･ 0.9µs P’s memory requirements O(|C|log|C|) (|C|: circuit size) (3) How do the front-ends compare to each other? (4) Are the constants good or bad?

How does the prover’s cost vary with the choice of front-end? Extrapolated prover execution time, normalized to Buffet

All of the front-ends have terrible concrete performance Extrapolated prover execution time, normalized to native execution

Front-end: generality brings a concrete price (but better in theory)  Verifier’s “variable costs”: genuinely inexpensive  Prover’s computational costs: near-total disaster  Memory: creates scaling limit for verifier and prover 

One option: T arget domains where verifier cannot simply execute the computation • Anonymous credentials: Cinderella [Oakland16] • Anonymity for Bitcoin: Zerocash [Oakland14] • Location-private tolling [Security09]: Pantry [ SOSP 13] Another option: try to motivate theoretical advances

Summary of state of the art implementations Reality check with a performance evaluation Nex ext t ste teps: ps: We n e nee eed d 3-6 6 or orde ders of m f magnitude gnitude spe peed edup up

• More efficient reductions from programs to circuits • Inexpensive floating-point operations (to target domains such as deep learning, machine learning, … ) • Better handling of state

ADSNARK [S&P15] , Hash first argue Pantry [SOSP13] Geppetto [S&P15] later [CCS16] Technique CRHF in circuit SNARK already has SNARK already (folklore) a CRHF has a CRHF Generality Any circuit Specific Any circuit Prover expense O(k log(|D|)) O(k |D|) O(k |D|) 10 6 to 10 8 x 10 6 to 10 8 x 10 6 to10 8 x Concrete expense [S&P17]