Impossibility Results for Concurrent Two-Party

Computation

Yehuda LindellIBM T.J.Watson

A Basic Problem of Cryptography:

Secure Computation A set of parties with private inputs.

Parties wish to jointly compute a function of their inputs so that (amongst other things): Privacy: each party receives its output and

nothing else. Correctness: the output is correctly computed

Properties must be ensured even if some of the parties maliciously attack the protocol.

Security Requirements Consider a secure auction (with secret

bids): An adversary may wish to learn the bids of all

parties – to prevent this, require PRIVACY An adversary may wish to win with a lower bid

than the highest – to prevent this, require CORRECTNESS

But, the adversary may also wish to ensure that it always gives the highest bid – to prevent this, require INDEPENDENCE OF INPUTS

Defining Security Option 1:

Analyze security concerns for each specific problem

Auctions: as in previous slide Elections: privacy and correctness only (?)

Problems: How do we know that all concerns are

covered? Definitions are application dependent (no

general results, need to redefine each time).

Defining Security – Option 2 The real/ideal model paradigm:

Ideal model: parties send inputs to a trusted party, who computes the function and sends the outputs.

Real model: parties run a real protocol with no trusted help.

Informally: a protocol is secure if any attack on a real protocol can be carried out in the ideal model.

Since no attacks can be carried out in the ideal model, security is implied.

The Security Definition:

IDEALREAL

??Trusted party

Protocolinteraction

adversary A adversary S

“Formal” Security Definition A protocol securely computes a

function f if: For every real-model adversary A,

there exists an ideal-model adversary S, such that

the result of a real execution of with A is indistinguishable from the result of an ideal execution with S (where the trusted party computes f).

Why This Definition? General – it captures ALL applications.

The specifics of an application are defined by its functionality, security is defined as above.

The security guarantees achieved are easily understood (because the ideal model is easily understood).

We can be confident that we did not “miss” any security requirements.

Remark

All the results presented here are according to this definitional paradigm.

Proving Security of Protocols “REQUIREMENTS”:

The output of the ideal-model adversary must have the same distribution as the output of the real-model adversary.

The output of the honest party in the ideal model (with the ideal adversary) must have the same distribution as the output the honest party in the real model (with the real adversary).

Proving Security of Protocols The ideal-model adversary’s output must

be like that of the real-model adversary: Internally invoke the real adversary,

simulate a real execution, output whatever the real adversary does.

The honest party’s output must be the “same” in the real and ideal executions: In the above simulation, “extract” the input

used by the real adversary and send it to the trusted party.

Proving Security of Protocols Given a real-model adversary, construct

an ideal-model adversary that does the following: Internally invoke the real-model adversary Simulate a real execution for the real

adversary Extract the input used by the real

adversary, and send it to the trusted party Obtain the output from the trusted party

and cause the simulated real execution to terminate with this output.

The Stand-Alone Model

Alice Bob

One set of parties executing a single protocol in isolation.

Feasibility for Stand-Alone Any multi-party functionality can

be securely computed: honest majority: information theoretic

[BGW88,CCD88,RB89] no honest majority: assuming

trapdoor permutations [Y86,GMW87]

That is: any distributed task can be carried out securely!

Stand-Alone Computation?

This setting does not realistically model the security concerns of modern networks.

A more realistic model:

The Concurrent Model

Many parties running many protocol executions.

Alice Bob

Composition vs Stand-Alone Security in the stand-alone setting does

not imply security under composition.

Therefore, the feasibility results of the late 80’s do not apply.

Conclusion: the question of feasibility for secure computation needs to be re-examined for the setting of protocol composition.

Protocol Composition - Overview

A taxonomy of composition

4 parameters: The context The participating parties The scheduling The number of executions

The Context What else is happening in the network (or

with which protocols should the secure protocol compose):

1) Self Composition: many executions of a single protocol (protocols runs with itself – e.g. ZK)

1) General Composition: secure protocol runs together with arbitrary other protocols (e.g. UC)

Crucial difference regarding network control

The Participating Parties Who is running the executions:

A single set of parties: same set of parties (and often same roles – e.g., ZK).

Arbitrary sets of parties: possibly different and intersecting sets.

The Scheduling The order of executions:

Sequential Parallel Concurrent

Hybrid type: concurrent with timing

Number of Executions Standard notion:

Unbounded Concurrency: the number of secure protocol executions can be any polynomial

More restricted notion: Bounded Concurrency: a priori bound

on the number of executions (and protocol can rely on this bound).

Classifying Some Known Work Concurrent zero-knowledge [DNS98]:

Model of concurrent self composition with a single set of parties

Feasibility with arbitrary scheduling [RK99] Much work on the round complexity of black-box

