Survey secure composition of multiparty protocols
1 / 56

Survey on Secure Composition of Multiparty Protocols - PowerPoint PPT Presentation

  • Uploaded on

Survey: Secure Composition of Multiparty Protocols. Yehuda Lindell IBM T.J. Watson. Secure Multiparty Computation. A set of parties with private inputs.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Survey on Secure Composition of Multiparty Protocols' - sherlock_clovis

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

Secure multiparty computation l.jpg
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 l.jpg
Secure Computation Tasks

  • Examples:

    • Authentication protocols

    • Online payments

    • Auctions

    • Elections

    • Privacy preserving data mining

    • Essentially any task…

Defining security l.jpg
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 l.jpg



Protocol output

Protocol output

The Real Model

The ideal model l.jpg
The Ideal Model









Slide7 l.jpg

For every real

adversary A

there exists an

adversary S



Trusted party

The Security Definition:

Computational Indistinguishability:every probabilistic polynomial-time observer that receives the input/output 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 in REAL.



Meaning of the definition l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 astand-alonemodel of computation…

The classic stand alone model l.jpg
The Classic Stand-Alone Model



One set of parties executing a single protocol in isolation.

Stand alone l.jpg

  • Doesn’t realistically model the modern network setting.

  • Rather:

Security under composition l.jpg
Security Under Composition



Many parties running many different protocol executions.

Concurrent composition l.jpg
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 “concurrentcomposition”.

Composition can also be considered for the sequential and parallel cases.

Here we focus on the concurrent case only.

Research on concurrent composition l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
Concurrent General Composition

  • A secure protocol runs together with arbitrary network activity.

  • The arbitrary network activity can include both secure and insecure protocols

  • Realistically models setting of modern networks.

Arbitrary network


Secure protocol


Slide21 l.jpg

adversary A

Security: General Composition

Arbitrary network


Arbitrary network


Secure protocol


Trusted party



Slide22 l.jpg

adversary A

adversary S

Security: General Composition

Arbitrary network


Arbitrary network


Secure protocol


Trusted party



Slide23 l.jpg

adversary A

adversary S

Security: General Composition

Arbitrary network


Arbitrary network


Secure protocol


Trusted party



Step 1 formalizations of security l.jpg
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 stand-alone 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 l.jpg
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 l.jpg
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 security27 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 existingdefinitions, what about [PW00]?

Alternatives do not exist l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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


Feasibility of self composition l.jpg
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 l.jpg
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 l.jpg
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 equivalence38 l.jpg
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 l.jpg
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

Two types of restrictions l.jpg
Two Types of Restrictions

  • Assumptions on the network:

    • Assume that the network behaves in a certain way. E.g., TIMING assumptions.

  • Enforceable policy:

    • 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 l.jpg
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 l.jpg
Lower Bounds

  • Black-box simulation:

    • Protocols for m-bounded concurrent self composition require at least mrounds of communication [L03b]

  • General (even non-black-box) simulation:

    • Protocols for m-bounded concurrent self composition require at least mbits of communication [L04a]

Positive results protocols l.jpg
Positive Results (Protocols)

  • Theorem [L03b]:

    • Every two-party function can be securely computed under m-bounded self composition.

  • Theorem [PR03]:

    • Every two-party function can be securely computed underm-bounded self composition, in a constant number of rounds.

  • Theorem [P04]:

    • Every multi-party function can be securely computed underm-bounded 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 l.jpg
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 l.jpg
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 l.jpg
Local Sequentiality

  • Honest parties locally run executions strictly sequentially (enforceable policy) in a multi-party 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).

The main idea l.jpg
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=quasi-polynomial).

Generalized uc ps04 l.jpg
“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 of positive results l.jpg
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 results53 l.jpg
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 atrusted 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 l.jpg
Summary of Impossibility

  • Without an honest majority or a trusted setup phase:

    • Broadimpossibility 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 l.jpg
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 l.jpg
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.