Non-Malleable Commitments: Constructing Secure Cryptographic Protocols

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!