Concurrent Secure Computation with Optimal Query Complexity
 4 Citations
 2.5k Downloads
Abstract
The multiple ideal query (MIQ) model [Goyal, Jain, and Ostrovsky, Crypto’10] offers a relaxed notion of security for concurrent secure computation, where the simulator is allowed to query the ideal functionality multiple times per session (as opposed to just once in the standard definition). The model provides a quantitative measure for the degradation in security under concurrent selfcomposition, where the degradation is measured by the number of ideal queries. However, to date, all known MIQsecure protocols guarantee only an overall average bound on the number of queries per session throughout the execution, thus allowing the adversary to potentially fully compromise some sessions of its choice. Furthermore, [Goyal and Jain, Eurocrypt’13] rule out protocols where the simulator makes only an adversaryindependent constant number of ideal queries per session.
We show the first MIQsecure protocol with worstcase persession guarantee. Specifically, we show a protocol for any functionality that matches the [GJ13] bound: The simulator makes only a constant number of ideal queries in every session. The constant depends on the adversary but is independent of the security parameter.
As an immediate corollary of our main result, we obtain the first password authenticated key exchange (PAKE) protocol for the fully concurrent, multiple password setting in the standard model with no setup assumptions.
Keywords
Commitment Scheme Main Thread Concurrent Execution Auxiliary Input Splitting Factor1 Introduction
General feasibility results for secure computation were established nearly three decades ago in the seminal works of [14, 33]. However, these results only promise security for a protocol if it is executed in isolation, “unplugged” from any network activity. In particular, these results are not suitable for the Internet setting where multiple protocol executions may occur concurrently under the control of a common adversary.
A Brief History of Concurrent Security. Towards that end, an ambitious effort to understand and design concurrently secure protocols kicked into gear with early works such as [10, 15], and later the study of the concurrent zero knowledge setting [7, 11, 23, 30, 32]. For other functionalities and in more general settings, however, farreaching impossibility results were established [1, 3, 6, 8, 13, 18, 24]. These results refer to the “plain model” where the participating parties have no trusted setup, and hold even if the parties have access to pairwise authenticated communication and a broadcast channel.
Two main lines of research have emerged in order to circumvent these impossibility results. The first concerns with the use of trusted setup assumptions such as a common random string, strong public key infrastructure or tamperproof hardware tokens (see, e.g. [2, 5, 22]).
The second line of research is dedicated to the study of weaker security definitions that allow for positive results in the plain model, without additional trust assumptions. The most notable examples of this include security w.r.t. superpolynomial time simulation [4, 9, 12, 28, 31] and inputindistinguishable computation [12, 26]. One main drawback in this line of research is that it is not always clear by “how much” is the definition of security relaxed, or in other words “how much security” is being lost due to concurrent attacks.
The Multiple Ideal Query Model and Its Applications. The multiple ideal query model (or, the MIQ model in short) of Goyal, Jain and Ostrovsky [21] takes a different approach to the problem of quantifying the security loss. In this model, the simulator is allowed to query the ideal functionality multiple times per session (as opposed to just once in the standard definition). On the technical side, allowing the simulator multiple queries indeed facilitates proofs of security in a concurrent setting. On the conceptual side, this model allows for a natural quantification of the “security loss” incurred by concurrent attack: the more ideal queries, the weaker the security guarantee. Furthermore, the effect of multiple ideal queries strongly depends on the task at hand, thus allowing for more finetuned notions of security for a given problem or setting.
One functionality where this approach proved very effective is that of passwordbased key exchange (namely the twoparty function that outputs a secret random value to both parties if the inputs provided by the two parties are equal). When the number of queries made by the simulator per session is a constant, the security guarantees of the MIQ model actually imply fully concurrent passwordbased authenticated key exchange (see [16, 17, 21]). This fact was exploited by Goyal et al. [21] to get the first concurrent PAKE in the plain model — albeit with the significant restriction that the same password is to be used as input in every session. This restriction results from a weakness in their modeling and analysis  a weakness that we overcome in this work.
The Central Question: How Many Queries? So, how to best bound the number of ideal queries made by the simulator? Intuitively, if we allow a large number of queries, then the security guarantee may quickly degrade and become meaningless; in particular, if enough queries are allowed, then the adversary may be able to completely learn the inputs of the honest parties. On the other hand, if the number of allowed queries is very small (say only \(1+\epsilon \) per session) then the security guarantee is very close to that of the standard definition.
To exemplify this further, consider 1outofm OT. Here, as long as \(\lambda \), the simulator’s query complexity, is smaller than m, MIQ provides meaningful security which degrades gracefully with \(\lambda \). More generally, the remaining security for any session i in concurrently secure computation of function f is proportional to the “level of unlearnability” of \(f(\cdot ,x_i)\) after q queries, where \(x_i\) is the secret input of the honest party in session i. Passwordbased key exchange is an extreme case of an unlearnable function. Ideally, we would like to bring \(\lambda \) as close as possible to 1.
Prior Work: Average Case vs. Worst Case Guarantees. The best positive result in the MIQ model is due to Goyal, Gupta, and Jain [19] (improving upon [21]). They provide a construction where the number of ideal queries in a session are \((1+ \frac{\log ^6{n}}{n})\), where n is the security parameter. However, this is only an averagecase guarantee over the sessions that provides very weak security. In particular, it does not preclude the ideal adversary from making an arbitrarily large number of queries in some chosen sessions (while keeping the number of queries low in the other sessions). In cases of interest, such as the PAKE functionality or the above oblivious polynomial evaluation functionality, this means that the security in some sessions may be completely compromised!
Furthermore, Goyal and Jain [20] recently proved an unconditional lower bound on the number of ideal queries per session. Specifically, they show that there exists a twoparty functionality that cannot be securely realized in the MIQ model with any (adversary independent) constant number of ideal queries per session. A natural and important question is thus what is the best worstcase bound we can give on the number of ideal queries asked per session?
1.1 Our Results
In this work, we fully settle the question of worstcase number of per session ideal queries in the context of general function evaluation. Our main result is stated below.
Theorem 1.1
(Main Result (Informally Stated)). Under standard cryptographic assumptions, for every PPT functionality f, there exists a protocol in the MIQ model where the simulator makes only a constant number of ideal queries in every session. The aforementioned constant is dependent upon the adversary, and, in particular on the number of sessions (rather than being universal).
If the number of concurrent sessions being executed by the adversary is \(n^c\), then the constant in the above theorem will be derived from c.
We stress that due to the worstcase guarantee of our result, we are able to achieve, for the first time in the study of the MIQ model, meaningful security for all sessions, which is much closer to standard security for secure computation. Interestingly, our protocol is the same as the [19] protocol. Still, we provide a significantly better analysis of its security. We stress that prior to this work, no approach for obtaining a worstcase bound on the ideal query complexity was known.
Our upper bound tightly matches the lower bound of Goyal and Jain [20] which rule out protocols where the simulator makes a constant number of ideal queries per session for any universal constant. Taken together, this fully resolves the central problem in the study of the MIQ problem: a (adversary dependent) constant number of ideal queries per session is both necessary and sufficient for simulation. Thus, our work can be viewed as the final step in understanding the simulator query complexity of the MIQ model.
Fully Concurrent PAKE Without Setup. Say that a passwordbased key exchange protocol is fully concurrent if it remains secure in a setting where unboundedly many executions of the protocol run concurrently, on potentially different passwords. An immediately corollary of our main result is the resolution of the long standing open problem of designing a fully concurrent PAKE protocol in the standard model and with no setup assumptions.
1.2 Technical Overview
Simulator Query Complexity and Precise Simulation. The question of simulator query complexity in the MIQ model is intimately connected to the notion of precise simulation introduced by Micali and Pass [25]. Recall that traditional simulator strategies allow for the simulator’s running time to be an arbitrary polynomial factor of the (worstcase) running time of the real adversary. The notion of precise simulation concerns with the study of how low this polynomial can be. This idea is, in fact, much more general and can also be used in the context of resources other than running time, such as memory, etc. Thus, in the most general sense, the goal of precise simulation is to develop simulation strategies whose resource utilization is “close” to the resource utilization of the real adversary.
As observed in [21], the study of simulator query complexity in the MIQ model can also be cast as a precise simulation problem by viewing the trusted party queries as the resource of the simulator. Therefore, advances in precise simulation strategies go hand in hand with improvements in the simulator query complexity in the MIQ model. Indeed, prior works in the MIQ model [19, 21] have relied upon sophisticated precise simulation strategies in order to obtain their positive results. We note, however, that till date, all precise simulation strategies only focus on minimizing the total cost of the simulator across all the sessions. Indeed, this is why these works only yield an averagecase bound on the simulator query complexity.
In this work, we are interested in minimizing the worstcase simulator query complexity per session. In other words, we are interested in simulation strategies that guarantee local precision for every session.
Our Approach in a Nutshell. Towards that end, our starting observation is that the problem of bounding the simulator query complexity per session can be reduced to bounding the number of times the output message of a session appears in the entire simulation transcript.^{1} In other words, we need a precise (concurrent) simulation strategy where the output message of every session appears only a constant number of times across the entire simulation transcript.^{2} For this purpose, we revisit existing precise simulation strategies. Concretely, we show that a slight variant of the “sparse” rewinding strategy of Goyal, Gupta and Jain [19] (that we henceforth refer to as the GGJ simulation strategy) satisfies our desired property. We prove this by a novel, purely combinatorial analysis. Our final secure computation protocol remains essentially identical to those in the prior works in the MIQ model.
We now give an overview of the steps involved in our proof. Say that we wish to analyze the number of queries in session i. Consider the specific point in the protocol execution of session i where, the simulator actually makes a query to the ideal functionality: call this point \(p_i\) (for example, this may be the 5th message of the protocol execution in session i). This means that whenever the simulator reaches the point \(p_i\) (in the overall concurrent execution), it will have to call the trusted functionality for session i to compute the next outgoing message. Thus, now the problem reduces to simply counting how many times the point \(p_i\) occurs in the entire rewinding schedule. Observe that in each thread of execution, point \(p_i\) only occurs once. However, there could be multiple threads of execution resulting because of rewinding. Therefore, \(p_i\) may also occur multiple times in the rewinding schedule.
While a direct (full) analysis of the GGJ rewinding strategy [19] turns out to be complex, we are able to break it down into three different steps. Each step builds upon the previous one, with the final step yielding us the desired bound on the simulator query complexity. Below, we provide an informal overview of each of the three steps and refer the reader to the later sections for details.
Step 1. LazyKP with Static Scheduling: We first consider the warmup case when scheduling of messages by the adversary is static. This means that the ordering of the messages of different sessions is decided by the adversary ahead of time and is fixed (and does not change upon rewinding by the simulator). Further, instead of directly analyzing the GGJ simulator [19], here we will analyze the query complexity of the (simpler) “lazyKP” simulator [23, 29, 30] for the case where the simulator uses a splitting factor of n for rewinding. That is, during simulation, each thread is divided into n equal parts, and, each resulting part is rewound individually (resulting in different threads of execution).
In this case, we are able to prove that the simulator makes at most O(1) queries to the ideal functionality in any given session. This is done by relying on the following fact. Say that the point \(p_i\) does not occur in a given thread. Then, since the adversary only employs static scheduling, this would mean that the point \(p_i\) also cannot occur in any threads resulting from rewinding this thread. Thus, the proof reduces to a counting argument on the number of threads resulting from rewinding the part of the main thread containing \(p_i\). If d is the depth of recursion for our recursive rewinding schedule, then we are able to show that there are at most \(O(2^d)\) threads containing point \(p_i\). However, the depth d will be a constant for lazyKP simulation with splitting factor n.
Step 2. LazyKP with Dynamic Scheduling: Now we analyze a general adversary that may dynamically change the ordering of the messages across different sessions upon being rewound. Hence, different threads of execution may have different ordering of the messages. We shall continue to analyze the lazyKP simulation strategy with splitting factor n.
In this case, we prove that the simulator makes at most \(O(\log (n))\) queries to the ideal functionality in any given session. The key difficulty in this case is that even if a given thread does not contain the point \(p_i\), the threads resulting from its rewinding may still have \(p_i\). Hence, it seems hard to rule out the possibility that \(p_i\) may show up in a large number of threads throughout the simulation.
To overcome this problem, we rely on the following fact: once the point \(p_i\) is seen in the main thread of execution, it cannot occur in any thread arising out of the main thread after that point. We also observe that before this point is seen in the main thread, there seems hope to rule out its occurrence in a “large" number of look ahead threads. This relies on the symmetry of the main and the lookahead threads, and, on the fact that this point has roughly equal probability of occurring first in the main thread vs occurring first in any given look ahead thread. This step of the proof is more involved than the first step and we refer the reader to Sect. 4 for details.
Step 3. Sparsifying the LazyKP Simulation: In the final step, we analyze the sparse rewinding strategy of [19]. Very roughly speaking, the sparse rewinding strategy of [19] aims to rewind the adversary in “as few places as possible" while still solving all the sessions. More specifically, there is a cost associated with creating each look ahead, and, the goal of the rewinding strategy is to solve all sessions while minimizing the cost.
The sparse rewinding strategy of [19] builds upon the lazyKP simulator with splitting factor n. Very roughly, [19] pick a subset of the total threads resulting out of the lazyKP simulation, and choose to execute only the threads in the subset (while ignoring the remaining threads by aborting them at their start). In more detail, at each level of recursion, [19] randomly chooses \(\frac{\text {polylog}(n)}{n}\) fraction of the total threads and execute them while ignoring the rest. Interestingly, Goyal et al. [19] show that, if one uses protocols with somewhat higher round complexity, all the session will still be solved even though most of the lookahead threads are never executed.
The key idea of our final step is to leverage this sparsification in order the reduce the number of queries from \(O(\log (n))\) from the previous step to O(1). Recall from above that if we were to use the full lazyKP simulation, the point \(p_i\) would have occurred at \(O(\log (n))\) places in the entire simulation. However, now, in the GGJ rewinding strategy, it will occur only O(1) times because most of the threads will never be executed. More details are given in Sect. 5.
2 Our Model
Let \(n\) denote the security parameter. We consider malicious, static adversaries that choose whom to corrupt before the start of any protocol. We work in the static input setting, i.e., we assume that the inputs of the honest parties in all sessions are fixed at the beginning. We do not require fairness.
Ideal Model. In the ideal world experiment, there is a trusted party for computing the desired twoparty functionality f. Let there be two parties \(P_{1}\) and \(P_{2}\) that are involved in multiple, say \(m=m(n)\), evaluations of f. Let \(\mathcal {S}\) denote the adversary. The ideal world execution (parametrized by \(\lambda \)) proceeds as follows.

