Survey: Secure Composition of
Multiparty Protocols
Yehuda Lindell
IBM T.J. Watson
Secure Multiparty Computation


A set of parties with private inputs.
Parties wish to jointly compute a function of
their inputs so that certain security properties
(like privacy and correctness) are preserved.


E.g., secure elections, auctions…
Properties must be ensured even if some of
the parties maliciously attack the protocol.
Secure Computation Tasks

Examples:

Authentication protocols

Online payments

Auctions

Elections

Privacy preserving data mining

Essentially any task…
Defining Security

Security is formulated by comparing a real protocol
execution to an ideal execution with a trusted party
[GMW,GL,Be,MR,Ca]:




Real model: parties run a real protocol with no trusted help.
Ideal model: parties send inputs to a trusted party, who
computes the function for them.
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 Real Model
x
y
Protocol output
Protocol output
The Ideal Model
x
y
x
f1(x,y)
f1(x,y)
y
f2(x,y)
f2(x,y)
The Security Definition:
For every real
adversary A

there exists an
adversary S
Computational Indistinguishability: every probabilistic
Protocol
polynomial-time observer that receives the input/output
interaction
distribution of the honest parties and the adversary, outputs 1
upon receiving the distribution generated in IDEAL with
negligibly close probability to when it is generated
REAL.
Trustedinparty
REAL
IDEAL
Meaning of the Definition

Interpretation 1:


Security in the ideal model is absolute. Since no
attacks are possible in the ideal model, we obtain
that the same is also true of the real model.
Interpretation 2:


Anything that an adversary could have
learned/done in the real model, it could have also
learned/done in the ideal model.
Note: real and ideal adversaries have same
complexity.
Properties of the Definition

Privacy:



The ideal-model adversary cannot learn more about the honest
party’s input than what is revealed by the function output.

Thus, the same is true of the real-model adversary.

Otherwise, the REAL and IDEAL could be easily distinguished.
Correctness:

In the ideal model, the function is always computed correctly.

Thus, the same is true in the real-model.

Otherwise, the REAL and IDEAL could be easily distinguished.
Others:

For example, independence of inputs
Feasibility Results

A fundamental theorem: any multi-party
problem can be securely computed:



Computational setting: for any number of
corruptions and assuming trapdoor permutations
[Y86,GMW87]
Information theoretic setting: for a 2/3 majority
(or regular majority given a broadcast channel)
[BGW88,CCD88,RB89,B89]
In summary: any distributed task can be
carried out securely!
What’s Left?



Wide-ranging feasibility results already
achieved.
As we have seen, any distributed computing
task can be carried out in a secure way!
But, these results all considered a standalone model of computation…
The Classic Stand-Alone Model
Alice
Bob
One set of parties executing a single
protocol in isolation.
Stand-Alone?


Doesn’t realistically model the modern
network setting.
Rather:
Security Under Composition
Alice
Bob
Many parties running many different
protocol executions.
Concurrent Composition


Many protocol executions are run at the same time
(with arbitrary scheduling of messages).
In modern network settings:


Secure protocols are run many times, by the same and
different users

Many different secure protocols are run at the same time

Secure protocols are run alongside insecure protocols
All of the above are loosely categorized as
“concurrent composition”.
Composition can also be considered for the sequential and parallel cases.
Here we focus on the concurrent case only.
Research on Concurrent
Composition

Initial works looked at specific problems, and
specific security properties:

Witness indistinguishability [FS90]

Non-malleability [DDN91]

Zero knowledge [DNS98], followed by [KPR98, RK99, R00,
KP01, CKPR01, B01, PRS02] and much more…

There have been many later works on a variety of
problems (e.g., oblivious transfer [GM00], key exchange
[CK02], authenticated Byzantine agreement [LLR02]).
General Feasibility?

The above-mentioned work all considered a
very limited type of composition:


The same protocol running many times and where
parties have “fixed roles”.
In addition, the above all considered specific
tasks (and not general feasibility for secure
multiparty computation).
A Research Project in Progress

Understand the feasibility of obtaining security
under concurrent composition:



Formalize security in a setting where many different
protocols are executed concurrently
Provide answers to the question of whether or not
security can be achieved in this setting, and under
what assumptions.
Construct secure protocols, where possible.
Restating the Project Aim

Background:



It has been shown that security in the stand-alone
setting does not imply security under protocol
composition.
Therefore, the feasibility results of the late 80’s do
not hold in this setting.
Fundamental question:

Is it possible to achieve security in the setting
of protocol composition, and if yes, for what
problems and under what assumptions?
Concurrent General Composition



A secure protocol runs
together with arbitrary
network activity.
Arbitrary network
activity
The arbitrary network
activity can include both
secure and insecure
protocols
Realistically models
setting of modern
networks.
Secure protocol
interaction
Security: General Composition
Arbitrary network
activity
Arbitrary network
activity
adversary A
Secure protocol
interactions
REAL
Trusted party
IDEAL
Security: General Composition
Arbitrary network
activity
Arbitrary network
activity
adversary A
Secure protocol
interactions
REAL
adversary S
Trusted party
IDEAL
Security: General Composition
Arbitrary network
activity
Arbitrary network
activity
adversary A
Secure protocol
interactions
REAL

