Download presentation
Presentation is loading. Please wait.
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: IDEALREAL ? Trusted party Protocol interaction adversary Aadversary S
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 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.
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 AliceBob 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 Many parties running many protocol executions. AliceBob
17
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.
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): 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
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: FeasibilityNotion 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, 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.
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 Protocol interaction Arbitrary interaction write inputs/ read outputs Environment
35
UC ideal model Environment Trusted party 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 ? IDEALREAL Protocol interaction Trusted party
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 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.
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 P 1. All messages are forwarded by the adversary between the environment and honest party P 2. Otherwise, adversary does nothing.
41
Recall: The Real Model Protocol interaction Environment
42
extract input Recall: Ideal Model Simulation Environment
43
Back to The Real Model Protocol interaction Environment
44
The Real Execution Protocol interaction Environment Protocol interaction
45
extract input The Ideal Simulation Environment Protocol interaction Trusted party
46
extract input The Ideal Simulation Environment Protocol interaction Trusted party
47
extract input The Ideal Simulation Environment Protocol interaction Trusted party NOTE: Input extraction happens before any interaction with the trusted party.
48
extract input 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
extract input An Attack Protocol interaction 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.
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: FeasibilityNotion ZK and Commit – XUniversal composability (UC): ? Concurrent general composition: ? Concurrent self composition: Other functions – ? Many functions – X
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-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
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- simulator 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: HYBRIDREAL ? adversary S Trusted party Arbitrary network activity Arbitrary network activity adversary A Secure protocol interaction
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
Protocol interaction Arbitrary network activity Graphical Proof Environment UC-REAL Protocol interaction GENERAL-REAL =
67
Proof (continued) Protocol interaction Arbitrary network activity Arbitrary network activity Trusted party GENERAL-REALGENERAL-HYBRID
68
Proof (continued) Arbitrary network activity Trusted party GENERAL-HYBRID UC-IDEAL = Environment Trusted party
69
Feasibility No honest majority and no setup: FeasibilityNotion 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 A single pair of parties running the same protocol many times concurrently. Alice Bob
73
The Security Definition: IDEALREAL ? Trusted party Protocol interaction adversary A adversary S
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., <). 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
FeasibilityNotion ZK and Commit – X Many functions – X Universal composability (UC): Concurrent general composition: Concurrent self composition: Many functions – X Feasibility No honest majority and no setup: ?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 Non black-box simulation 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
FeasibilityNotion 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 Feasibility No honest majority and no setup: ? Black box > 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
FeasibilityNotion 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 Feasibility No honest majority and no setup: Black-box > m rounds Non black-box > 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 (specialized-simulator) UC Unbounded concurrent self composition implies concurrent general composition
93
FeasibilityNotion 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 Summary No honest majority and no setup: Black-box > m rounds Non black-box > 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
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.