1

Vipul Goyal Microsoft Research, India

Constructing Non-Malleable Commitments

2

Commitment Schemes [Blum’84]

Com(s)

CombinationReceiverCommitter

s?s?

s

• Commitment like a note placed in a combination safe• Two properties: hiding and binding• Electronic equivalent of such a safe

Opening of Com(s)

3

Contract Bidding

Com(s)

• Legitimate businessman: doesn’t want to leak his bid (during bidding phase), need crypto

s?s? ?

s

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

5

g, ga, gb, s.gab

a, bCommitter

s

• After commitment phase: s hidden; gab reqd to get s• Binding: a, b unique given commitment phase, hence s

unique

• DDH assumption: given (g, ga, gb), any information about gab is hard to compute

Receiver

Generate a,b randomly

6

Contract Bidding: is a commitment sufficient?

Com(s)

• Adversary still cheats and creates a winning bid

s?s? Com(0.99s)

7

Hiding doesn’t imply Non-malleability

7

ga, gb, s.gab

a, b

Committer ga, gb, 0.99.s.gab

a, b Receiver

• Simply multiply the last string by 99/100• Design of non-malleable commitments: not an easy

problem

8

Non-Malleable Commitments

• Introduced in the seminal work of Dolev, Dwork and Naor [DDN91]

Picture credit: R. Pass

• 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

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

10

• 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

ss'

11

NM Commitment: Definition

11

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

ss'

12

Ideas behind our Scheme

12

• Commitment stage to have multiple rounds of interaction

• Use a “normal” commitment scheme Com and convert into non-malleable

s

13

Our Protocol: Intuitive Overview

14

First Idea: every committer commits differently

14

• Different committers have different identities (say 1 to 100); identities public

• Two stages: • one with label ID• one with 100 - ID

ID = 25

25

75

s

15

Key Idea: every committer commits differently

15

• 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

ID = 25

Com(s), Com(s), …(25 times)

Com(s), Com(s) …(75 times)

s

16

Man-in-the-middle Scenario

16

• Lets look at left and right interactions• At least one stage where right label > left label

25

37

25

37

75

63

17

Man-in-the-middle Scenario

17

• 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?

k commitments to s

k’ commitments to s’

s s'

. . .

. . . ?

Problem: Adversary creates several commitments on right using one on the left

18

Prevent Replication: use Interaction

Com(s1), Com(s2)

b in {1,2}

opening of Com(sb) ReceiverCommiter

• s1 and s2: secret shares of s; s1 s2 = s

• Scheme still hiding + binding

open remaining Com

s

19

Prevent Replication contd..

19

Com(s1), Com(s2)

1

opening of Com(s1)

1

2

.

.• Gets only one opening from left

• Might need to open both ?

20

Overall Idea

20

Com(s1[1]), Com(s2[1])

ch[1]

open

• Formal Analysis: next

Com(s1[ID]), Com(s2[ID])

ch[ID]

open

. . .

Proof: all commitments same

ID

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

23

Com(s1[i]), Com(s2[i])

ch[i]

open sch[i][i]

• 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)

ID

s

for i in [ID]

24

Proof of Security

Com(ls1[i]), Com(ls2[i])

• 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

L-idCom(rs1[i]), Com(rs2[i])

L-ch with [L-id] length

open chosen shares

R-ch with [R-id] length

open chosen shares

R-id

ls rs

R-ch’L-ch’

25

Proof of Security

Com(ls1[i]), Com(ls2[i])

L-ch with [L-id] length

open chosen shares Receiver

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

L-idCom(rs1[i]), Com(rs2[i])

R-ch with [R-id] length

open chosen shares

R-id

26

Proof of Security

Com(ls1[i]), Com(ls2[i])

L-ch with [L-id] length

open chosen shares Receiver

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

L-idCom(rs1[i]), Com(rs2[i])

R-ch with [R-id] length

open chosen shares

R-id

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!