Introduction to modern cryptography lecture 12
This presentation is the property of its rightful owner.
Sponsored Links
1 / 25

Introduction to Modern Cryptography, Lecture 12 PowerPoint PPT Presentation


  • 61 Views
  • Uploaded on
  • Presentation posted in: General

Introduction to Modern Cryptography, Lecture 12. Secure Multi-Party Computation. We want to emulate a trusted party. Imagine that the parties send their inputs to a trusted party (no eavesdroping)

Download Presentation

Introduction to Modern Cryptography, Lecture 12

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


Introduction to modern cryptography lecture 12

Introduction to Modern Cryptography, Lecture 12

Secure Multi-Party Computation


We want to emulate a trusted party

We want to emulate a trusted party

  • Imagine that the parties send their inputs to a trusted party (no eavesdroping)

  • The trusted party computes the “functional” (not a function): a random process that maps m inputs to m outputs

  • The trusted party gives every party its output (again no eavesdroping)

  • We want to do without a trusted party


General two party computation

General Two-Party Computation

  • A 2 party protocol problem is a random process that maps pairs of inputs (one per party) to pairs of outputs

  • Special cases of interest:

  • f(x,y) = (g(x,y),g(x,y))

  • f(x,y) = uniformly distributed over ((0,0),(1,1))


Conventions

Conventions

  • The protocol problem has to be solved only for inputs of the same length

  • The functionality is computable in time polynomial in the length of the input

  • Security is measured in terms of the length of the input (use inputs 1n)


The semi honest model

The semi-honest model

  • A semi-honest party is one who follows the protocol with the exception that it keeps all its intermediate computations

    • In particular, when the protocol calls for tossing a fair coin, the semi-honest party will indeed toss a fair coin

    • Also, the semi-honest party will send all messages as instructed by the protocol

  • Actually, it suffices to keep the internal coin tosses and all messages received


Privacy in the semi honest model

Privacy in the semi-honest model

  • A protocol privately computes

    if whatever a semi-honest party can obtain after participating in the protocol, it could obtain from its input and output


Security in the semi honest model

Security in the semi-honest model

  • The “ideal” execution makes use of a trusted third party

  • A semi-honest protocol is secure if the results of the protocol can be simulated in the ideal model

  • In the semi-honest model, security = privacy


The malicious model

The Malicious Model

  • There are three things we cannot hope to avoid:

    • Parties refusing to participate

    • Parties substituting their local input

    • Parties aborting the protocol prematurely

  • Security in the malicious model: the protocol emulates the ideal model (with a trusted third party)


Secure protocols for the semi honest model

Secure Protocols for the Semi-Honest model

  • Produce a Boolean circuit representing the functionality

  • Use a “circuit evaluation protocol” which scans the circuit from the inputs wires to the output wires

  • When entering a basic step, the parties hold shares of the values of the input wires, and when exiting a basic step, the parties hold shares of the output wires

NOTE: ONLY DETERMINISTIC SO FAR


What gates

What gates?

  • It suffices to consider AND and XOR gates of fan-in 2

  • Use arithmetic over GF(2) where multiplication = AND and addition = XOR

    • 1*1=1, 1*0=0, 0*0=0, 0*1=0

    • 1+1=0, 1+0=1, 0+1=1, 0+0=0


Required gates

Required Gates


Addition gate

Addition Gate

c1 = a1+b1

c2 = a2+b2

c1+c2 = a1+a2+b1+b2


Multiplication gate

Multiplication Gate

c1+c2 = (a1+a2)(b1+b2)

(c1,c2) should be uniformly

chosen amongst all solutions

We use Oblivious Transfer


Oblivious transfer in the case of semi honest parties

Oblivious transfer in the case of semi-honest parties

  • Sender has t1, t2, …, tk (bits)

  • Receiver chooses some 1 ≤ i ≤ k

  • Goal: Receiver gets ti, Sender does not know i


Ot using rsa for semi honest

OT Using RSA for semi-honest

  • Sender chooses RSA keys, sends public key to Receiver

  • Receiver chooses random e1, e2, …, ek

  • Receiver computes RSApub(ei)

  • Receiver sends Sender:

  • Sender computes:


Ot using rsa for semi honest1

OT Using RSA for semi-honest

Sender sends Receiver:

Receiver computes:


Privately computing c 1 c 2 a 1 a 2 b 1 b 2

Privately computing c1+c2=(a1+a2)(b1+b2)

  • We use Oblivious transfer with four shares

  • Party 1 chooses a random c1 in 0,1

  • Party 1 has a1, b1, and plays the OT sender with

  • Party 2 has a2, b2, and plays the OT receiver with


Correctness

Correctness


The circuit evaluation protocol

The circuit evaluation protocol

  • Do a topological sort of all wires in the circuit

  • Input wires: every player “shares” the value of her input wire with the other player

  • Once the shares of the circuit output wires are computed, every party sends its share of wires for the other party


How to force semi honest behavior

How to force semi-honest behavior

  • Theorem: suppose that trapdoor permutations exist (e.g., RSA), then any two party functionality can be securely computable in the MALICIOUS MODEL.


Problems with malicious parties

Problems with Malicious parties

  • Different input (nothing to do)

  • Does not use truly random bits (I happen to have chosen at random the ace) – use coin tossing in a well

  • Send messages other than the messages it should send via the protocol – use zero knowledge proofs


Coin tossing in a well

Coin tossing in a well

  • A coin tossing in a well protocol is a two party protocol for securely computing (in the malicious model) the randomized functionality

Where b is uniformly distributed on 0,1


Simple solution

Simple solution

  • Use an encoding of 0’s and 1’s

  • Alice chooses a random encoding of a random bit b and sends Bob the one-way function (or more exactly bit commitment) of the bit

  • Bob sends a random bit c to Alice

  • Alice reveals the commitment to b

  • The common random bit is b+c


Alice does not want bob to know her coin tosses only to prove that they are honest

Alice does not want Bob to know her coin tosses, only to prove that they are honest:

  • Alice chooses many random bits b1, b2, …and sends Bob the bit commitments

  • Bob sends Alice random bits c1, c2, …

  • Alice uses the bits bi + ci in her computation

  • Alice gives Bob a zero knowledge proof that the computation uses these bits, based upon the commitments to the bits that Bob already has


Alice s other inputs

Alice’s other inputs

  • Alice needs to be consistent in her inputs, we cannot force Alice not to lie about her input, but at least we can force her to be consistent


  • Login