input indistinguishable computation l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Input-Indistinguishable Computation PowerPoint Presentation
Download Presentation
Input-Indistinguishable Computation

Loading in 2 Seconds...

play fullscreen
1 / 26

Input-Indistinguishable Computation - PowerPoint PPT Presentation


  • 280 Views
  • Uploaded on

Input-Indistinguishable Computation. Silvio Micali MIT Rafael Pass Cornell Alon Rosen Harvard. Definitions vs. Protocols. x. Crypto in the 20 th century – protocols -> definitions Crypto in the 21 st century – definitions -> protocols This talk:

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Input-Indistinguishable Computation' - HarrisCezar


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
input indistinguishable computation
Input-IndistinguishableComputation
  • Silvio Micali MIT
  • Rafael Pass Cornell
  • Alon Rosen Harvard
definitions vs protocols
Definitions vs. Protocols

x

  • Crypto in the 20th century – protocols -> definitions
  • Crypto in the 21st century – definitions -> protocols
  • This talk:
  • New definition (input-indistinguishable computation)
      • For secure two-party computation (malicious).
      • Definition is“simulation free.”
      • Inspired bywitness indistinguishability.
  • New protocol
      • Concurrency without trustedset-up.
      • Standard complexity assumptions.
  • Our motivation is “protocol driven.’’
  • We do not achieve “holy grail” of cryptography (yet)…

x

modern crypto methodology

Delicate balance

Modern Crypto Methodology

Define security (what it means to break the scheme).

Specify adversary in terms of:

  • computational power,
  • access to scheme.

Construct scheme and prove that breaking it implies solving (assumed) computationally hard problem (e.g. factoring).

To reach balance:

  • Establish feasibility.
  • Improve efficiency.
  • Weaken hardness assumption.

See if can satisfy a stronger definition (stronger adversary)...

Need to convince that:

  • Definition is meaningful.
  • Adversary is realistic.
  • Assumption is reasonable.
slide4

Alice

Alice

Bob

Bob

 PPT B*

 PPT S

Secure Two-Party Computation

REAL

IDEAL

YES

WELL…

If you believe Factoring/DL are hard.

  • Is definition meaningful?
  • Is adversary realistic?
  • Is assumption reasonable?

Theorem[Yao, GMW,Kil]: Assuming OT protocol, every efficient two-party function can be securely computed.

slide5

B

B

B

B

B

B

B

B

A

A

A

A

A

A

A

A

A

A

UC/General/Self Composition [C,L03,L04]

REAL

IDEAL

  • Is definition meaningful?
  • Is adversary realistic?
  • Is assumption reasonable?

YES

YES

Maybe, if we just had a protocol…

Theorem[CKL, L03, L04]: For most “interesting’’ functions definitions of UC/General/Self composition cannot be achieved.

slide6

Reference String

B

B

B

B

A

A

A

A

A

A

Set-Up Assumptions

REAL

IDEAL

Theorems[CLOS, BCNP, CDPW]: Assuming OT, every efficient two-party function can be securely (UC) computed with some form of trusted set-up.

  • Meaningful?
  • Realistic?
slide7

B

B

B

B

B

B

B

B

A

A

A

A

A

A

A

A

A

A

Super-Polynomial Time Simulation [P03]

REAL

IDEAL

 PPT B*

 PsuperPTS

Theorems[PS,BS]: Assuming subexp-hardness (and OT), every eff. two-party function can be securely computed with quasi-poly simulator.

  • Is definition meaningful?
  • Is adversary realistic?
  • Is assumption reasonable?

YES in many cases

[BS] very sensitive to security parameters

[PS] non-standard assumptions

super polynomial time simulation
Super-Polynomial Time Simulation

Super-polynomial time simulation (SPS) is very appealing:

  • Yields meaningful security guarantee.
  • Handles a realistic adversary.
  • Has the potential of being realized
    • Under standard assumptions.
    • Without constraints on security parameters.

But coming up with such a protocol is still open.

We give a definition that can be realized:

    • Under standard assumptions.
    • Without constraints on security parameters.
    • In face of unbounded number of concurrent executions.

Definition: Any protocol (A,B) is secure.

d.Is (arguably) meaningful for many interesting functions.

e. May lead to solution that admits unbounded simulation.

slide9

Input-Indistinguishable Computation

  • Correctness.
  • Input-Independence

Privacy

Input-Indistinguishability

Consider

  • honestA with input x
  • malicious B* with input y
  • B* should get output.

ALL inputs of A compatible with output of B* “EQUALLY LIKELY”

To distinguish x0,x1must use y* s.t.F(x0,y*) ≠ F(x1,y*)

  • Trivial if single-input per output
  • Generalization of Witness-Indist [FS90]

What is y*?

Implicit input function IN(viewB*) = y*

witness indistinguishability fs90

Prover

Verifier

Witness Indistinguishability [FS90]

view(w) = V*’s view of the interaction when P uses w

Witness Indistinguishability: for  PPT V*, w0, w1

view(w0)  view(w1)

WI property “well-behaved’’ under concurrent composition

interactive proofs vs two party computation

A

P

V*

B*

Interactive Proofs vs. Two-Party Computation
  • V* has no input B* has input y
  • V* output is 0/1 B* output is F(x,y*)
  • P input “hard” to compute A input can be finite