and non-black-box zero-knowledge

Universal composition [Ca01]: UC is a stringent security definition that

guarantees secure under concurrent general composition with arbitrary sets of parties.

Universal Composability -

Feasibility Positive Results - Any multi-party

functionality can be securely computed: honest majority: no setup assumptions [Ca01] no honest majority: in the common reference

string model (and assuming trapdoor permutations) [CLOS02]

Negative Results: Impossibility for specific zero-knowledge

and commitment functionalities without setup assumptions [CF01,Ca01]

Remark Security definitions vs composition

operations: UC security implies security under concurrent

general composition UC security = security definition Concurrent general composition = composition

operation

Sometimes can be the same (by defining security directly by the desired composition operation).

For UC (and other cases), it is not.

Fundamental Questions1) What functionalities can and cannot be UC

computed without setup assumptions, in the no honest majority case?

2) Are the impossibility results for commitment and zero-knowledge (and possibly others) due to quirks of the UC definition, or are they inherent to concurrent general composition?

3) What about other definitions and other settings of concurrency? That is, can some type of concurrent two-party computation (e.g., self composition) be achieved without setup assumptions?

Feasibility

No honest majority and no setup:

NotionFeasibility

Universal composability (UC):

ZK and Commit – X Other functions – ?

Concurrent general composition:

?

Concurrent self composition:

?

Our Results

Feasibility of UC

Question 1: What functionalities can and cannot

be UC computed without setup assumptions, in the no honest majority case?

Feasibility of UC Setting: no honest majority and no trusted

setup phase.

We focus on the important two-party case.

Recall: UC zero-knowledge and commitment already ruled out (but for specific definition of these functionalities).

Impossibility Results Example: consider deterministic two-

party functions where both parties receive the same output: Such a function can be UC computed IF AND

ONLY IF it depends on only one parties’ input and is efficiently invertible.

Therefore, Yao’s millionaire’s problem cannot be UC computed.

We also have broad results for general functions (where parties may receive different output) and for probabilistic functionalities.

Definition: Secure Computation Recall the ideal/real model simulation

paradigm: Ideal model: parties send inputs to a trusted

party, who computes the function and sends the outputs.

Real model: parties run the protocol with no trusted help.

Informally: a protocol is secure if any attack on a real protocol can be carried out in the ideal model.

UC Definition Introduces an additional adversarial

entity called the environment Z.

Z provides inputs to the parties, reads their outputs and interacts with the adversary throughout the execution.

Z represents the external environment, and acts an an interactive distinguisher.

UC real model

Protocolinteraction

Arbitraryinteraction

write inputs/read outputs

Environment

UC ideal modelEnvironment

Trusted party

Arbitraryinteraction

write inputs/read outputs

UC SecurityEnvironment

??IDEALREAL

Protocolinteraction

Trusted party

UC Definition – Remarks The real-model and ideal model

adversaries interact with the environment in the same way.

This interaction is on-line: The adversary cannot rewind the environment The adversary does not have access to the

environment’s code (i.e., access is black-box)

This property is essential to the proof of the UC composition theorem, and to our impossibility results.

Key Observation

Our impossibility results are derived from the following observation: In the plain model and with no honest

majority, the UC ideal-model simulator has no advantage over a real adversary.

In other words, whatever the simulator can do (e.g., extraction), a real adversary can also do.

Proving the Observation

IDEA: What happens if the environment just plays the role of an honest party in the protocol? Environment runs code of honest party P1. All messages are forwarded by the

adversary between the environment and honest party P2.

Otherwise, adversary does nothing.

Recall: The Real Model

Protocolinteraction

Environment

extract input

Recall: Ideal Model Simulation

Environment

Back to The Real Model

Protocolinteraction

Environment

The Real Execution

Protocolinteraction

Environment

Protocolinteraction

extract input

The Ideal SimulationEnvironment

Protocolinteraction

Trusted party

extract input

The Ideal SimulationEnvironment

Protocolinteraction

Trusted party

extract input

The Ideal SimulationEnvironment

Protocolinteraction

Trusted party

NOTE: Input extraction happens before anyinteraction with the trusted party.

extract input

Equivalently

Protocolinteraction

Conclusion: the ideal-model simulator simulates (including extraction) while in a real protocol execution; exactly like a real adversary.

An Attack

Protocolinteraction

extract input

An Attack

Protocolinteraction

Conclusion: a real adversary can use the ideal-model simulator in order to extract the honest party’s input.

E.g., this rules out computing any function that does not reveal the honest party’s input.

UC Feasibility – Conclusions Ruled out large classes of two-party

functionalities.

Note 1: we do not have complete characterizations for feasibility