adversary S
Trusted party
IDEAL
Step 1: Formalizations of Security

Aim: provide a definition with which it is
possible to prove the security of protocols
under concurrent general composition


Preferably, the definition should relate to a standalone setting, and security under composition
should be derived via a composition theorem
First rigorous definition (and composition
theorem) provided in [PW00]

Considered the case that a secure protocol is run
once in an arbitrary network (system)
Security in the General Case

Universal composability (UC-security) [Ca01]:




Considers the case that secure protocols are run
any polynomial number of times in an arbitrary
network
As with previous work, the definition relates to a
“stand-alone setting”, and is accompanied by a
“composition theorem”
Theorem: any protocol that is UC-secure remains
secure under concurrent general composition
Note: UC is a definition of security, the security
goal is that of concurrent general composition.
Feasibility of UC Security

The Good News:


Theorem 1: Assuming that a majority of the parties
are honest, there exists a UC-secure protocol for any
multiparty functionality [C01].
Theorem 2: In the common reference string model*,
there exists a UC-secure protocol for essentially any
multiparty functionality and for any number of
corrupted parties [CLOS02].
*In the common reference string model, a string is chosen according to
a predetermined distribution and posted on a “secure” bulletin board.
Feasibility of UC Security


Recall: any protocol that is UC-secure, is
secure under concurrent general composition.
Therefore, security under concurrent general
composition (and thus security in real network
settings) can be achieved:

assuming an honest majority or

assuming a common reference string
and under appropriate complexity assumptions
Honest Majority and Trust

Assuming an honest majority or a trusted setup phase
is highly undesirable:




Honest majority – not realistic for many modern settings
Trusted setup phase – who do we trust? (A lot of damage if
trust is broken.)
Question: Can we achieve UC-security without these
assumptions?
First ominous sign:


It is impossible to construct UC-secure zero-knowledge and
commitment protocols (for a specific formulation) [CF01,Ca01]
What about other formulations, other functionalities?
Broad Impossibility for UC

Theorem [CKL03]:



In a setting with no honest majority and no trusted setup,
there exist large classes of functions that cannot be
computed under the definition of UC-security.
For example, if any privacy of inputs is preserved by
the function, then it cannot be securely computed
under the UC definition.
Key exchange, secure channels, signatures are
exceptions and can be realized [CK02,Ca04]
Alternatives to UC?



Fact 1: the UC definition provides very strong security
guarantees.
Fact 2: the UC definition suffers from severe
impossibility results.
Aim: find a different definition that provides the same
security guarantees, and doesn’t suffer from the UC
impossibility results.


Reason for hope: UC is a very stringent definition
(significantly more stringent than stand-alone defs)
We also have other existing definitions, what about [PW00]?
Alternatives Do Not Exist

Theorem [L03a]:



Any protocol that is secure under concurrent
general composition, is also UC-secure.
This holds even if the secure protocol is executed
only once in an arbitrary network.
Corollary:

Any definition that implies security under general
composition suffers from broad impossibility
results. This includes the definition of [PW00].
Interpretation of the Result

We prove this theorem for a specific definition of
security under concurrent general composition



The definition is arguably as “weak as possible”,
while still within the ideal/real model paradigm
However, it may be possible to bypass this with
weaker definitions (we will discuss this later).
Nevertheless, the desired (natural) definition is
completely ruled out.
What Now?



It is desirable to obtain security

Without an honest majority (arguably, essential)

Without a trusted setup phase (who do we trust?)
But we cannot obtain security under general
composition in this case!
Suggestion: consider weaker notions of
composition
Self Composition



Many executions of a
single protocol.
Captures the issue of
many executions of a
secure protocol, but not
the interaction with
other secure or insecure
protocols.
Define an IDEAL world
with many calls to a
trusted party.
Secure protocol
interaction
Feasibility of Self Composition

Self composition seems much easier:



No interaction of different secure protocols
together
No arbitrary (possibly insecure) protocol running
alongside
Can secure protocols be constructed for this
(weaker) notion of composition?
Equivalence and Impossibility

Theorem [L04a]:


A protocol securely computes a function under
self composition if and only if it securely computes
it under general composition.
Corollary: all the impossibility results for
general composition hold for self composition
as well.
Proof of Equivalence

General composition  self composition:


Easy: self composition is a special case of general
composition
Self composition  general composition:

Main observation: a protocol execution can be used
by the parties to send arbitrary bits to each other.
Proof of Equivalence


Assume that a protocol  is secure under self
composition.
Emulate the arbitrary network by running
many copies of  only:



An execution of  is just an execution of .
An arbitrary message of length m is sent by
running m copies of , sending 1 bit each time.
Since  remains secure in this emulation, it
also remains secure under general
composition.
Bypassing the Impossiblity

