On the Composition of Public- - On the Composition of Public Coin - - PowerPoint PPT Presentation

▶
on the composition of public on the composition of public
SMART_READER_LITE
LIVE PREVIEW

On the Composition of Public- - On the Composition of Public Coin - - PowerPoint PPT Presentation

Mar 04, 2023 385 likes •617 views

On the Composition of Public- - On the Composition of Public Coin Zero- -Knowledge Protocols Knowledge Protocols Coin Zero Rafael Pass (Cornell) Wei-Lung Dustin Tseng (Cornell) Douglas Wiktrm (KTH) 1 Zero Knowledge [GMR85] Zero

slide-1
SLIDE 1

On the Composition of Public On the Composition of Public-

  • Coin Zero

Coin Zero-

  • Knowledge Protocols

Knowledge Protocols

Rafael Pass (Cornell) Wei-Lung Dustin Tseng (Cornell) Douglas Wiktröm (KTH)

1

slide-2
SLIDE 2

Zero Knowledge [GMR85] Zero Knowledge [GMR85]

  • Interactive protocol between a Prover and a

Verifier where the Verifier learns nothing except the proof statement

  • Fundamental construct of cryptography
  • Used in secure MPC, authentication, etc, etc

2

Prover Verifier

slide-3
SLIDE 3

Zero Knowledge [GMR85] Zero Knowledge [GMR85]

  • For every PPT V* (adversary) there is a PPT

simulator S:

Simulator S

≈

Prover Verifier V* View of V* with Prover View generated by S

3

Indistinguishable

slide-4
SLIDE 4

Black Black-

  • Box Zero Knowledge [GO90]

Box Zero Knowledge [GO90]

  • Universal S interacts with and rewinds V*

Equivalently:

– Most known and all practical ZK are BB – This talk: Focus on BB ZK

4

Output View Output View

slide-5
SLIDE 5

Composition of ZK [GKr90] Composition of ZK [GKr90]

  • Do ZK protocols stay ZK when composed?

5

Parallel [FS90, GKr90] Concurrent [FS90, DNS04]

slide-6
SLIDE 6

Composition of ZK [GKr90] Composition of ZK [GKr90]

  • In general: ZK breaks even under 2 parallel

executions [FS90, GKr90]

  • Specific protocols:

– Secure under both parallel and concurrent composition (e.g., [GKa96, FS90, RK99, KP01, PRS02]) – But these protocols use something new:

Private Coins

6

slide-7
SLIDE 7

Public vs. Private Coins Public vs. Private Coins

  • Public-coin:
  • The original ZK protocols are all public-coin

[GMR85,GMW91, Blum87]

  • Why care about public-coin protocols?

– Theory: – Practice:

7

Prover Verifier

Private-coin:

  • Simpler to implement
  • V resilient to leakage and side channel attacks
  • Understand original protocols
  • e.g. “IP(Poly) = AM(Poly)” [GS86]
slide-8
SLIDE 8

The Question: The Question:

Are private coins necessary for composing ZK (even just) in parallel?

  • First studied by Goldreich-Krawczyk in 1990
  • Partial result: No constant round public-coin

BB ZK w/ neg. soundness error (L ∉ BPP)

– Known O(1) round public-coin BB ZK (with big soundness error) not secure in parallel

8

slide-9
SLIDE 9

Our Results Our Results

9

  • 1. Any public-coin protocol is not BBZK if

repeated sufficiently in parallel (L ∉ BPP).

  • 1. Any public-coin protocol is not BBZK if

repeated sufficiently in parallel (L ∉ BPP).

  • 2. For every m, there is a public-coin proof

for NP that is BBZK up to m concurrent sessions, assuming OWF.

  • 2. For every m, there is a public-coin proof

for NP that is BBZK up to m concurrent sessions, assuming OWF.

[Bar01]: Public-coin constant round bounded- concurrent non-BB ZK argument assuming CRH. [Bar01]: Public-coin constant round bounded- concurrent non-BB ZK argument assuming CRH.

slide-10
SLIDE 10

Prover Verifier

α

The The Goldreich Goldreich-

  • Krawczyk

Krawczyk framework framework

[GKr90]: If the verifier uses PRF to generate its messages in a constant round public-coin protocol → Protocol is resettably-sound [BGGL01]

10

+ PRF PRF(α )

slide-11
SLIDE 11

The The Goldreich Goldreich-

  • Krawczyk

