Optimistic Concurrent Zero-Knowledge Alon Rosen IDC Herzliya abhi shelat University of Virginia

Cryptographic Protocols Designed to handle worst case behavior Rigorous analysis induces complex design This work: 1.Assume best case (optimistically) 2.Prepare for worst case The gain: simplicity/efficiency/feasibility

Test Case: Concurrent ZK Why concurrent zero-knowledge? Extensively studied problem Useful benchmark: 1.Negative results for ZK  inherent difficulties 2.Solutions for ZK  solutions for other problems Central issues: 1. Complex setting 2. Technical difficulties in proving security 3. Round inefficient protocols

This Work New protocol for concurrent ZK: 1.Best case: constant round-complexity 2.Worst case: logarithmic round-complexity Protocol is simple Idea is applicable to other protocols Demonstrates gains from optimistic approach

Zero-Knowledge [GMR85] Prover Verifier Theorem T is true Really? Prove it! Completeness: if T is true Pr[P convinces V] = 1 Soundness: if T is NOT true Pr[P* convinces V] ≤ ½ Zero knowledge: only thing that V learns is validity of T

Defining ZK For every adversary verifier V* there exists a simulator S that produces prover-verifier interactions. Verifier* Simulator

The requirement… Simulator If T is true, simulation is indistinguishable from interaction. Prover Verifier *  Real interactionSimulation

Soundness vs. Zero-Knowledge 1.Soundness: if there is no “witness” for T, prover should not be able to convince. 2.ZK: Simulator should be able to convince that T is true without possessing a “witness” for T. 3.S should have some advantage over P. Simulator Prover Verifier *  Real interactionSimulation

Black-Box simulation Verifier* Simulator S feeds V* with random tape Advantage is gained via ability to “rewind” random tape

Composition of ZK proofs Three basic types of composition: 1.Sequential [GO]. 2.Parallel [GoKr]. 3.Concurrent [F,DNS].

Sequential Composition Prover Verifier

Parallel Composition Prover Verifier

No restrictions on synchronization of messages. Adversary verifier determines the schedule. Sequential and Parallel composition are special cases. Concurrent Composition [F,DNS] Prover Verifier

The “price” of concurrent ZK To achieve concurrent ZK: 1.make set-up assumptions, or 2.increase round-complexity. If no set-up is assumed: 1.Best known round complexity ω(log n) [RK, KP,PRS] 2.If protocol has less than o(log n/log log n) rounds black-box simulation is impossible [CKPR]

Alternative Approaches CRS/PKI [CGGM00, D00] Timing [DNS98, PTV10] Quasi-polynomial simulation [P03] Non-black-box [B01] Responsive round-complexity [CKP01]

Simulator cannot proceed beyond end of a session without being able to convince. Thus, simulator must rewind every session. Simulation work done for one session may be lost due to rewinding of other sessions. Should simulate polynomially many sessions. Why is BB concurrent ZK hard?

An Interleaved Scheduling [DNS] Time progression Session progression 4-message protocols are “hard” to simulate concurrently Messages may depend on history of interaction.

Example (n=3) Can be generalized to protocols having as many as k=o(log n/log log n) rounds [CKPR].

The RK Paradigm Generate many “rewinding” opportunities (P1) (V1) (P2) (V2) (P3) (V3) (Vk) (Pk) Prover Verifier ”Successful” rewinding of even one round is sufficient in order to complete simulation.

The protocol Stage I (preamble): Has k rounds and is independent of common input. Stage II (body of proof): Standard 3-round challenge/response ZK/WI protocol. Simulator’s ability to rewind preamble enables learning verifier’s challenge in advance. Prover cannot rewind and will not learn anything from preamble’s execution.

Intuition for Simulator 3-round ZK 1.Many rounds   round with few nested sessions 2.Rewinding that round does not cause much harm (P1) (V1) (P2) (V2) (P3) (V3) (Vk) (Pk)

Our New Protocol Key point: slot with no nesting  ok to rewind slot Stage I (preamble): 1.Optimistically assume that 1 st slot has no nested session 2.If nested session exists, add one more slot 3.Keep adding until no nesting in slot or # slots = k Stage II (body of proof): 1.Reached as soon as Stage I ends 2.3-round challenge/response ZK/WI (as before)

Our New Protocol Best case: no nested sessions in first slot Worst case: all slots have a nested session in them Best case Worst case 3-round ZK (V0) (P1) (V1) (P2) (V2) (Pk) (Vk) 3-round ZK (V0) (P1) (V1)

Footer Freeness Def: Slot j of session B has a nested footer if session A’s (Vk) message occurs between the (Pj), (Vj) messages of session B. Def: Slot j is said to be footer free if it has no nested footer. Note: 1.Certainly satisfied if no message is nested 2.But also allows some nested messages 3.“Typical” concurrent schedule has many footer free slots

Example (V1) (P1) (Vk) (Pk ) (Pj) (Vj) (Pj’) (Vj’) nested footer free (V2) (P2)

[RK] : “Solve” (rewind) one session at a time [KP, PRS] : rewind many sessions simultaneously timing of rewinding is oblivious to schedule New simulator: combines both rewind many sessions simultaneously timing of rewinding is adaptive Simulating the Protocol

Let i be some session. Case 1:  slot in session i that is footer free total # of slots < k rewind without getting “stuck” on other sessions Case 2:  slots in session i have nested footer Total # slots = k If k = w(log n) oblivious sim. solves session i Adaptive Rewinding

Summary Pros: efficiency/simplicity/flexibility Cons: 1.Requires coordination between provers 2.May leak scheduling information to V* In the paper: comparison with timing and responsive round complexity models

Questions?