Impossibility Results for Concurrent Two-Party Computation

1
Impossibility Results for Concurrent Two-Party
Computation

• Yehuda Lindell
• IBM T.J.Watson

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

3
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

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

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

6
The Security Definition
IDEAL
REAL
7
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).

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

9
Remark

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

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

11
Proving Security of Protocols

• The ideal-model adversarys 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 partys 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.

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

13
The Stand-Alone Model
Alice
Bob

• One set of parties executing a single protocol in
  isolation.

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

15
Stand-Alone Computation?

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

16
The Concurrent Model
Alice
Bob
Many parties running many protocol executions.

17
Composition vs Stand-Alone

• Security in the stand-alone setting does not
  imply security under composition.
• Therefore, the feasibility results of the late
  80s do not apply.
• Conclusion the question of feasibility for
  secure computation needs to be re-examined for
  the setting of protocol composition.

18
Protocol Composition - Overview

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

19
The Context

• 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)
• General Composition secure protocol runs
  together with arbitrary other protocols (e.g.
  UC)
• Crucial difference regarding network control

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

21
The Scheduling

• The order of executions
• Sequential
• Parallel
• Concurrent
• Hybrid type concurrent with timing

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

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

24
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

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

26
Fundamental Questions

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

27
Feasibility

• No honest majority and no setup

Feasibility Notion
ZK and Commit X Other functions ? Universal composability (UC)
? Concurrent general composition
? Concurrent self composition
28
Our Results
29
Feasibility of UC

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

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

31
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, Yaos millionaires problem cannot be
  UC computed.
• We also have broad results for general functions
  (where parties may receive different output) and
  for probabilistic functionalities.

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

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

34
UC real model
35
UC ideal model
Arbitrary interaction
write inputs/ read outputs
36
UC Security

• A protocol is UC secure if
• for every real-model adversary A,
• there exists an ideal-model adversary S,
• such that
• Z cannot distinguish between a real execution
  with A and an ideal execution with S.

37
UC Security
Environment
?
Trusted party
IDEAL
REAL
38
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
  environments code (i.e., access is black-box)
• This property is essential to the proof of the UC
  composition theorem, and to our impossibility
  results.

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

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

41
Recall The Real Model
Environment
Protocol interaction
42
Recall Ideal Model Simulation
Environment
43
Back to The Real Model
Environment
Protocol interaction
44
The Real Execution
Environment
Protocol interaction
Protocol interaction
45
The Ideal Simulation
Environment
Protocol interaction
Trusted party
46
The Ideal Simulation
Environment
Protocol interaction
Trusted party
47
The Ideal Simulation
Environment
Protocol interaction
NOTE Input extraction happens before
any interaction with the trusted party.
Trusted party
48
Equivalently
Protocol interaction

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

49
An Attack
Protocol interaction
50
An Attack
Protocol interaction

• Conclusion a real adversary can use the
  ideal-model simulator in order to extract the
  honest partys input.
• E.g., this rules out computing any function that
  does not reveal the honest partys input.

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

52
Feasibility

• No honest majority and no setup

Feasibility Notion
ZK and Commit X Universal composability (UC)
? Concurrent general composition
? Concurrent self composition
Many functions X
Other functions ?
53
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!

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

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

56
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

57
Preliminaries (continued)

• Important observation
• Most of the impossibility results for UC
  described before hold also for specialized-simulat
  or UC.
• Specifically
• Deterministic two-party functions where both
  parties get output (slightly weaker)
• Deterministic privacy preserving functions
• Warning does not hold for probabilistic
  functionalities

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

59
Corollary 1

• IMPOSSIBILITY
• Broad impossibility results of specialized-simulat
  or UC hold for any definition implying concurrent
  general composition.

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

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

62
The Security Definition
Arbitrary network activity
Arbitrary network activity
HYBRID
REAL
63
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.

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

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

66
Graphical Proof
Environment

Protocol interaction
UC-REAL
GENERAL-REAL
67
Proof (continued)
?
GENERAL-REAL
GENERAL-HYBRID
68
Proof (continued)
Arbitrary network activity

Trusted party
GENERAL-HYBRID
UC-IDEAL
69
Feasibility

• No honest majority and no setup

Feasibility Notion
ZK and Commit X Many functions X Universal composability (UC)
Concurrent general composition
? Concurrent self composition
?
Many functions X
70
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).

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

72
The Model of Concurrency
Bob
Alice
A single pair of parties running the same
protocol many times concurrently.

73
The Security Definition
adversary S
adversary A
Protocol interaction
IDEAL
REAL
Trusted party
74
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)

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

76
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).
77
Proof Idea

• Let f be a function that enables bit transmission
  (e.g., lt).
• 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 ?)

78
Proof Idea (cont.)

• Conclusion
• ? is also secure when run concurrently with any
  protocol ?. That is, ? is secure under concurrent
  general composition.

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

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

81
Feasibility

• No honest majority and no setup

Feasibility Notion
ZK and Commit X Many functions X Universal composability (UC)
Concurrent general composition
Concurrent self composition
Many functions X
?
Many functions X
82
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

83
Black-Box Simulation

• Simulator (for proving security) uses only oracle
  access to adversary

Black-box simulation
Non black-box simulation
84
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.

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

86
Feasibility

• No honest majority and no setup

Feasibility Notion
ZK and Commit X Many functions X Universal composability (UC)
Many functions X Concurrent general composition
Many functions X Concurrent self composition
m-bounded concurrent self composition
?
Black box gt m rounds
87
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.

88
Feasibility

• No honest majority and no setup

Feasibility Notion
ZK and Commit X Many functions X Universal composability (UC)
Many functions X Concurrent general composition
Many functions X Concurrent self composition
m-bounded concurrent self composition
Black-box gt m rounds
Non black-box gt m bits
Non black-box ?
89
Conclusion

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

90
Is there any good news?
91
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.

92
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 (specialize
d-simulator) UC
Unbounded concurrent self composition implies
concurrent general composition
93
Summary

• No honest majority and no setup

Feasibility Notion
ZK and Commit X Many functions X Universal composability (UC)
Many functions X Concurrent general composition
Many functions X Concurrent self composition
m-bounded concurrent self composition
Black-box gt m rounds
Non black-box gt m bits
94
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

95
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