Optimistic Concurrent Zero-Knowledge

1. Optimistic Concurrent Zero-Knowledge • Alon Rosen IDC Herzliya • abhi shelatUniversity of Virginia

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

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

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

5. Prover Verifier Zero-Knowledge [GMR85] 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

6. Simulator Verifier* Defining ZK For every adversary verifier V* there exists a simulatorSthat produces prover-verifier interactions.

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

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

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

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

11. Prover Verifier Sequential Composition

12. Prover Verifier Parallel Composition

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

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

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

16. Why is BB concurrent ZK hard? Should simulate polynomially many sessions. • 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.

17. 1 2 3 n R(n-1) Time progression Session progression An Interleaved Scheduling [DNS] 4-message protocols are “hard” to simulate concurrently 1 2 3 n Messages may depend on history of interaction.

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

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

20. 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.

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

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

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

24. 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: • Certainly satisfied if no message is nested • But also allows some nested messages • “Typical” concurrent schedule has many footer free slots

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

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

27. Adaptive Rewinding • 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

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

29. Questions?