slide1
Download
Skip this Video
Download Presentation
Vipul Goyal Microsoft Research, India

Loading in 2 Seconds...

play fullscreen
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
slide1

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