impossibility results for concurrent two-party computation
DESCRIPTION
Impossibility Results for Concurrent Two-Party Computation. Yehuda Lindell IBM T.J.Watson. 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): - PowerPoint PPT PresentationTRANSCRIPT
![Page 1: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/1.jpg)
Impossibility Results for Concurrent Two-Party
Computation
Yehuda LindellIBM T.J.Watson
![Page 2: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/2.jpg)
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.
![Page 3: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/3.jpg)
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
![Page 4: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/4.jpg)
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).
![Page 5: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/5.jpg)
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.
![Page 6: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/6.jpg)
The Security Definition:
IDEALREAL
??Trusted party
Protocolinteraction
adversary A adversary S
![Page 7: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/7.jpg)
“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).
![Page 8: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/8.jpg)
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.
![Page 9: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/9.jpg)
Remark
All the results presented here are according to this definitional paradigm.
![Page 10: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/10.jpg)
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).
![Page 11: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/11.jpg)
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.
![Page 12: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/12.jpg)
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.
![Page 13: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/13.jpg)
The Stand-Alone Model
Alice Bob
One set of parties executing a single protocol in isolation.
![Page 14: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/14.jpg)
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!
![Page 15: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/15.jpg)
Stand-Alone Computation?
This setting does not realistically model the security concerns of modern networks.
A more realistic model:
![Page 16: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/16.jpg)
The Concurrent Model
Many parties running many protocol executions.
Alice Bob
![Page 17: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/17.jpg)
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.
![Page 18: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/18.jpg)
Protocol Composition - Overview
A taxonomy of composition
4 parameters: The context The participating parties The scheduling The number of executions
![Page 19: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/19.jpg)
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
![Page 20: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/20.jpg)
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.
![Page 21: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/21.jpg)
The Scheduling The order of executions:
Sequential Parallel Concurrent
Hybrid type: concurrent with timing
![Page 22: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/22.jpg)
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).
![Page 23: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/23.jpg)
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.
![Page 24: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/24.jpg)
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]
![Page 25: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/25.jpg)
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.
![Page 26: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/26.jpg)
Fundamental Questions1) 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?
![Page 27: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/27.jpg)
Feasibility
No honest majority and no setup:
NotionFeasibility
Universal composability (UC):
ZK and Commit – X Other functions – ?
Concurrent general composition:
?
Concurrent self composition:
?
![Page 28: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/28.jpg)
Our Results
![Page 29: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/29.jpg)
Feasibility of UC
Question 1: What functionalities can and cannot
be UC computed without setup assumptions, in the no honest majority case?
![Page 30: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/30.jpg)
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).
![Page 31: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/31.jpg)
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.
![Page 32: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/32.jpg)
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.
![Page 33: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/33.jpg)
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.
![Page 34: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/34.jpg)
UC real model
Protocolinteraction
Arbitraryinteraction
write inputs/read outputs
Environment
![Page 35: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/35.jpg)
UC ideal modelEnvironment
Trusted party
Arbitraryinteraction
write inputs/read outputs
![Page 36: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/36.jpg)
UC SecurityEnvironment
??IDEALREAL
Protocolinteraction
Trusted party
![Page 37: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/37.jpg)
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.
![Page 38: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/38.jpg)
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.
![Page 39: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/39.jpg)
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.
![Page 40: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/40.jpg)
Recall: The Real Model
Protocolinteraction
Environment
![Page 41: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/41.jpg)
extract input
Recall: Ideal Model Simulation
Environment
![Page 42: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/42.jpg)
Back to The Real Model
Protocolinteraction
Environment
![Page 43: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/43.jpg)
The Real Execution
Protocolinteraction
Environment
Protocolinteraction
![Page 44: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/44.jpg)
extract input
The Ideal SimulationEnvironment
Protocolinteraction
Trusted party
![Page 45: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/45.jpg)
extract input
The Ideal SimulationEnvironment
Protocolinteraction
Trusted party
![Page 46: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/46.jpg)
extract input
The Ideal SimulationEnvironment
Protocolinteraction
Trusted party
NOTE: Input extraction happens before anyinteraction with the trusted party.
![Page 47: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/47.jpg)
extract input
Equivalently
Protocolinteraction
Conclusion: the ideal-model simulator simulates (including extraction) while in a real protocol execution; exactly like a real adversary.
![Page 48: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/48.jpg)
An Attack
Protocolinteraction
![Page 49: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/49.jpg)
extract input
An Attack
Protocolinteraction
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.
![Page 50: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/50.jpg)
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.
![Page 51: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/51.jpg)
Feasibility
No honest majority and no setup:
NotionFeasibility
Universal composability (UC):
ZK and Commit – X
Concurrent general composition:
?
Concurrent self composition:
?
Other functions – ?Many functions – X
![Page 52: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/52.jpg)
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!
![Page 53: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/53.jpg)
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?
![Page 54: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/54.jpg)
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.
![Page 55: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/55.jpg)
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
![Page 56: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/56.jpg)
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
![Page 57: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/57.jpg)
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.
![Page 58: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/58.jpg)
Corollary 1
IMPOSSIBILITY: Broad impossibility results of
specialized-simulator UC hold for any definition implying concurrent general composition.
![Page 59: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/59.jpg)
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”.
![Page 60: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/60.jpg)
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.
![Page 61: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/61.jpg)
The Security Definition:
HYBRIDREAL
??adversary S
Trusted party
Arbitrary networkactivity
Arbitrary networkactivity
adversary A
Secure protocolinteraction
![Page 62: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/62.jpg)
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.
![Page 63: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/63.jpg)
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.
![Page 64: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/64.jpg)
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.
![Page 65: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/65.jpg)
Protocolinteraction
Arbitrary networkactivity
Graphical ProofEnvironment
UC-REAL
Protocolinteraction
GENERAL-REAL
=
![Page 66: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/66.jpg)
Proof (continued)
Protocolinteraction
Arbitrary networkactivity
Arbitrary networkactivity
Trusted party
GENERAL-REAL GENERAL-HYBRID
![Page 67: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/67.jpg)
Proof (continued)Arbitrary network
activity
Trusted party
GENERAL-HYBRID UC-IDEAL
=
Environment
Trusted party
![Page 68: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/68.jpg)
Feasibility
No honest majority and no setup:
NotionFeasibility
Universal composability (UC):
ZK and Commit – X Many functions – X
Concurrent general composition:
Concurrent self composition:
?
?Many functions – X
![Page 69: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/69.jpg)
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).
![Page 70: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/70.jpg)
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)?
![Page 71: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/71.jpg)
The Model of Concurrency
A single pair of parties running the same protocol many times
concurrently.
Alice Bob
![Page 72: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/72.jpg)
The Security Definition:
IDEALREAL
??
Trusted party
Protocolinteraction
adversary A adversary S
![Page 73: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/73.jpg)
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)
![Page 74: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/74.jpg)
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.
![Page 75: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/75.jpg)
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).
![Page 76: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/76.jpg)
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 )
![Page 77: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/77.jpg)
Proof Idea (cont.)
Conclusion: is also secure when run
concurrently with any protocol . That is, is secure under concurrent general composition.
![Page 78: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/78.jpg)
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.
![Page 79: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/79.jpg)
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.
![Page 80: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/80.jpg)
NotionFeasibility
Universal composability (UC):
ZK and Commit – X Many functions – X
Concurrent general composition:
Concurrent self composition:
Many functions – X
Feasibility
No honest majority and no setup:
?Many functions – X
![Page 81: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/81.jpg)
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
![Page 82: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/82.jpg)
Black-Box Simulation Simulator (for proving security)
uses only oracle access to adversary
Non black-box simulation Black-box simulation
![Page 83: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/83.jpg)
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.
![Page 84: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/84.jpg)
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.
![Page 85: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/85.jpg)
NotionFeasibilityUniversal composability (UC):
ZK and Commit – X Many functions – X
Concurrent general composition:
Many functions – X
Concurrent self composition:
Many functions – X
m-bounded concurrent self composition
FeasibilityNo honest majority and no setup:
?Black box > m rounds
![Page 86: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/86.jpg)
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.
![Page 87: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/87.jpg)
NotionFeasibilityUniversal composability (UC):
ZK and Commit – X Many functions – X
Concurrent general composition:
Many functions – X
Concurrent self composition:
Many functions – X
m-bounded concurrent self composition
FeasibilityNo honest majority and no setup:
Black-box > m rounds
Non black-box > m bitsNon black-box – ?
![Page 88: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/88.jpg)
Conclusion
For m-bounded concurrent self composition: Either many rounds (black-box) Or “very long” messages (or at least
dependence on m).
![Page 89: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/89.jpg)
Is there any good news?
![Page 90: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/90.jpg)
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.
![Page 91: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/91.jpg)
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
![Page 92: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/92.jpg)
NotionFeasibilityUniversal composability (UC):
ZK and Commit – X Many functions – X
Concurrent general composition:
Many functions – X
Concurrent self composition:
Many functions – X
m-bounded concurrent self composition
SummaryNo honest majority and no setup:
Black-box > m rounds
Non black-box > m bits
![Page 93: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/93.jpg)
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
![Page 94: Impossibility Results for Concurrent Two-Party Computation](https://reader030.vdocument.in/reader030/viewer/2022032607/56813069550346895d964676/html5/thumbnails/94.jpg)
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