Direction 1: Consider restricted networks (for
example, restrict concurrency in some way)


Restriction should still be realistic enough to model
real network settings
Direction 2: Consider weaker notions of
security

Definitions should still be strong enough to
provide real security guarantees
Restricted Network Settings
Two Types of Restrictions

Assumptions on the network:


Enforceable policy:


Assume that the network behaves in a certain
way. E.g., TIMING assumptions.
Honest parties agree to behave in a certain way.
E.g., SELF composition, honest parties keep some
inputs independent from other executions.
Preferable to not have either of the above:

If we do adopt a restriction: the more reasonable,
the better.
Bounding the Number of
Executions (Network Assumption)

What about m-bounded concurrent self
composition?




Assume a bound m on the number of concurrent
executions
Design a protocol that remains secure for up to m
concurrent executions only
Note 1: for general composition impossibility holds
even for one execution. We therefore only consider
self composition here.
Note 2: this assumption is very problematic…
Lower Bounds

Black-box simulation:


Protocols for m-bounded concurrent self
composition require at least m rounds of
communication [L03b]
General (even non-black-box) simulation:

Protocols for m-bounded concurrent self
composition require at least m bits of
communication [L04a]
Positive Results (Protocols)

Theorem [L03b]:


Theorem [PR03]:


Every two-party function can be securely computed under mbounded self composition, in a constant number of rounds.
Theorem [P04]:



Every two-party function can be securely computed under mbounded self composition.
Every multi-party function can be securely computed under mbounded self composition, in a constant number of rounds.
A non-constant-round protocol also exists without any corruption
limitation. (Previous protocols had such a limitation.)
Note: These protocols still have high bandwidth (as they must due to
the communication complexity lower bound).
Timing Assumptions

Assume that:



Local clocks have small drift (network assumption)
Bound on network latency can be estimated
(needed only for validity, not security)
Arguably, timing assumptions are very
realistic (much moreso than bounded
composition, for example).
Positive Result

Theorem [L04b]:


Every two-party function can be securely
computed under self composition with timing
assumptions.
Limitations:



Two-party versus multi-party
Considers only two parties running many
executions (this generalizes to client/server model
with corruption limitation, but is still limited).
Nevertheless promising…
Local Sequentiality

Honest parties locally run executions strictly
sequentially (enforceable policy) in a multiparty network


Note: globally, there is concurrency
Theorem [L04b]:

If a protocol securely computes a function under
locally sequential self composition, then it securely
computes it under concurrent self composition
(with fixed scheduling).
Weaker Notions of Security
The Main Idea

Provide the IDEAL adversary with more
power than the REAL adversary.

Used by [P02] for concurrent zero-knowledge (real
adversary=polynomial; ideal adversary=quasipolynomial).
“Generalized UC” [PS04]


Alternative definition based on UC
Security guarantee: any protocol that is secure under
“generalized UC” has the following property:


For every REAL (probabilistic polynomial-time) adversary there
exists an IDEAL (super-polynomial time adversary) that
provides the security guarantees of concurrent general
composition with respect to every arbitrary NETWORK.
Theorem [PS04]:

There exist protocols for securely computing any multiparty
functionality under the definition of “generalized UC”, for any
number of corrupted parties and without setup assumptions.
Summary & Conclusions
Summary of Positive Results

Any multi-party functionality can be securely
computed under concurrent general
composition:


Assuming an honest majority [C01]
Without an honest majority but in the common
reference string model [CLOS02]
Summary of Positive Results

Restricted network models:



Any multi-party functionality can be securely computed
under bounded self composition, without an honest
majority or trusted setup phase [L03b,PR03,P04]
Any two-party functionality can be securely computed under
self composition with timing, without a trusted setup phase
[L04b]
Weaker notions of security:

Any multi-party functionality can be securely computed
under generalized UC, without an honest majority or
trusted setup phase [PS04]
Summary of Impossibility

Without an honest majority or a trusted setup phase:




Broad impossibility results for universal composability
[CKL03]
These impossibility results extend to any definition that
achieves security under concurrent general composition
[L03a]
By the equivalence between self and general
composition, we also have broad impossibility results
for (unbounded) self composition [L04a] and even
locally sequential self composition [L04b].
There are also lower bounds on bounded concurrent
self composition [L03b,L04a]
Future Research

Due to the extensive impossibility results,
alternative avenues need to be explored:

Continue studying feasibility in (realistic) restricted
networks:



Has proven successful wrt bounded self composition and
timing.
Other possibilities…
Consider weaker notions of security definitions:


Initial steps in this direction have already been taken
with success in [PS04]
What about complexity assumptions? Other notions?
Final Word




Concurrent composition is a fact of life of real
network settings.
Protocols that are proven secure in the stand-alone
model are not necessarily secure under composition.
Therefore, it does not suffice to prove that a protocol
is secure in the stand-alone model.
If we want to promote the use of “provably secure”
protocols, we must prove them secure in the right
model.