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
Top Related