Yehuda Lindell
IBM T.J.Watson


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.


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


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).


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.

REAL
adversary A adversary S
?
Protocol interaction
Trusted party
IDEAL


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 ).


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.

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


“ 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).


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.


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 .

Alice Bob
One set of parties executing a single protocol in isolation .


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!


This setting does not realistically model the security concerns of modern networks.

A more realistic model:

Alice Bob
Many parties running many protocol executions.


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.


A taxonomy of composition

4 parameters:




The context
The participating parties
The scheduling
The number of executions


1)
What else is happening in the network (or with which protocols should the secure protocol compose):
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


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 order of executions:



Sequential
Parallel
Concurrent

Hybrid type: concurrent with timing


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).


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 .


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]


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.

1) 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 zeroknowledge (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 twoparty computation (e.g., self composition ) be achieved without setup assumptions?

No honest majority and no setup:
Notion
Universal composability ( UC ):
Concurrent general composition:
Concurrent self composition:
Feasibility
ZK and Commit – X
Other functions – ?
?
?


Question 1:

What functionalities can and cannot be UC computed without setup assumptions, in the no honest majority case?


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).



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 .


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 .


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 .

Arbitrary interaction
Environment write inputs/ read outputs
Protocol interaction

Arbitrary interaction
Environment write inputs/ read outputs
Trusted party

Environment
Protocol interaction
REAL
?
Trusted party
IDEAL



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.


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.


IDEA: What happens if the environment just plays the role of an honest party in the protocol?



Environment runs code of honest party P
1
.
All messages are forwarded by the adversary between the environment and honest party P
2
.
Otherwise, adversary does nothing.

Environment
Protocol interaction

Environment extract input

Environment
Protocol interaction

Environment
Protocol interaction
Protocol interaction

Environment
Protocol interaction extract input
Trusted party

Environment
Protocol interaction extract input
Trusted party

Environment
Protocol interaction extract input
NOTE: Input extraction happens before any interaction with the trusted party.
Trusted party

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

Protocol interaction

Protocol interaction extract input


Conclusion: a real adversary can use the idealmodel 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.


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.

No honest majority and no setup:
Notion
Universal composability ( UC ):
Concurrent general composition:
Concurrent self composition:
Feasibility
ZK and Commit – X
Other functions – ?
?
?


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!


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?


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.


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


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


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.


IMPOSSIBILITY:

Broad impossibility results of specializedsimulator UC hold for any definition implying concurrent general composition.


“ 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 ” .


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.

Arbitrary network activity
Arbitrary network activity adversary A ?
adversary S
REAL
Secure protocol interaction
Trusted party
HYBRID


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.



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 .




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 .

Environment
=
Protocol interaction
UC-REAL
Arbitrary network activity
Protocol interaction
GENERAL-REAL

Arbitrary network activity
Arbitrary network activity

Protocol interaction
GENERAL-REAL
Trusted party
GENERAL-HYBRID

Arbitrary network activity
=
Trusted party
GENERAL-HYBRID
Environment
Trusted party
UC-IDEAL

No honest majority and no setup:
Notion
Universal composability ( UC ):
Concurrent general composition:
Concurrent self composition:
Feasibility
ZK and Commit – X
Many functions – X
?
– X
?


Impossibility results are always definitiondependent.

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).




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)?

Alice
Bob
A single pair of parties running the same protocol many times concurrently.

adversary A adversary S
?
REAL
Protocol interaction
Trusted party
IDEAL



This is the model considered for concurrent zero-knowledge
Equivalent to a scenario of many pairs of parties (with corruption limitation)


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 .


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).




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  )


Conclusion:

 is also secure when run concurrently with any protocol  . That is,  is secure under concurrent general composition .


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.

No honest majority and no setup:
Notion
Universal composability ( UC ):
Concurrent general composition:
Concurrent self composition:
Feasibility
ZK and Commit – X
Many functions – X
Many functions
?
–
–
X
X


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


Simulator (for proving security) uses only oracle access to adversary
Non black-box simulation Black-box simulation


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.


Holds for natural functionalities:


Blind signatures
Oblivious transfer

Demonstrates that even this weak concurrent setting is “ hard ” .

Compare to concurrent zero-knowledge.

No honest majority and no setup:
Notion Feasibility
ZK and Commit – X
Many functions – X
Universal composability
( UC ):
Concurrent general composition:
Concurrent self composition: m-bounded concurrent self composition
Many functions – X
Many functions – X
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 .

No honest majority and no setup:
Notion Feasibility
ZK and Commit – X
Many functions – X
Universal composability
( UC ):
Concurrent general composition:
Concurrent self composition: m-bounded concurrent self composition
Many functions – X
Many functions – X
Black-box > m rounds
Non black-box > m bits

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


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.


Impossibility for UC (and specialized-simulator UC)
Concurrent general composition implies
(specialized-simulator) UC

Therefore: impossibility for concurrent general composition
Unbounded concurrent self composition implies concurrent general composition

Therefore: impossibility for concurrent self composition

No honest majority and no setup:
Notion Feasibility
Universal composability
( UC ):
Concurrent general composition:
Concurrent self composition: m-bounded concurrent self composition
ZK and Commit – X
Many functions – X
Many functions – X
Many functions – X
Black-box > m rounds
Non black-box > m bits


Many open question remain. E.g:

Exact characterizations



Probabilistic functions for concurrent general compostion
Further relaxations (e.g., on input distributions, input correlations, nonadaptive choice of inputs etc.)
Bounded concurrent self composition with arbitrary sets of parties






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