Adaptively Secure Broadcast, Revisited - PowerPoint Presentation

Slide1

Adaptively Secure Broadcast, Revisited

Juan A. Garay (AT&T), Jonathan Katz (UMD),

Ranjit Kumaresan (UMD)

, Hong-Sheng Zhou (UMD)Slide2

Talk Outline

Preliminaries

Broadcast

Simulation-based

security

The

Hirt-Zikas

result [HZ10]

Adaptive attacks on broadcast protocols

Impossibility of adaptively secure broadcast!

Here:

(Re)examining their communication model

Is adaptively secure broadcast possible?Slide3

Broadcast [PSL80,LSP82]

If the sender is honest, then all

parties output the sender’s message

All honest parties always output

the same message

Message m

m

1

m

2

m

4

m

3

m

1

m

2

m

4

m

3Slide4

Modeling the Problem

Adversary model

Centralized

byzantine

adversary

Corrupts at most

t

out of

n

parties

Static

or

adaptive

adversary

Static: parties corrupted before

execution begins

Adaptive: parties corrupted during

protocol execution

Communication model

Point-to-point, secure and authenticated channels

Synchronous networkSlide5

Prior Work

Unconditional security iff

t < n/3

[PSL80, LSP82, …]

Computational security for

t < n

[PSL80, DS83, …]

Assuming a public-key infrastructure (PKI) and digital signatures

Most prior work focus on “property-based” notions of securitySlide6

Simulation-Based Security

Awkward or difficult to define adaptive security using property-based definitions

“If the sender is honest, then…” – but what if the sender starts honest and is later corrupted?

Cleaner definitions using the

simulation paradigm

(Side benefits: secure composition; security under concurrent executions) Slide7

The Simulation Paradigm [GMW87]

Ideal-world with a trusted third party

carrying out task

Real-world cryptographic protocol Slide8

The Simulation Paradigm (cont’d)

≈

REAL

IDEALSlide9

REAL

Universally

Composable

Security [Can01]

IDEAL

≈

Environment

Concurrent CompositionSlide10

The Broadcast Functionality

Functionality

F

BC

:

F

BC

receives

m

from the sender;

D FBC

sends m to all recipients.Slide11

Adaptively Secure Broadcast?

Hirt-Zikas ’10:

Adaptive attacks on all existing broadcast protocols

All existing broadcast protocols are

not adaptively secureSlide12

An Adaptive Attack

1

st

round

Later…

Message v

v’

v'

v’

v’

Message v’Slide13

Adaptively Secure Broadcast?

Hirt-Zikas ’10:

Adaptive attacks on all existing broadcast protocols

Adaptively secure broadcast is

impossible

for

t > n/2Slide14

Communication Model: A Closer Look

Adversary can corrupt sender & change its messages

in the same round.

Crucial for their impossibility result

Sender’s messages cannot be changed once sent

[Can00,LLR02,…]

No corruption “in the middle of a round”

“Atomic delivery model”

[HZ10] modelSlide15

Is Adaptive Security Possible?

Is adaptively secure broadcast possible for

t > n/2

if we assume “atomic” message delivery?

Note: [HZ10] attacks work on known protocols even in this model

Yes! Adaptively secure broadcast is possible for

t < nSlide16

Relaxed Broadcast

Functionality

F

RBC

[HZ10]

F

RBC

receives

m

from the sender;

D F

RBC sends

m to the adversary

D

The adversary decides whether to corrupt the sender; if it does, the adversary may change m

to any desired value

D F

RBC sends m

to all recipients

Existing protocols (e.g., [DS83]) give adaptively secure

relaxed

broadcast for

t < nSlide17

Commitments

m

m

Alice

(message

m

)

Bob

Hiding:

m

hidden from Bob

Binding: Alice can open commitment only to

mSlide18

Our Broadcast Protocol

1. Sender

sends

commitment to m

using

F

RBC

2. Sender sends the

decommitment

to each receiver via point-to-point

channels

3. Each receiver broadcasts the

decommitment

they received using FRBC

4. All players agree on the first valid

decommitment

, and output the corresponding message

mSlide19

Avoiding Adaptive Attacks

1. Sender sends commitment to

m

using

F

RBC

2. Sender sends the

decommitment

to each receiver via point-to-point channels

3. Each receiver broadcasts the

decommitment

they received using

F

RBC

4. All players agree on the first valid

decommitment

, and output the corresponding message

m

Adversary learns nothing about m

All honest parties receive the decommitment

Even if the sender is corrupted, the committed value cannot be changedSlide20

Simulation

1. Sender sends commitment to m

using

F

RBC

2.

Simulator

gets m from

F

BC

and generates a

decommitment

to m; it then sends this to all parties via point-to-point channels

3. Each receiver broadcasts

decommitment

via

FRBC

4. All players agree on a valid

decommitment, and output the corresponding message

m

Simulator sends dummy commitments

UC commitments allow simulator to open com to any

mSlide21

Setup Assumptions?

As written, we use

UC commitments

UC commitment require additional setup assumptions + stronger cryptographic assumptions that we would like to avoid!

In fact,

honest-binding

commitments suffice

Binding once the sender acts honestly during the commit phase

Can be realized with no additional setup, based on OWF

Example based on Pedersen’s commitment:

Honest sender

Input

m

Choose

h,x

com =

(h, gm

hx)

Simulator

(No input)

Choose r,y

com = (gr, g

y)

Equivocation

On input

mSet x = (y-m)/r

Output (g

r,x)Slide22

Our Result (Summarized)

Assuming a PKI and digital signatures,

there exists a (universally composable) broadcast protocol

secure against adaptive corruption of any t < n partiesSlide23

Applications to Secure Computation

Protocols for secure computation typically designed/analyzed assuming a broadcast channel

Plug in a protocol that realizes

F

BC

 security when run over a point-to-point network

Can we use a protocol realizing

F

RBC

instead?

Better efficiency…?

Secure computation in [HZ10] network model?

We observe that FRBC

suffices for most specific constructions

Messages broadcast are always commitments to some valueSlide24

Summary

Adaptively secure broadcast for

t < n

Assuming the ‘standard’ synchronous communication model

Our result:

Matches the threshold for statically secure broadcast

Requires no additional setup or assumptions

Can be safely used within arbitrary other protocolsSlide25

Thank You