Krawczyk framework framework

[GKr90]: If the verifier uses PRF to generates it messages in a constant round public-coin protocol → Protocol is resettably-sound [BGGL01]

11

Goal: Accepting execution for x ∉ L Goal: Accepting execution for x ∉ L

Verifier V

+ PRF

Resetting P*

slide-12
SLIDE 12

The The Goldreich Goldreich-

  • Krawczyk

Krawczyk framework framework

[GKr90]: If the verifier uses PRF to generates it messages in a constant round public-coin protocol → Protocol is resettably-sound [BGGL01]

  • If protocol is resettably-sound and BB ZK for L

→ L ∈ BPP (decided by S) [GK90, BGGL01]: x ∈ L → S(x) gives accepting view (ZK) x ∉ L → S(x) gives rejecting view (resettable-sound)

12

slide-13
SLIDE 13

Main Lemma Main Lemma

  • Compare with soundness amplification

– Recent work: Parallel repetition amplifies sound- ness of public-coin arguments [PV07, HPPW08]:

  • From ε → εpoly(n)

– Our work: “Quality” of soundness also improves

  • From “standard sound” → “resettably sound”

– Can use soundness amplification techniques

13

Any public-coin protocol (where V uses PRF for its messages) is resettably-sound when repeated sufficiently in parallel. Any public-coin protocol (where V uses PRF for its messages) is resettably-sound when repeated sufficiently in parallel.

slide-14
SLIDE 14

Proof Idea Proof Idea

  • Reduction R: Resettable P* → normal P
  • R tries to forward messages that P* utilize for

an accepting execution

– Possible to continue simulation due to public-coin

14

Verifier V

Reduction R

Resetting P*

slide-15
SLIDE 15

Which Message to Forward? Which Message to Forward?

  • [GKr90] For constant round protocols, choose

random messages to forward

– Guess correctly w.p. 1/poly each round – Doesn’t work when there are more rounds

  • Our approach:

– Do a test run to see which msg “should’ve been”

  • forwarded. Forward it and continue simulation

– If P* doesn’t use forwarded msg, rewind P* until it does

15

slide-16
SLIDE 16

Acc. Acc.

Example Example

16

Verifier V

Start: Two rounds are already forwarded Case: S fails to produce accepting view. → Rewind!

FAIL FAIL

Case: Forwarded msg not in accepting view → Rewind! Case: Forwarded msg is in accepting view → Found next message to forward Repeat Process Repeat Process

Acc. Acc. Reduction R

Resetting P*

slide-17
SLIDE 17

The Reduction Again The Reduction Again

  • 1. In a test run of P*, find the msg used by P* to

form an accepting view.

  • 2. Forward the msg to V and receive a fixed reply.
  • 3. Keep rewinding P* until the forwarded msg is

used in an accepting view

  • The next msg in view gets forwarded. Repeat.

Reduction idea analogous to [HPPW08]

Reduction always works! Is it poly time?

17

slide-18
SLIDE 18

Analysis Sketch Analysis Sketch

  • If we can rewind external V:

– Case: P* chooses which branch to use in view randomly. → Then poly rewinds are enough – This is actually the worst case

  • But we can’t rewind external V:

– Forwarded messages are fixed. Might fix a BAD message – Reduction: Resettable parallel P*→normal standalone P – New picture!

18

standalone

slide-19
SLIDE 19

Analysis Sketch Analysis Sketch

  • Can almost rewind the Verifier
  • Results in a statistically close distribution!

– Technically shown by relying on Raz’s Lemma – Technique used in soundness amplification of 2-prover games [Raz98] and public-coin arguments [HPPW08]

19

Verifier V

Reduction R

Resetting P*

slide-20
SLIDE 20

Conclusion Conclusion

  • Any public-coin protocol, with enough parallel

repetitions, is resettably-sound

→ so not BB ZK unless L ∈ BPP

  • Elucidate connection between hardness

amplification and BB ZK lower bounds

– New set of techniques for BB lower bounds

20

slide-21
SLIDE 21

Corollary Corollary

  • Bare Public-Key setup

– More efficient (private-coin) concurrent ZK – Model studied in the soundness amplification literature [IW97, BIN97, HPPW08]

  • Using [BIN97, HPPW08] techniques, we can

extend our impossibility result to BPK too

21

slide-22
SLIDE 22

Thank You! Thank You!

22