I. Inputs: \(P_1\) and \(P_2\) obtain a vector of m inputs, denoted \(\vec {x}\) and \(\vec {y}\) respectively. The adversary is given auxiliary input z, and chooses a party to corrupt. Without loss of generality, we assume that the adversary corrupts \(P_2\). The adversary receives the input vector \(\vec {y}\) of the corrupted party.

II. Session Initiation: The adversary initiates a new session by sending a startsession message to the trusted party. The trusted party then sends \((\mathsf startsession ,i)\) to \(P_{1}\), where i is the index of the session.

III. Honest Parties Send Inputs to Trusted Party: Upon receiving the message \((\mathsf startsession ,i)\) from the trusted party, \(P_{1}\) sends \((i,x_{i})\) to the trusted party, where \(x_i\) denotes its input for session i.

IV. Adversary Sends Input to Trusted Party and Receives Output: At any point, the adversary may send a message \((i,\ell ,y'_{i,\ell })\) to the trusted party for any \(y'_{i,\ell }\) of its choice. It receives back \((i,\ell ,f(x_i,y'_{i,\ell }))\) where \(x_i\) is the input value that \(P_1\) previously sent to the trusted party for session i. For any i, the trusted party accepts at most \(\lambda \) tuples indexed by i from the adversary.

V. Adversary Instructs Trusted Party to Answer Honest Party: When the adversary sends a message of the type \((\mathsf output ,i,\ell )\) to the trusted party, the trusted party sends \((i,f(x_i,y'_{i,\ell }))\) to \(P_{1}\), where \(x_i\) and \(y'_{i,\ell }\) denote the respective inputs sent by \(P_1\) and adversary for session i.

VI. Outputs: The honest party \(P_{1}\) always outputs the values \(f(x_i,y'_{i,\ell })\) that it obtained from the trusted party. The adversary may output an arbitrary efficient function of its auxiliary input z, input vector \(\vec {y}\) and the outputs obtained from the trusted party.
The ideal execution of a function \(\mathcal {F}\) with security parameter \(n\), input vectors \(\vec {x}\), \(\vec {y}\) and auxiliary input z to \(\mathcal {S}\), denoted \(\mathsf {Ideal}_{\mathcal {F},\mathcal {S}}(n,\vec {x},\vec {y},z)\), is defined as the output pair of the honest party and \(\mathcal {S}\) from the above ideal execution.
Definition 2.1
( \(\lambda \) Ideal Query Simulator). Let \(\mathcal {S}\) be a nonuniform probabilistic (expected) ppt machine representing the idealmodel adversary. We say that \(\mathcal {S}\) is a \(\lambda \)ideal query simulator if it makes at most \(\lambda \) output queries per session in the above ideal experiment.
Real Model. Let \(\varPi \) be a twoparty protocol for computing \(\mathcal {F}\). Let \(\mathcal {A}\) denote a nonuniform probabilistic polynomialtime adversary that controls either \(P_1\) or \(P_2\). The parties run concurrent executions of the protocol \(\varPi \), where the honest party follows the instructions of \(\varPi \) in each execution i using input \(x_i\). The scheduling of all messages is controlled by the adversary. At the conclusion of the protocol, an honest party computes its output as prescribed by the protocol. Without loss of generality, we assume the adversary outputs exactly its entire view of the execution of the protocol.
The real concurrent execution of \(\varPi \) with security parameter \(n\), input vectors \(\vec {x}\), \(\vec {y}\) and auxiliary input z to \(\mathcal {A}\), denoted \(\mathsf {Real}_{\varPi ,\mathcal {A}}(n,\vec {x},\vec {y},z)\), is defined as the output pair of the honest party and \(\mathcal {A}\), resulting from the above realworld process.
Definition 2.2
3 Framework for Concurrent Extraction

Stage 1: First, \(P_{1}\) and \(P_{2}\) interact in the commit phase of an execution of an extractable commitment scheme \(\langle C,R\rangle \) (described below) where \(P_{2}\) acts as the committer, committing to a random string, and, \(P_{1}\) acts as the receiver.

Stage 2: At the end of the commitment protocol, \(P_{1}\) sends a special message \(\mathsf {msg}\) to \(P_{2}\).

Extraction in all Sessions: \(\mathcal {S}\) must successfully extract the value committed by adversarial \(P_{2}^*\) in each execution of \(\varPi \).

Minimize the Query Parameter: Let \(\lambda \) denote the upper bound on the number of times the special message \(\mathsf {msg}_{s}\) of any session s appears in the entire simulation transcript. We refer to \(\lambda \) as the query parameter. Then, the goal of \(\mathcal {S}\) is to minimize the query parameter.
In the next subsection, we describe the extractable commitment scheme \(\langle C,R\rangle \) from [30]. Later, in Sects. 4 and 5, we analyze the “lazyKP” rewinding strategy [23, 29, 30] and the “sparse” rewinding strategy of Goyal, Gupta and Jain (GGJ) [19].
3.1 Extractable Commitment Protocol \(\langle C,R\rangle \)
Let \(\textsc {com}(\cdot )\) denote the commitment function of a noninteractive perfectly binding string commitment scheme. Let \(\ell = \omega (\log n)\). Let \(N= N(n)\) which will be determined later depending on the extraction strategy. The commitment scheme \(\langle C,R\rangle \) between the committer C and the receiver R is described as follows.
Commit Phase: This consists of two stages, namely, the Init stage and the ChallengeResponse stage, described below:
Open image in new window To commit to a \(n\)bit string \(\sigma \), C chooses \((\ell \cdot N)\) independent random pairs of \(n\)bit strings \(\{\alpha ^0_{i,j}, \alpha ^1_{i,j}\}_{i,j=1}^{\ell ,N}\) such that \({\alpha }^0_{i,j}\oplus {\alpha }^1_{i,j}=\sigma \) for all \(i\in [\ell ],j\in [N]\). C commits to all these strings using \(\textsc {com}\), with fresh randomness each time. Let \(B\leftarrow \textsc {com}(\sigma )\), and \(A^{0}_{i,j}\leftarrow \textsc {com}(\alpha ^{0}_{i,j})\), \(A^{1}_{i,j}\leftarrow \textsc {com}(\alpha ^{1}_{i,j})\) for every \(i \in [\ell ],j\in [N]\).

Challenge: R sends a random \(\ell \)bit challenge string \(v_j=v_{1,j},\ldots ,v_{\ell ,j}\).

Response: \(\forall i\in [\ell ]\), if \(v_{i,j}=0\), C opens \(A^{0}_{i,j}\), else it opens \(A^{1}_{i,j}\) by sending the decommitment information.
Notation. We introduce some terminology that will be used in the remainder of this paper. We refer to the committed value \(\sigma \) as the preamble secret. A \(\mathsf {slot}_i\) of the commitment scheme consists of the i’th \(\mathsf {Challenge}\) message from R and the corresponding \(\mathsf {Response}\) message from C. Thus, in the above protocol, there are \(N\) slots.
4 LazyKP Extraction Strategy
In this section, we discuss the “lazyKP” rewinding strategy [23, 29, 30] with a “splitting factor” of \(n\). We note that the idea of using a large splitting factor was first used in [27].
For this strategy, we will first prove that \(\lambda = \mathcal {O}(1)\) for static adversarial schedules. Next, we will prove that for dynamic schedules, \(\lambda = \mathcal {O}(\log n)\). In both of these results, the constants in \(\mathcal {O}\) depend on number of sessions started by the concurrent adversary.
LazyKP Simulator. The rewinding strategy of the lazyKP simulator is specified by the \(\text {Lazy}\text {}\textsc {KP}\text {}\textsc {Simulate}\) procedure. Very roughly, the simulator divides the current thread (given as input) into n equal parts and then rewinds each part individually and recursively. The input to the \(\text {Lazy}\text {}\textsc {KP}\text {}\textsc {Simulate}\) procedure consists of a triplet \((\ell ,\mathsf {hist},\mathcal {T})\). The parameter \(\ell \) denotes the adversary’s messages to be explored, the string \(\mathsf {hist}\) is a transcript of the current thread of execution, and \(\mathcal {T}\) is a table containing the contents of all the adversary’s messages explored so far (to extract the preamble secrets and for sending the Stage 2 special message in protocol \(\varPi \) in any session).
For every session s consisting of an execution of \(\varPi \), the goal of the simulator is to find two instances of any slot \(i\in [N]\) of the commitment protocol \(\langle C,R\rangle \) where the simulator’s challenges are different and adversary responds with a valid response to each challenge. Note that in this case, the simulator can extract the preamble secret of \(\langle C,R\rangle \) from the two responses of the adversary. On the other hand, if the simulation reaches Stage 2 in \(\varPi \) at any time, without having extracted the preamble secret from the adversary, then it gives up the simulation and outputs \(\bot \). In this case, we say the simulator gets stuck.
It follows from [29] that the lazyKP simulator (as described above) gets stuck with only negligible probability.
4.1 Terminology for Concurrent Simulation
We introduce some terminology and definitions regarding concurrent simulation that will be used in the rest of the paper.
Execution Thread. Consider any adversary that starts \(m=\mathsf {poly}(n)\) number of concurrent sessions of \(\varPi \). In order to extract the preamble secret in every session, the simulator creates multiple execution threads, where a thread of execution is a simulation of (part of) the protocol messages in the \(m\) sessions. We differentiate between the following:
Main Thread vs Lookahead Thread: The main thread is a simulation of a complete execution of the \(m\) sessions, and this is the execution thread that is output by the simulator. In addition, from any execution thread, the simulator may create other threads by rewinding the adversary to a previous state and continuing the execution from that state. Such a thread is called a lookahead thread. Note that a lookahead thread can be created from another lookahead thread.
Complete vs Partial Thread: We say that an execution thread T is a complete thread if it shares a prefix with the main thread: it starts where the main thread starts, and, continues until it is terminated by the simulator. Other threads that start from intermediary points of the simulation are called partial threads. Note that by definition, the main thread is a complete thread. In general, a complete thread may consist of various partial threads. Various complete threads may overlap with each other. For simplicity of exposition, unless necessary, we will not distinguish between complete and partial threads in the sequel.
Simulation Transcript. The simulation transcript is the set of all the messages between the simulator and the adversary during the simulation of all the concurrent sessions. In particular, this includes the messages that appear on the main thread as well as all the lookahead threads.
Simulation Index. Consider \(m=\mathsf {poly}(n)\) concurrent executions of \(\varPi \). Let \(M = m(2N+2)\), where \(2N+2\) is the round complexity of \(\varPi \). Then, a simulation index i denotes the point where the i’th message (out of a maximum of M messages) is sent on any complete execution thread in the simulation transcript.
Note that a simulation index i may appear multiple times over various threads in the simulation transcript. However, a simulation index i can appear at most once on any given thread (complete or partial). In particular, every simulation index \(i\in [M]\) appears on the main thread (unless the main thread is aborted prematurely). Further, if a lookahead thread T was created from a thread at simulation index i, then only simulation indices \(j>i\) can appear on T.
Static vs Dynamic Scheduling. Consider the concurrent execution of \(m=\mathsf {poly}(n)\) instances of \(\varPi \). Recall that the adversary controls the scheduling of the protocol messages across the \(m\) sessions. We say that a concurrent schedule is static if the scheduling of the protocol messages is decided by the adversary ahead of time and does not change upon rewindings. Thus, in a static schedule, protocol messages appear in the same order on every complete thread. In particular, for every \(i\in [M]\), every instance of a simulation index i in the simulation transcript corresponds to the same message index \(j\in [2N+2]\) of the same session s (out of the \(m\) sessions). However note that the actual content of the j’th message may differ on every execution thread.
We say that a concurrent schedule is dynamic if at any point during the execution, the adversary may decide which message to schedule next based on the protocol messages received so far. Therefore, in a dynamic schedule, the ordering of messages may be different on different execution threads in the simulation. In particular, each instance of a simulation index i may correspond to a different message \(j_i\) of a different session \(s_i\).
Recursion Levels. We define recursion levels of simulation and count the number of threads at each recursion level for the lazyKP simulator. We say that the main thread is at recursion level 0. Note that the \(\text {Lazy}\text {}\textsc {KP}\text {}\textsc {Simulate}\) divides the main thread of execution into \(n\) parts and executes each part twice. This results in \(2n\) execution threads, \(n\) of which are part of the main thread, while the remaining \(n\) are lookahead threads. All of these \(2n\) threads are said to be at recursion level 1. Now, each of these threads at recursion level 1 is divided into \(n\) parts and each part is executed twice. This creates \(2n\) threads at recursion level 2. Since there are \(2n\) threads at recursion level 1, in total, we have \((2n)^2\) threads at recursion level 2. (Again, out of these \((2n)^2\) threads, \(2n^2\) threads actually lie on the \(2n\) threads at level 1.) This process is continued recursively. At recursion level \(\ell \), there are \((2n)^\ell \) threads. Since there are \(m(2N+2)\) messages across the \(m\) sessions, the depth of recursion is a constant \(c'\), where \(c'=c+\log (2N+2)\) when \(m=n^c\). Then, at recursion level \(c'\), there are \((2n)^{c'}\) threads.
4.2 Analysis of \(\lambda \) for Static Schedules
We start by analyzing the lazyKP extraction strategy for static schedules. Let \(\lambda _{\mathsf {lazy}\text {}\mathsf {KP}}\) denote the query parameter for the lazyKP simulator.
Theorem 4.1
For any constant c and any concurrent execution of \(m=n^c\) instances of \(\varPi \) where the scheduling of messages is static, \(\lambda _{\mathsf {lazy}\text {}\mathsf {KP}} = 2^{c'}\), where \(c'=c+\log (2N+2)\).
In order to prove Theorem 4.1, we use the following lemma that follows by a simple counting argument (the proof is deferred to the full version).
Lemma 4.2
For any constant c and any concurrent execution of \(m=n^c\) instances of \(\varPi \), the simulation transcript generated by the lazyKP simulator is such that every simulation index \(i\in [M]\) appears \(2^{c'}\) times, where \(c'=c+\log (2N+2)\).
Consider any session s. From the definition of static scheduling, we have that for every \(j\in [2N+2]\), if the j’th message of session s appears at simulation index i on any thread, then every instance of simulation index i in the simulation transcript corresponds to the j’th message of session s. Now, from Lemma 4.2, since each simulation index appears \(2^{c'}\) times in the simulation transcript, we have that the special message of every session s appears \(2^{c'}\) times in the simulation. Thus, we have that \(\lambda _{\mathsf {lazy}\text {}\mathsf {KP}} = 2^{c'}\) for static schedules.
4.3 Analysis of \(\lambda \) for Dynamic Schedules
Theorem 4.3
For any polynomial \(m=\mathsf {poly}(n)\), for any concurrent execution of \(m\) instances of \(\varPi \) (with possibly dynamic scheduling of messages), \(\lambda _{\mathsf {lazy}\text {}\mathsf {KP}} = \mathcal {O}(\log n)\) except with negligible probability.
 1.
The number of times \(\mathsf {msg}_s\) appears in the simulation transcript before \(i_{\mathsf {main}}\). Let \(\delta _1\) denote this number.
 2.
The number of times \(\mathsf {msg}_s\) appears in the simulation transcript at \(i_{\mathsf {main}}\) or after \(i_{\mathsf {main}}\). Let \(\delta _2\) denote this number.
Thus, the total number of times \(\mathsf {msg}_s\) appears in the simulation transcript is \(\delta _1+\delta _2\). It suffices to prove that \(\delta _1+\delta _2=\mathcal {O}(\log n)\).
Let \(i_1,\ldots ,i_{k}\) be the distinct simulation indices where \(\mathsf {msg}_s\) appears in the simulation transcript. Let \(i_1,\ldots ,i_k\) be ordered, i.e., for every \(\ell \in [k1]\), \(i_{\ell }<i_{\ell +1}\). Let \(k_1\le k\) be such that \(i_{k_1}<i_{\mathsf {main}}\) and \(i_{k_1+1}\ge i_{\mathsf {main}}\).
Lemma 4.4
For any \(\ell \in [k]\), the probability that \(\mathsf {msg}_s\) does not appear on the main thread at simulation index \(i_{\ell }\) is at most \((1\frac{1}{c'})\).
Proof
Now, we first observe that \(\mathsf {msg}_s\) cannot appear on a lookahead thread that starts at a simulation index \(i>i_{\mathsf {main}}\). Thus, to compute \(\delta _2\), we only need to consider the lookahead threads that started at simulation indices \(i<i_{\mathsf {main}}\) and did not finish before reaching \(i_{\mathsf {main}}\). Let \(T_{\mathsf {good}}\) denote the set of such threads.
By using Lemma 4.2, we can claim that \(T_{\mathsf {good}} \le 2^{c'}\). Then, assuming the worst case where \(\mathsf {msg}_s\) appears on each thread \(T\in T_{\mathsf {good}}\), we have that \(\delta _2 \le 2^{c'}\)
5 GGJ Extraction Strategy
In this section, we discuss the GGJ extraction strategy [19] and analyze the query complexity parameter for the same. Unlike [19] that used a splitting factor of 2, we will work with \(n\) as the splitting factor. For this strategy, we will prove that for every concurrent schedule of polynomial number of sessions, the query parameter \(\lambda = \mathcal {O}(1)\). Here, the constant in \(\mathcal {O}\) depends on the number of concurrent sessions.
Overview. Roughly speaking, the GGJ rewinding strategy can be viewed as a “stripped down” version of the lazyKP simulation strategy. In particular, unlike lazyKP that executes every thread at every recursion level, here we only execute a small fraction of them. The actual threads that are to be executed are chosen uniformly at random, at every level. It is shown in GGJ that by slightly increasing the round complexity – (roughly) \(N = n^2\) from \(N = n\), executing a \(\frac{\mathsf {polylog}n}{N}\) fraction of threads at every level is sufficient to extract the preamble secret in every session.
 1.
We first describe an algorithm \(\mathsf {Sparsify}\) that essentially selects which threads to execute in the lazyKP recursion tree (Sect. 5.1).
 2.
Next, we describe the actual GGJ simulation procedure \(\textsc {GGJ}\text {}\textsc {Simulate}\) that is essentially the same as the \(\text {Lazy}\text {}\textsc {KP}\text {}\textsc {Simulate}\) strategy, except that it only executes the threads selected by \(\mathsf {Sparsify}\) (Sect. 5.2).
5.1 The Sparsification Procedure
We first describe the lazyKP simulation tree and give a coloring scheme for the same. Next, we describe the \(\mathsf {Sparsify}\) algorithm that takes the lazyKP simulation tree as input and outputs a “trimmed” version of it that will correspond to the GGJ simulation tree.

The root node is colored white.

Consider the \(2n\) child nodes of any parent node. The odd numbered nodes are colored white and the even numbered nodes are colored black.
Let us explain our coloring strategy. The root node (which is colored white) corresponds to the main thread of execution. Each black colored node \(\mathsf {Node}\) corresponds to a lookahead thread that was forked from the thread corresponding to node \(\mathsf {Parent}(\mathsf {Node})\). A white colored node \(\mathsf {Node}\) (except the root node) corresponds to a thread \(T'\) that is a part of the thread T corresponding to node \(\mathsf {Parent}(\mathsf {Node})\).
Node Labeling. To facilitate the description of the GGJ simulation strategy, we first describe a simple tree node labeling strategy for \(\mathsf {Tree}_{\mathsf {lazy}\text {}\mathsf {KP}}\). The root node is labeled 1. The i’th child (out of \(2n\) children) of the root node is labeled (1, i). More generally, consider a node \(\mathsf {Node}\) at level \(\ell \in [c']\). Let path be its label. Then the i’th child of Node is labeled (path, i).
Below, whenever necessary, we shall refer to the nodes by their associated labels.
The Sparsify Procedure. Let p be such that \(\frac{1}{p} = \frac{\mathsf {polylog}(n)}{N}\). The \(\mathsf {Sparsify}\) function transforms the lazyKP simulation tree \(\mathsf {Tree}_{\mathsf {lazy}\text {}\mathsf {KP}}\) into a “sparse” tree \(\mathsf {Tree}_{\mathsf {sp}}\) in the following manner.
 1.
Choose \(\frac{1}{p}\) fraction of the total black nodes at level \(\ell \), uniformly at random. Let \(B_{\ell }\) denote the set of these nodes.
 2.
Delete from \(\mathsf {Tree}_{\mathsf {lazy}\text {}\mathsf {KP}}\), every black node \(\mathsf {Node}\) at level \(\ell \) that is not present in set \(B_{\ell }\). Further, delete the entire subtree of \(\mathsf {Node}\) from \(\mathsf {Tree}_{\mathsf {lazy}\text {}\mathsf {KP}}\).
The resultant tree is denoted as \(\mathsf {Tree}_{\mathsf {sp}}\). Looking ahead, we will describe the GGJ rewinding strategy as essentially a modification of \(\text {Lazy}\text {}\textsc {KP}\text {}\textsc {Simulate}\) in that it only executes the threads corresponding to the nodes in \(\mathsf {Tree}_{\mathsf {sp}}\).
5.2 The \(\textsc {GGJ}\text {}\textsc {Simulate}\) Procedure
The rewinding strategy of the GGJ simulator is specified by the \(\textsc {GGJ}\text {}\textsc {Simulate}\) procedure. The input to the \(\textsc {GGJ}\text {}\textsc {Simulate}\) procedure is a tuple (path, \(\ell ,\mathsf {hist},\mathcal {T}\)). The parameter path denotes the label of the node in \(\mathsf {Tree}_{\mathsf {sp}}\) that is to be explored, \(\ell \) denotes the number of adversary’s messages to be explored (on the thread corresponding to the node labeled with path), the string \(\mathsf {hist}\) is a transcript of the current thread of execution, \(\mathcal {T}\) is a table containing the contents of all the adversary’s messages explored so far (to extract the preamble secrets and for sending the Stage 2 special message in \(\varPi \) in any session).
It is implicit in [19] that the GGJ simulator (as described above) gets stuck with only negligible probability when \(N = \mathcal {O}(n^2)\). We now analyze the query parameter \(\lambda _{\mathsf {GGJ}}\) for the GGJ simulation strategy. A formal proof is deferred to the full version.
Theorem 5.1
For every constant c, every \(m= n^c\) number of concurrent executions of \(\varPi \), the query parameter \(\lambda _{\mathsf {GGJ}} = \mathcal {O}(1)\), where the constant depends on c.
Proof
(Sketch). Fix any session s. We will show that the special message \(\mathsf {msg}_s\) can appear at most \(\mathcal {O}(1)\) times at each recursion level \(\mathsf {RL}_{\ell }\). Then, since there are only a constant number of recursion levels, it will follow that \(\lambda _{\mathsf {GGJ}} = \mathcal {O}(1)\).
Towards that end, lets fix a recursion level \(\ell \). First recall from Theorem 4.3 that for the lazyKP simulation strategy, \(\lambda _{\mathsf {lazy}\text {}\mathsf {KP}} = \mathcal {O}(\log n)\). In particular, this implies that at every recursion level \(\ell \) in the lazyKP simulation, \(\mathsf {msg}_s\) for a session s appears on at most \(\mathcal {O}(\log n)\) threads. Using the tree terminology as introduced earlier, we have that \(\mathsf {msg}_s\) appears on (the threads corresponding to) at most \(\mathcal {O}(\log n)\) black nodes at level \(\ell \) in \(\mathsf {Tree}_{\mathsf {lazy}\text {}\mathsf {KP}}\). Now, recall that at every level \(\ell \), the \(\mathsf {Sparsify}\) procedure selects only \(\frac{1}{p} = \frac{\mathsf {polylog}n}{N}\) fraction of black nodes, uniformly at random, and deletes the rest of the black nodes. Using Chernoff bound, we can then show that the probability that Sparsify selects \(\omega (1)\) black nodes containing \(\mathsf {msg}_s\) is negligible.
6 From Concurrent Extraction to Concurrent Secure Computation
Theorem 6.1
Assuming 1outof2 oblivious transfer, for any efficiently computable functionality f there exists a protocol \(\varPi \) that \(\mathcal {O}(1)\)securely realizes f in the MIQ model.
We construct such a protocol by following the exact recipe of [19, 21]. We note that the works of [19, 21] show how to compile a semihonest secure computation protocol \(\varPi _\mathsf{sh}\) for any functionality f into a new protocol \(\varPi \) that securely realizes f in the MIQ model. The core ingredient of their compiler is a concurrently extractable commitment \(\langle C,R\rangle \): if there exists a concurrent simulator for \(\langle C,R\rangle \) with query parameter \(\lambda \), then the resultant (compiled) protocol \(\varPi \) \(\lambda \)securely realizes f.
In order to prove Theorem 6.1, we construct such a protocol \(\varPi \) by simply plugging in our \(O(n^2)\)round extractable commitment scheme in the construction of [19, 21]. Then, it follows from Theorem 5.1 that protocol \(\varPi \) \(\mathcal {O}(1)\)securely realizes f in the MIQ model, where the constant in \(\mathcal {O}\) depends on c, where \(n^c\) is the number of sessions opened by the concurrent adversary.
Fully Concurrent PAKE in the Plain Model. Consider the PAKE functionality: it takes a password as input from each party, and, if they match, outputs a randomly generated key to both of them. The above protocol, when executed for the PAKE functionality gives a PAKE construction in the MIQ model where the simulator makes a constant number of queries per session in the ideal world. We then plug in Lemma 7 in [21] which shows that a PAKE construction in the MIQ model for a constant number of queries implies a concurrent PAKE as per the definition of Goldreich and Lindell [16] (with the modification that the constant in big O is adversary dependent). Put together, this gives us a construction of concurrent passwordauthenticated key exchange in the plain model.
Footnotes
 1.
More concretely, we wish to bound the first message in the protocol where the simulator is forced to query the trusted party in order to obtain the function output.
 2.
Note that the output message of a session may appear more than once in the simulation transcript if the simulator employs rewinding.
References
 1.Agrawal, S., Goyal, V., Jain, A., Prabhakaran, M., Sahai, A.: New impossibility results on concurrently secure computation and a noninteractive completeness theorem for secure computation. In: CRYPTO (2012)Google Scholar
 2.Barak, B., Canetti, R., Nielsen, J., Pass, R.: Universally composable protocols with relaxed setup assumptions. In: FOCS (2004)Google Scholar
 3.Barak, B., Prabhakaran, M., Sahai, A.: Concurrent nonmalleable zero knowledge. In: FOCS (2006)Google Scholar
 4.Barak, B., Sahai, A.: How to play almost any mental game over the net  concurrent composition using superpolynomial simulation. In: Proc. \(46\)th FOCS (2005)Google Scholar
 5.Canetti, R., Lindell, Y., Ostrovsky, R., Sahai, A.: Universally composable twoparty and multiparty secure computation. In: STOC (2002)Google Scholar
 6.Canetti, R., Fischlin, M.: Universally composable commitments. In: Kilian, J. (ed.) CRYPTO 2001. LNCS, vol. 2139, p. 19. Springer, Heidelberg (2001) CrossRefGoogle Scholar
 7.Canetti, R., Kilian, J., Petrank, E., Rosen, A.: Blackbox concurrent zeroknowledge requires \(\stackrel{\sim }{\Omega }(\log n)\) rounds. In: STOC, pp. 570–579 (2001)Google Scholar
 8.Canetti, R., Kushilevitz, E., Lindell, Y.: On the limitations of universally composable twoparty computation without setup assumptions. In: Eurocrypt (2003)Google Scholar
 9.Canetti, R., Lin, H., Pass, R.: Adaptive hardness and composable security in the plain model from standard assumptions. In: FOCS (2010)Google Scholar
 10.Dolev, D., Dwork, C., Naor, M.: Nonmalleable cryptography. SIAM J. Comput. 30(2), 391–437 (electronic) (2000), preliminary version in STOC 1991Google Scholar
 11.Dwork, C., Naor, M., Sahai, A.: Concurrent zeroknowledge. In: STOC, pp. 409–418 (1998)Google Scholar
 12.Garg, S., Goyal, V., Jain, A., Sahai, A.: Concurrently secure computation in constant rounds. In: Pointcheval, D., Johansson, T. (eds.) EUROCRYPT 2012. LNCS, vol. 7237, pp. 99–116. Springer, Heidelberg (2012) CrossRefGoogle Scholar
 13.Garg, S., Kumarasubramanian, A., Ostrovsky, R., Visconti, I.: Impossibility results for static input secure computation. In: SafaviNaini, R., Canetti, R. (eds.) CRYPTO 2012. LNCS, vol. 7417, pp. 424–442. Springer, Heidelberg (2012) CrossRefGoogle Scholar
 14.Goldreich, O., Micali, S., Wigderson, A.: How to play any mental game. In: STOC (1987)Google Scholar
 15.Goldreich, O., Krawczyk, H.: On the composition of zeroknowledge proof systems. SIAM J. Comput. 25(1), 169–192 Feburary 1996. http://epubs.siam.org/sambin/dbq/article/22068, preliminary version appeared in ICALP1990
 16.Goldreich, O., Lindell, Y.: Sessionkey generation using human passwords only. In: Kilian, J. (ed.) CRYPTO 2001. LNCS, vol. 2139, p. 408. Springer, Heidelberg (2001) CrossRefGoogle Scholar
 17.Goldreich, O., Lindell, Y.: Sessionkey generation using human passwords only. J. Cryptology 19(3), 241–340 (2006)MathSciNetCrossRefzbMATHGoogle Scholar
 18.Goyal, V.: Positive results for concurrently secure computation in the plain model. In: FOCS (2012)Google Scholar
 19.Goyal, V., Gupta, D., Jain, A.: What information is leaked under concurrent composition? In: Canetti, R., Garay, J.A. (eds.) CRYPTO 2013, Part II. LNCS, vol. 8043, pp. 220–238. Springer, Heidelberg (2013) CrossRefGoogle Scholar
 20.Goyal, V., Jain, A.: On concurrently secure computation in the multiple ideal query model. In: Johansson, T., Nguyen, P.Q. (eds.) EUROCRYPT 2013. LNCS, vol. 7881, pp. 684–701. Springer, Heidelberg (2013) CrossRefGoogle Scholar
 21.Goyal, V., Jain, A., Ostrovsky, R.: Passwordauthenticated sessionkey generation on the internet in the plain model. In: Rabin, T. (ed.) CRYPTO 2010. LNCS, vol. 6223, pp. 277–294. Springer, Heidelberg (2010) CrossRefGoogle Scholar
 22.Katz, J.: Universally composable multiparty computation using tamperproof hardware. In: Naor, M. (ed.) EUROCRYPT 2007. LNCS, vol. 4515, pp. 115–128. Springer, Heidelberg (2007) CrossRefGoogle Scholar
 23.Kilian, J., Petrank, E.: Concurrent and resettable zeroknowledge in polyloalgorithm rounds. In: STOC (2001)Google Scholar
 24.Lindell, Y.: Boundedconcurrent secure twoparty computation without setup assumptions. In: STOC, pp. 683–692. ACM (2003)Google Scholar
 25.Micali, S., Pass, R.: Local zero knowledge. In: STOC (2006)Google Scholar
 26.Micali, S., Pass, R., Rosen, A.: Inputindistinguishable computation. In: FOCS (2006)Google Scholar
 27.Pandey, O., Pass, R., Sahai, A., Tseng, W.L.D., Venkitasubramaniam, M.: Precise concurrent zero knowledge. In: Smart, N.P. (ed.) EUROCRYPT 2008. LNCS, vol. 4965, pp. 397–414. Springer, Heidelberg (2008) CrossRefGoogle Scholar
 28.Pass, R.: Simulation in quasipolynomial time, and its application to protocol composition. In: Eurocrypt (2003)Google Scholar
 29.Pass, R., Tseng, W.L.D., Venkitasubramaniam, M.: Concurrent zero knowledge, revisited. J. Cryptology 27(1), 45–66 (2014)CrossRefzbMATHGoogle Scholar
 30.Prabhakaran, M., Rosen, A., Sahai, A.: Concurrent zero knowledge with logarithmic roundcomplexity. In: FOCS (2002)Google Scholar
 31.Prabhakaran, M., Sahai, A.: New notions of security: achieving universal composability without trusted setup. In: STOC (2004)Google Scholar
 32.Richardson, R., Kilian, J.: On the concurrent composition of zeroknowledge proofs. In: Stern, J. (ed.) EUROCRYPT 1999. LNCS, vol. 1592, p. 415. Springer, Heidelberg (1999) CrossRefGoogle Scholar
 33.Yao, A.C.C.: How to generate and exchange secrets. In: FOCS (1986)Google Scholar