Vipul Goyal Microsoft Research India

1. Non-Black-Box Simulation in the Fully Concurrent Setting Vipul Goyal Microsoft Research India

2. Non Black Box Simulation [Barak’01] • ZK and simulation [Goldwasser-Micali-Rackoff’85]. All initial simulators used code of adv in a black-boxway • Barak introduced non-black-box simulation in cryptography • Gave a new ZK protocol: public-coin, based on CRHFs, “straight-line” strict poly time simulation • Helped changed the landscape of cryptographic protocols: useful in resettable protocols, non-malleable protocols, concurrent secure computation protocols ….

3. Our Contribution • A main limitation of Barak’s technique was in the concurrent setting • Simulator only worked in standalone or bounded concurrent setting • Main contribution: extend Barak’s technique to the fully concurrent setting • We give a new ZK protocol: as with Barak’s, ours is public-coin, based on CRHFs, and has a “straight-line” strict poly-time simulator • However simulation works in the fully concurrent setting • Not a strict improvement over Barak’s: round complexity of our construction is nϵ (where it was only a constant in Barak’s)

4. Talk Overview • Recall Barak’s construction and the problems in fully concurrent setting • Our ZK construction • Reduce the core challenge to a purely combinatorial problem • Relatively simple and short proof • Arguably the simplest concurrent ZK protocol • Applications • Simplifying Assumption: Assume a non-interactive WI universal argument system (one message from Prover to Verifier)

5. Barak’s ZK Construction Statement: x in L Com(h(M)) slot Random r Verifier Prover WI-UA: x in L or M outputs r ZK simulator: M is the code/state of the verifier machine Soundness: r is long and random

6. Concurrent setting: problem Com(h(M)) . . c • M doesn’t output r • Fix: M contains the state of system (simulator + verifier) • M regenerates the entire slot transcript and finally arrives at r • The UA takes time c.k to compute r UA: M outputs r c.k steps

7. Exponential time simulator Session 2 Session 1 Com(h(M)) c 0-heavy r c’ = c.k 1-heavy 1-heavy c.k steps 2-heavy c.k2 steps • Messages except UA: 0-heavy • If slot has i-heavy messages: i-heavy slot • UA regenerating transcript of i-heavy slot: (i+1) heavy UA • If i-heavy for superconstant i => simulation exponential time

8. A failed attempt: have many slots Com(h(M1)) r1 . . Com(h(Mn)) rn UA still “heavy” Repeat in parallel n times to get n different 1-heavy UAs Next session: Make n slots 1-heavy UA: x in L or Mi outputs ri for some i 1-heavy

9. Our Idea: Have many UA’s Com(h(M1)) r1 UA1 heavy . . Com(h(Mn)) rn UAn

10. Our Protocol: Basic Idea Com(h(Mi)) ri UA: Mi output ri Com(UAi) For i =1 to n WIAOK: x in L or i-th UA convincing for some i • Only one UA needs to be picked for simulation in each session • Adv doesn’t know which one it is

11. Basic combinatorial problem: construct a marking strategy • Simulator has to mark each outgoing UA message either SIMULATE or BLANK • UA marked BLANK: 0-heavy • i-heavy slot: contains i-heavy UA • If slot doesn’t have a simulated UA, 0-heavy • UA marked SIMULATE: (i+1)-heavy iff the slot is i-heavy • Constraint • At least one UA in each session marked SIMULATE. • No i-heavy UA for any super-constant i

12. Example • Say we mark the first UA message SIMULATE in all sessions i-heavy UA for super-constant i 0-heavy 1-heavy 1-heavy . . 2-heavy 2-heavy . . 0-heavy 3-heavy . . 0-heavy 0-heavy 0-heavy 0-heavy 0-heavy Session 1 Session 2 Session 3 • Randomized marking strategy: paper for details

13. Sample of Applications • First public-coin concurrent ZK • Earlier negative result with BB simulation [Pass-Tseng-Wikstrom’09] • First concurrent blind signatures as per ideal/real definition • Earlier negative result for BB simulation by [Lindell’03] • Resolving the bounded pseudoentropy conjecture [Goyal’12] • Improvements in both the round complexity as well as the class of realizable functionalities for concurrent secure computation

14. Thank You!