Note 2: there do exist interesting 2-party functions that can be UC computed: Key exchange, secure message transmission… However, these are of a “non-standard” nature.

Feasibility

No honest majority and no setup:

NotionFeasibility

Universal composability (UC):

ZK and Commit – X

Concurrent general composition:

?

Concurrent self composition:

?

Other functions – ?Many functions – X

Inherent Impossibility? These results relate to the specific

definition of UC.

Universal composability implies concurrent general composition, but the reverse is not known to hold.

So, this does not answer the question of feasibility of obtaining security under concurrent general composition!

Feasibility: General Composition

Question 2: Are the impossibility results for UC

security inherent to concurrent general composition?

Equivalently, is it possible to achieve concurrent general composition, via some other definition, without an honest majority or setup?

Optimality of UC

Importance: Do UC impossibility results hold for

general composition (feasibility study perspective)?

Is UC the “right” definition (protocol designer perspective)?

This is of interest even in settings where secure protocols can be obtained.

Preliminaries Specialized-simulator UC:

A relaxed variant of the UC definition UC requires a single simulator for all

“environments” In this variant, every “environment”

can have a different simulator

Preliminaries (continued) Important observation:

Most of the impossibility results for UC described before hold also for specialized-simulator UC.

Specifically: Deterministic two-party functions where

both parties get output (slightly weaker) Deterministic privacy preserving functions

Warning: does not hold for probabilistic functionalities

Main Result

Theorem: security under concurrent general composition implies specialized-simulator UC.

The theorem holds even if the secure protocol is run only once in the arbitrary network.

Corollary 1

IMPOSSIBILITY: Broad impossibility results of

specialized-simulator UC hold for any definition implying concurrent general composition.

Corollary 2

“ALMOST” OPTIMALITY OF UC: Any definition achieving concurrent

general composition must be secure under specialized-simulator UC.

Conclusion: specialized-simulator UC is not “too restrictive”.

This is an indication that UC is also not “too restrictive”.

General Composition – Definition Follows the ideal/real model paradigm.

The ideal (or hybrid) model: parties run an arbitrary protocol and have access to a trusted party computing f. (Inputs for f can be influenced by ). Denote f.

The real model: parties run an arbitrary protocol and concurrently run a protocol (instead of using the trusted party). Denote .

A protocol is secure if any attack on the real model can be carried out in the hybrid model.

The Security Definition:

HYBRIDREAL

??adversary S

Trusted party

Arbitrary networkactivity

Arbitrary networkactivity

adversary A

Secure protocolinteraction

General Composition – Definition Security Definition:

A protocol is secure under concurrent general composition if for every protocol , any adversarial attack on (i.e. real) can be carried out in f (i.e. hybrid).

Note: a secure protocol exhibits the same behavior as an ideal execution for f, for every protocol to which it runs concurrently.

Proving the Theorem If a protocol is secure under concurrent

general composition, then is like f. For specialized-simulator UC, need to

show that UC-IDEAL with f is like UC-REAL with (for some environment Z).

Let Z be an environment. Design a protocol that emulates Z. By design, f is like UC-IDEAL with f and

Z. Likewise, is like UC-REAL with and Z.

Proof of the Theorem By the security of , is like f. But, remember that f is like UC-

IDEAL with f and Z, and is like UC-REAL with and Z.

Therefore, UC-IDEAL with f is like UC-REAL with (for Z).

That is, is specialized-simulator UC.

Protocolinteraction

Arbitrary networkactivity

Graphical ProofEnvironment

UC-REAL

Protocolinteraction

GENERAL-REAL

=

Proof (continued)

Protocolinteraction

Arbitrary networkactivity

Arbitrary networkactivity

Trusted party

GENERAL-REAL GENERAL-HYBRID

Proof (continued)Arbitrary network

activity

Trusted party

GENERAL-HYBRID UC-IDEAL

=

Environment

Trusted party

Feasibility

No honest majority and no setup:

NotionFeasibility

Universal composability (UC):

ZK and Commit – X Many functions – X

Concurrent general composition:

Concurrent self composition:

?

?Many functions – X

Caveat

Impossibility results are always definition-dependent.

So too, our results here are based on a specific definition of concurrent general composition (that we believe is as weak as possible while still capturing what is needed).

Feasibility: Self Composition

Question 3:

What about other definitions and other settings of concurrency?

Can concurrent self composition be achieved without set-up assumptions (or an honest majority)?

The Model of Concurrency

A single pair of parties running the same protocol many times

concurrently.

Alice Bob

The Security Definition:

IDEALREAL

??

Trusted party

Protocolinteraction

adversary A adversary S

The Model of Concurrency

This is the model considered for concurrent zero-knowledge

Equivalent to a scenario of many pairs of parties (with corruption limitation)