implicit input function
Implicit Input Function
  • Implicit input function INB:
    • defined on B*’s view of the interaction.
    • Wlog view depends only on x and on randomness of A
    • Well defined for all possible views.
  • Notation: for  PPT B*, x
        • y* <- INB(view(x))
  • Consistency: Output of A = F(x,y*)
  • Output delivery message: there exists a round in protocol s.t.
    • Implicit input is fully defined from view so far, but
    • no “information’’ about output has been released yet.
  • Implicit input and output round are implicit in ideal/real like definitions, but not required explicitly!
input indistinguishable computation13
Input-Indistinguishable Computation
  • (A,B) securely computes F w.r.t A if  implicit input function INB s.t.
  • Completeness: in honest execution of (A,B)
  • inputs = x,y output = F(x,y)
  • Input-Independence: for  PPT B*, x0, x1
  • INB(view(x0))  INB(view(x1))
  • Input-Indistinguishability: for  PPT B*, x0, x1
        • y* <- INB(view)
        • B* can only “distinguish” x0 and x1 when
          • F(x0,y*) ≠ F(x1,y*)
          • B* received output in the protocol
input indistinguishable computation14
Input-Indistinguishable Computation

(A,B) securely computes F w.r.t A if  implicit input function INB s.t.

Completeness: in honest execution of (A,B)

inputs = x,y output = F(x,y)

Input-Indist. and Indep.: For  PPT B*, x0, x1

Expt0(x0, x1)  Expt1(x0, x1)

Expti(x0,x1):

view<-view of B* in execution with A(xi)

y*<-INB(view)

If output = trueand F(x0,y*) ≠ F(x1,y*) 

Otherwise (y*,view)

example
Example
  • Oblivious transfer function.
  • F((s0,s1),c) = sc
  • (So x= (s0,s1) and y=c.)
  • Input independence: c is (computationally) independent of (s0,s1).
  • Input indistinguishability: Given sc* as output, and view((s0,s1)), the input s1-c* could take any value.
  • Very meaningful.
concurrent input indistinguishable computation
Concurrent Input Indistinguishable Computation

(A,B) securely computes F w.r.t A if  implicit input function INB s.t.

Completeness: in honest execution of (A,B)

inputs = x,y output = F(x,y)

ConcurrentInp-Indist. and Indep.: For  PPT B*, x0, x1

Expt0(x0, x1)  Exp1(x0, x1)

Basic Concurrency:

  • Same Protocol (self composition)
  •  fixed inputs sequences
  • Can be extended to handle arbitrary corruptions.
composibility
Composibility
  • Unlike WI (and UC) input-indistiguishability does not compose in general.
  • There exist protocols that are
    • stand-alone input indistinguishable, but
    • not concurrent input indistinguishable (even for two executions).
  • The problem is the potential malleability of (A,B).
  • Any solution must take malleability into consideration.
  • Turns out that insuring non-malleability is sufficient!
slide18

Main Theorem

  • Theorem:Suppose there exist (trapdoor) claw-free permutations. Then for any efficient 2-party function F, there exists a concurrent input-indistinguishable protocol for computing F.
  • Trapdoor claw-free permutations:
    • Required for OT, CRH, perfectly hiding commitments.
    • Follow from hardness of Factoring/DL.
slide19

High-Level Idea of Protocol

Yao’s protocol secure against honest-but-curious.

Compile a’ la GMW, but:

  • Instead of normal ZK, NMZK protocols of [P04][PR05]
    • Instructions of NMZK depend on identity of prover.
    • Different provers have different identities.
  • Provable Determinism[LMS04]: once first message sent, only one possible continuation (except for ZK).
  • And some more…

Let (A,B) denote resulting protocol.

slide20

Analysis

Lemma: (A,B) is (stand-alone) ideal/real secure.

Lemma: Stand-alone ideal/real -> stand-alone inp.-ind.

  • Implicit input is the value fed to trusted party.
  • Requires augmenting outputs of ideal/real w/ input of B*.
  • Relies on existence of output delivery message.
  • B*,D breaking inp.-ind. -> B**,D breaking ideal/real.

Lemma: (A,B) stand-alone inp.-ind. -> (A,B) conc. inp.-ind.

  • Implicit inputs same as in stand-alone.
  • Interplay between Hybrid argument and Simulation
  • Mixture of Black-box and Non black-box [PR05].
one many simulation extractable zk pr05

S

~

~

~

w2

wm

w1

ZKIDm

ZKID2

ZKID1

~

~

~

One-many Simulation-Extractable ZK [PR05]
  • Left interaction: simulate only one ZK execution.
  • Right interaction: concurrently extract witnesses from many executions.

B*

ZKID

concurrent stand alone

Concurrent -> Stand-Alone
  • Assume existence of concurrent adversary B*, and x, x s.t. corresponding EXPT can be distinguished.
  • Construct B** that violates stand-alone inp.-ind. Of (A,B).

}

x1

x1

B*

x2

x2

(view,y*)

-

(view,y*)

xm

xm

concurrent stand alone23

B**

Concurrent -> Stand-Alone

x1

M

xi

or xi

xm

Using a hybrid argument.

Only need to simulate the ZK proof in the ith execution.

Requires to extract all y*.

summary
Summary
  • Zero-knowledge (simulation paradigm) seems to have “hit the wall” with respect to protocol composition.
  • Maybe [Goldreich Micali Wigderson87] has made us “too ambitious…”
  • Perhaps we should
    • Give up in meaningfulness of definitions.
      • Super polynomial-time simulators [P03, PS04, BS05].
      • Based on indistinguishability [FS90].
    • Give up in generality of definitions.
      • Be meaningful only in specific cases.
      • Secure protocols for specifictasks [PR05,BPS06].