1 / 30

Vipul Goyal Microsoft Research, India

Constructing Non-Malleable Commitments. Vipul Goyal Microsoft Research, India. Commitment Schemes [Blum’84]. s?. Commitment like a note placed in a combination safe Two properties: hiding and binding Electronic equivalent of such a safe. s. Com( s ). Opening of Com( s). Combination.

nitza
Download Presentation

Vipul Goyal Microsoft Research, India

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. Constructing Non-Malleable Commitments Vipul Goyal Microsoft Research, India

  2. Commitment Schemes [Blum’84] s? • Commitment like a note placed in a combination safe • Two properties: hiding and binding • Electronic equivalent of such a safe s Com(s) Opening of Com(s) Combination Receiver Committer

  3. Contract Bidding s Com(s) s? ? • Legitimate businessman: doesn’t want to leak his bid (during bidding phase), need crypto

  4. Constructing Commitment Scheme • Discrete log assumption: given (g, ga), a is hard to compute • DDH assumption: given (g, ga, gb), any information about gab is hard to compute • Observe that given (g, ga, gb), gab, although hard to compute, is fixed and unique

  5. ElGamal Commitment Scheme • DDH assumption: given (g, ga, gb), any information about gab is hard to compute Generate a,b randomly g, ga, gb, s.gab s a, b Receiver Committer • After commitment phase: s hidden; gab reqd to get s • Binding: a, b unique given commitment phase, hence s unique 5

  6. Contract Bidding: is a commitment sufficient? Com(s) s? Com(0.99s) • Adversary still cheats and creates a winning bid

  7. Hiding doesn’t imply Non-malleability ga, gb, s.gab a, b ga, gb, 0.99.s.gab Committer Receiver a, b • Simply multiply the last string by 99/100 • Design of non-malleable commitments: not an easy problem 7

  8. Non-Malleable Commitments • Introduced in the seminal work of Dolev, Dwork and Naor [DDN91] • Important building block towards the bigger goal of designing secure cryptographic protocol for the internet setting • ->Several parties, some corrupt, trying to break sec of an honest party, well established goal to construct secure protocols • -> NMcom useful building blocks Picture credit: R. Pass

  9. Outline of the Talk • Plan for the rest of the talk • Problem statement + Definition • An informal idea of our new technique • Some formal details • Results / Prior works

  10. NM Commitment: Definition s s' • Problem: Adversary doesn’t know s, doesn’t know s’, just tweaks and copies (and ensures a relation between the two) • Definition: Adversary should “know” what it committed to (in particular s’); else fails 10

  11. NM Commitment: Definition s s' • Proof of non-malleability by contradiction: • s’ known; s unknown (hiding) • Hence, s’ can’t depend on s (throwing away left session) 11

  12. Ideas behind our Scheme s • Commitment stage to have multiple rounds of interaction • Use a “normal” commitment scheme Com and convert into non-malleable 12

  13. Our Protocol: Intuitive Overview

  14. First Idea: every committer commits differently 25 ID = 25 75 s • Different committers have different identities (say 1 to 100); identities public • Two stages: • one with label ID • one with 100 - ID 14

  15. Key Idea: every committer commits differently Com(s), Com(s), … (25 times) ID = 25 Com(s), Com(s) … (75 times) s • In each stage, use Com • commit to the same s many times in parallel depending on the label (using fresh randomness) • To open, open all of them, receiver verifies 15

  16. Man-in-the-middle Scenario 25 75 37 25 63 37 • Lets look at left and right interactions • At least one stage where right label > left label 16

  17. Man-in-the-middle Scenario k commitments to s . . . k’ commitments to s’ s s' . . . ? Problem: Adversary creates several commitments on right using one on the left • Recall: need to prove adv knows s’ • k’ > k: Adv has to give more commitments than he gets • At least one commitment prepared on his own? 17

  18. Prevent Replication: use Interaction Com(s1), Com(s2) s b in {1,2} opening of Com(sb) Receiver Commiter open remaining Com • s1 and s2: secret shares of s; s1 s2 = s • Scheme still hiding + binding

  19. Prevent Replication contd.. Com(s1), Com(s2) 1 opening of Com(s1) 1 . . • Gets only one opening from left • Might need to open both 2 ? 19

  20. Overall Idea Com(s1[1]), Com(s2[1]) Com(s1[ID]), Com(s2[ID]) ch[1] ch[ID] . . . open open Proof: all commitments same ID • Formal Analysis: next 20

  21. Our Protocol: Concrete Details

  22. Concept of Rewinding • A central concept in the formal analysis of crypto protocols • To prove adversary knows a string s • just run the adversary many times from different points (called rewinding the adversary machine) • observe protocol messages • compute string s and output

  23. Our Protocol for i in [ID] s Com(s1[i]), Com(s2[i]) ch[i] open sch[i][i] ID • For all i, s1[i]  s2[i] = s • Hence, two shares for any i sufficient to recover s • Identity encoded in length of challenge (= ID) 23

  24. Proof of Security L-id R-id Com(ls1[i]), Com(ls2[i]) Com(rs1[i]), Com(rs2[i]) R-ch’ R-ch with [R-id] length L-ch’ L-ch with [L-id] length open chosen shares open chosen shares rs ls • To prove security • Need to rewind the adversary and recover the secret rs • Can’t rewind honest party on the left • Idea: run protocol once, then • rewind adversary, give a different challenge R-ch’ • see response and recover rs • Problem: Can’t rewind left honest party; can’t given chosen shares to adv

  25. Proof of Security L-id R-id Com(ls1[i]), Com(ls2[i]) Com(rs1[i]), Com(rs2[i]) R-ch with [R-id] length L-ch with [L-id] length Receiver open chosen shares open chosen shares Commiter • Assume identities from “small” domain (logarthmic) • Assume R-id > L-id • At least two right chall mapping to same left chall (pigeon hole ) • Gives possibility to get two responses on right and give only one on left

  26. Proof of Security L-id R-id Com(ls1[i]), Com(ls2[i]) Com(rs1[i]), Com(rs2[i]) R-ch with [R-id] length L-ch with [L-id] length Receiver open chosen shares open chosen shares Commiter • Experiment to find a collision (R-ch, R-ch’  L-ch) • Replay the same reply in the left execution • Reply in the right execution enables recovery of rs Extraction successful !!

  27. Final Construction • This construction • Only works for identities coming from a logarithmic domain (need to find a collision) • Assumes that the adversary always gives correct answers • The ideas presented here don’t directly extend to the general case • Final construction: • Gives constant round non-malleable commitments for general adversaries • relies on a fair bit of probability/combinatorial analysis

  28. Prior Work • Long line of prior works on non-malleable commitments [Dolev-Dwork-Naor’91, Barak’02, Pass-Rosen’05,…., Wee’10] • All previous constructions either: • very inefficient (used heavy PCP machinery), or, • Non-standard assumptions • This work: avoids PCP machinery + uses only OWF

  29. Other Contributions in this Work • Techniques in this work allow us to solve several other connected open problems • Constant round oblivious transfer -> constant round secure multi-party computation • Black-box constant round non-malleable zero-knowledge • Follow up works using / improving our construction in various direction [Jain-Pandey’12, Goyal-Lee-Ostrovsky-Visconti’12, Garg-Goyal-Jain-Sahai’12]

  30. Thank You!

More Related