Main Result Theorem:

Consider functions which enable “bit transmission” (e.g., by fixing inputs, can be used for each party to send a bit to the other).

Then, such a function can be securely computed under concurrent self composition IF AND ONLY IF it can be securely computed under concurrent general composition.

Impossibility Results

Corollary: There exist large classes of functions*

that cannot be securely computed under concurrent self composition, even with just a single set of parties.

* This class is more restricted than that known for general composition (i.e., need bit transmission).

Proof Idea Let f be a function that enables bit

transmission (e.g., <). Assume that a protocol for computing f

is secure under concurrent self composition.

Then, emulate by running many copies of only: For calls to in , just call For -messages in , use bit transmission

capability of f (i.e., again use calls to )

Proof Idea (cont.)

Conclusion: is also secure when run

concurrently with any protocol . That is, is secure under concurrent general composition.

Conclusion

Concurrent self composition (for many functions) is actually “no easier” to obtain than concurrent general composition.

Caveat: it is crucial that the definition of self composition here is such that inputs may be chosen adaptively, based on previous outputs.

Functions Without Bit Transmission Proposition: There exist functionalities

that can be securely computed under concurrent

self composition, but cannot be securely computed under

concurrent general composition.

The functionality: zero knowledge proof of knowledge. Use concurrent zero knowledge for

simulation, extraction is straightforward.

NotionFeasibility

Universal composability (UC):

ZK and Commit – X Many functions – X

Concurrent general composition:

Concurrent self composition:

Many functions – X

Feasibility

No honest majority and no setup:

?Many functions – X

Getting Desperate…

What about m-bounded concurrent self composition? Consider a bound m on number of

concurrent executions Design a protocol that remains secure

for up to m concurrent executions only

Black-Box Simulation Simulator (for proving security)

uses only oracle access to adversary

Non black-box simulation Black-box simulation

Negative Result (Black-Box)

Theorem: There exist two-party functionalities such that every protocol that remains secure under m-bounded concurrent self composition, and is proven using black-box simulation, requires more than m rounds.

Negative Results (Black-Box) Holds for natural functionalities:

Blind signatures Oblivious transfer

Demonstrates that even this weak concurrent setting is “hard”.

Compare to concurrent zero-knowledge.

NotionFeasibilityUniversal composability (UC):

ZK and Commit – X Many functions – X

Concurrent general composition:

Many functions – X

Concurrent self composition:

Many functions – X

m-bounded concurrent self composition

FeasibilityNo honest majority and no setup:

?Black box > m rounds

Non Black Box Theorem:

Consider functions which enable “bit transmission” (e.g., by fixing inputs, can be used for each party to send a bit to the other).

Then, any protocol that securely computes such a function under m-bounded concurrent self composition must have communication complexity greater than m.

NotionFeasibilityUniversal composability (UC):

ZK and Commit – X Many functions – X

Concurrent general composition:

Many functions – X

Concurrent self composition:

Many functions – X

m-bounded concurrent self composition

FeasibilityNo honest majority and no setup:

Black-box > m rounds

Non black-box > m bitsNon black-box – ?

Conclusion

For m-bounded concurrent self composition: Either many rounds (black-box) Or “very long” messages (or at least

dependence on m).

Is there any good news?

Positive Results Theorem:

For every function f and every m, there exists an O(m)-round protocol that securely computes f under m-bounded concurrent self composition.

(Protocol also has very long messages)

Subsequently, [PR03] presented a constant round protocol with “very long” messages.

Summary – Flow of Results Impossibility for UC (and specialized-simulator

UC)

Therefore: impossibility for concurrent general composition

Therefore: impossibility for concurrent self composition

Concurrent general composition implies(specialized-simulator) UC

Unbounded concurrent self composition implies concurrent general composition

NotionFeasibilityUniversal composability (UC):

ZK and Commit – X Many functions – X

Concurrent general composition:

Many functions – X

Concurrent self composition:

Many functions – X

m-bounded concurrent self composition

SummaryNo honest majority and no setup:

Black-box > m rounds

Non black-box > m bits

Open Questions Many open question remain. E.g:

Exact characterizations Probabilistic functions for concurrent

general compostion Further relaxations (e.g., on input

distributions, input correlations, non-adaptive choice of inputs etc.)

Bounded concurrent self composition with arbitrary sets of parties

Credits Impossibility for UC

Eurocrypt 2003, Joint work with Ran Canetti (IBM) & Eyal Kushilevitz (Technion)

Impossibility for concurrent general composition FOCS 2003

Black-box lower-bound for self composition (and protocol for bounded-concurrent self composition) STOC 2003

Non-black-box impossibility for self composition and lower bound on communication complexity Submitted 2003