1 / 25

Introduction to Modern Cryptography, Lecture 12

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)

jmckeown
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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Introduction to Modern Cryptography, Lecture 12 Secure Multi-Party Computation

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

  3. 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))

  4. 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)

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

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

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

  8. 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)

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

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

  11. Required Gates

  12. Addition Gate c1 = a1+b1 c2 = a2+b2 c1+c2 = a1+a2+b1+b2

  13. Multiplication Gate c1+c2 = (a1+a2)(b1+b2) (c1,c2) should be uniformly chosen amongst all solutions We use Oblivious Transfer

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

  15. 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:

  16. OT Using RSA for semi-honest Sender sends Receiver: Receiver computes:

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

  18. Correctness

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

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

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

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

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

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

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

More Related