Constructing Non-Malleable Commitments
Download
1 / 30

Vipul Goyal Microsoft Research, India - PowerPoint PPT Presentation


  • 81 Views
  • Uploaded on

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.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Vipul Goyal Microsoft Research, India' - nitza


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

Constructing Non-Malleable Commitments

Vipul Goyal

Microsoft Research, India


Commitment schemes blum 84
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


Contract bidding
Contract Bidding

s

Com(s)

s?

?

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


Constructing commitment scheme
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


Elgamal commitment scheme
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


Contract bidding is a commitment sufficient
Contract Bidding: is a commitment sufficient?

Com(s)

s?

Com(0.99s)

  • Adversary still cheats and creates a winning bid


Hiding doesn t imply non malleability
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


Non malleable commitments
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


Outline of the talk
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


Nm commitment definition
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


Nm commitment definition1
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


Ideas behind our scheme
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



First idea every committer commits differently
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


Key idea every committer commits differently
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


Man in the middle scenario
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


Man in the middle scenario1
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


Prevent replication use interaction
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


Prevent replication contd
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


Overall idea
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



Concept of rewinding
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


Our protocol
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


Proof of security
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


Proof of security1
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


Proof of security2
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 !!


Final construction
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


Prior work
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


Other contributions in this work
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]



ad