Concurrent Secure Computation with Optimal Query Complexity

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 self-composition, where the degradation is measured by the number of ideal queries. However, to date, all known MIQ-secure 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 adversary-independent constant number of ideal queries per session.

We show the first MIQ-secure protocol with worst-case per-session 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 set-up assumptions.

R. Canetti — Supported by the Check Point Institute for Information Security, ISF grant 1523/14, and NSF Frontier CNS 1413920 and 1218461 grants.

A. Jain — Work done in part while visiting Microsoft Research, India, and at Boston University and MIT, where the author was supported in part by NSF 1218461 and DARPA FA8750-11-2-0225. Presently supported in part by a DARPA Safeware grant.

1 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, far-reaching 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 set-up, 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 tamper-proof 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. super-polynomial time simulation [4, 9, 12, 28, 31] and input-indistinguishable 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 fine-tuned notions of security for a given problem or setting.

One functionality where this approach proved very effective is that of password-based key exchange (namely the two-party 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 password-based 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 1-out-of-m 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. Password-based 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 average-case 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 two-party 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 worst-case 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 worst-case 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 worst-case 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 worst-case 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 password-based 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 (worst-case) 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 average-case bound on the simulator query complexity.

In this work, we are interested in minimizing the worst-case 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.¹ 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.² 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. Lazy-KP with Static Scheduling: We first consider the warm-up 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) “lazy-KP” 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 lazy-KP simulation with splitting factor n.

Step 2. Lazy-KP 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 lazy-KP 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 look-ahead 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 Lazy-KP 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 lazy-KP simulator with splitting factor n. Very roughly, [19] pick a subset of the total threads resulting out of the lazy-KP 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 look-ahead 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 lazy-KP 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 two-party 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 start-session message to the trusted party. The trusted party then sends $(\mathsf start-session ,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 start-session ,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 non-uniform probabilistic (expected) ppt machine representing the ideal-model 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 two-party protocol for computing $\mathcal {F}$. Let $\mathcal {A}$ denote a non-uniform probabilistic polynomial-time 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 real-world process.

Definition 2.2

( $\lambda$ -Secure Concurrent Computation in the MIQ Model). A protocol $\varPi$ is said to $\lambda$-securely realize a functionality $\mathcal {F}$ under concurrent self composition in the MIQ model if for every real model non-uniform ppt adversary $\mathcal {A}$, there exists a non-uniform (expected) ppt $\lambda$-ideal query simulator $\mathcal {S}$ such that for all polynomials $m=m(n)$, every pair of input vectors $\vec {x}\in X^m$, $\vec {y}\in Y^m$, every $z\in \{0,1\}^{*}$,

$$\left\{ \mathsf {Ideal}_{\mathcal {F},\mathcal {S}}(n,\vec {x},\vec {y},z)\right\} _{n\in \mathbb {N}} \mathop {\equiv }\limits ^{c} \left\{ \mathsf {Real}_{\varPi ,\mathcal {A}}(n,\vec {x},\vec {y},z)\right\} _{n\in \mathbb {N}}$$

3 Framework for Concurrent Extraction

The Setting. Consider the following two-party computation protocol $\varPi = (P_{1},P_{2})$:

• 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}$.

Now, consider the scenario where $P_{1}$ and $P_{2}$ are interacting in multiple concurrent executions of $\varPi$. Suppose that $P_{2}$ is corrupted. Our goal is to design a simulator algorithm $\mathcal {S}$ that satisfies the following two properties:

• 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 “lazy-KP” 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 non-interactive 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 Challenge-Response stage, described below:

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]$.

For every $j\in [N]$, do the following:

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

Open Phase: C opens all the commitments by sending the decommitment information for each one of them. R verifies the consistency of the revealed values. This completes the description of $\langle C,R\rangle$.

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 Lazy-KP Extraction Strategy

In this section, we discuss the “lazy-KP” 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.

Lazy-KP Simulator. The rewinding strategy of the lazy-KP 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).

The simulation is performed by invoking the procedure $\text {Lazy}\text {-}\textsc {KP}\text {-}\textsc {Simulate}$ with appropriate parameters. Let $m= \mathsf {poly}(n)$ denote the number of concurrent sessions in the adversarial schedule. Then, the $\text {Lazy}\text {-}\textsc {KP}\text {-}\textsc {Simulate}$ procedure is invoked with input $\left( m\left( N+1\right) ,\emptyset ,\emptyset \right)$, where $m(N+1)$ is the total number of adversary’s messages in a schedule of $m$ sessions. The $\text {Lazy}\text {-}\textsc {KP}\text {-}\textsc {Simulate}$ procedure is described in Fig. 1. Note that here (similar to [27]) we divide each thread into $n$ parts. In other words, we consider a splitting factor of $n$.

Fig. 1.

Lazy-KP Simulator with splitting factor $n$. Even though the messages in $\{\widetilde{\mathsf {hist}}_{i,2}\}$ do not appear in the output, some of them do appear in $\widetilde{\mathcal {T}}$.

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 lazy-KP 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 Look-ahead 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 look-ahead thread. Note that a look-ahead thread can be created from another look-ahead 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 look-ahead 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 look-ahead 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 lazy-KP 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 look-ahead 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.

Sibling Threads. Consider Fig. 2 where a thread T at some recursion level $\ell$ is divided into $n= 4$ parts, which leads to the creation of 8 threads at recursion level $\ell +1$. Each pair of threads $(T_i,T'_i)$ that are started from the same point are referred to as sibling threads.

Fig. 2.

One recursion step for splitting factor 4. Every $T_i$ and $T'_i$ are sibling threads.

4.2 Analysis of $\lambda$ for Static Schedules

We start by analyzing the lazy-KP extraction strategy for static schedules. Let $\lambda _{\mathsf {lazy}\text {-}\mathsf {KP}}$ denote the query parameter for the lazy-KP 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 lazy-KP 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.

Proof of Theorem 4.3. Fix any session s out of the $m=n^{c}$ sessions. Note that the special message $\mathsf {msg}_s$ of session s appears exactly once on the main thread. Let $i_{\mathsf {main}}$ denote the simulation index where $\mathsf {msg}_s$ appears on the main thread. Now, we will count:

• 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 [k-1]$, $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

Consider the simulation index $i_1$. From Lemma 4.2, we have that $i_1$ appears on $2^{c'}$ threads in the simulation transcript. Let $T[i_1] = T_1,\ldots ,T_{2^{c'}}$ denote these threads. Now, let q be such that the special message $\mathsf {msg}_s$ appears at simulation index $i_1$ on q of these $2^{c'}$ threads. Let $T^*[i_1] = T^*_1,\ldots ,T^*_q$ denote these q threads. Let $T_{\mathsf {main}}$ denote the main thread. Then, we have that:

$$\begin{aligned} \Pr \left[ T_{\mathsf {main}}\in T^*\left[ i_1\right] \right] = \frac{q}{2^{c'}} \end{aligned}$$

(1)

To see this, recall that the $\text {Lazy}\text {-}\textsc {KP}\text {-}\textsc {Simulate}$ procedure uses uniformly random coins on each execution thread, and follows the same strategy. Thus, the view of the adversary is indistinguishable on each thread. In particular, if p is the probability that a message $\alpha$ appears on a thread T and $m'$ appears on its sibling thread $T'$ with, then with probability $p-\mathsf {negl}(n)$, $m'$ appears on T and m appears on $T'$. (This is the “symmetry” property for threads in the lazy-KP simulation.) Therefore, Eq. 1 follows.

From Eq. 1, we have that:

$$\begin{aligned} \Pr \left[ T_{\mathsf {main}}\notin T^*\left[ i_1\right] \right] = 1- \frac{q}{2^{c'}} \end{aligned}$$

Note that the above probability is maximum when $q=1$. Hence, we have that:

$$\begin{aligned} \Pr [\mathsf {msg}_s~\text {does not occur on main thread at}~ i_1] \le 1-\frac{1}{2^{c'}}. \end{aligned}$$

(2)

Now, consider simulation index $i_2$. Again, from Lemma 4.2, we have that $i_2$ appears on $2^{c'}$ threads. Let $T[i_2]$ denote the set of these threads. Now, note that $\mathsf {msg}_s$ cannot appear on the look-ahead threads $T\in T^*[i_1]\cap T[i_2]$. Thus, following Eq. 2, we have that:

$$\begin{aligned} \Pr [\mathsf {msg}_s ~\text {does not occur on main thread at}~ i_2] \le 1-\frac{1}{2^{c''}}. \end{aligned}$$

where $c''\le c'$. Continuing the same argument, we have that for every $\ell \in [k-1]$,

$$\begin{aligned} \Pr [\mathsf {msg}_s ~\mathrm{is~not~on~main~thread~at}~ i_{\ell +1}] \le \Pr [\mathsf {msg}_s ~\mathrm{is~not~on~main~thread~at}~ i_{\ell }] \end{aligned}$$

Thus, for every $i_{\ell }$, we have that the probability that $\mathsf {msg}_s$ does not occur on main thread at $i_{\ell }$ is at most $1-\frac{1}{c'}$.

Computing $\delta _1$. Now, note that $(1-\frac{1}{c'})^t = \mathsf {negl}(n)$ for $t=\omega (\log n)$. Therefore, we have that $k_1 = \mathcal {O}(\log n)$. Now, since each of the simulation indices $i_1,\ldots ,i_{k_1}$ appears $2^{c'}$ times in the simulation transcript, we have that:

$$\begin{aligned} \delta _1 \le 2^{c'}\mathcal {O}(\log n) \end{aligned}$$

(3)

Computing $\delta _2$. We now compute the value of $\gamma _2$. Towards this, let us suppose that for every simulation index $i\in [\ell ]$, the $\text {Lazy}\text {-}\textsc {KP}\text {-}\textsc {Simulate}$ procedure runs all threads starting from simulation index i in parallel. That is, $\text {Lazy}\text {-}\textsc {KP}\text {-}\textsc {Simulate}$ performs one step of execution on each of these threads. It then performs the next execution step on each of these threads, and so on. Note that this is without loss of generality since the $\text {Lazy}\text {-}\textsc {KP}\text {-}\textsc {Simulate}$ procedure runs all such threads independently.

Now, we first observe that $\mathsf {msg}_s$ cannot appear on a look-ahead thread that starts at a simulation index $i>i_{\mathsf {main}}$. Thus, to compute $\delta _2$, we only need to consider the look-ahead 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 lazy-KP simulation strategy. In particular, unlike lazy-KP 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.

We describe the GGJ rewinding strategy in two main steps:

• 1. We first describe an algorithm $\mathsf {Sparsify}$ that essentially selects which threads to execute in the lazy-KP 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 lazy-KP simulation tree and give a coloring scheme for the same. Next, we describe the $\mathsf {Sparsify}$ algorithm that takes the lazy-KP simulation tree as input and outputs a “trimmed” version of it that will correspond to the GGJ simulation tree.

Lazy-KP Simulation Tree. Let $m=n^{c}$ be the total number of concurrent sessions of $\varPi$ started by an adversary $\mathcal {A}$. Then, the $\text {Lazy}\text {-}\textsc {KP}\text {-}\textsc {Simulate}$ strategy for $\mathcal {A}$ can be described by a 2n-ary tree $\mathsf {Tree}_{\mathsf {lazy}\text {-}\mathsf {KP}}$ of constant depth $c'$ where $c' = c+\log (2N+2)$. The nodes in $\mathsf {Tree}_{\mathsf {lazy}\text {-}\mathsf {KP}}$ are colored white or black as per the following strategy:

• 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 look-ahead 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})$.

Figure 3 denotes the lazy-KP simulation tree for splitting factor $n= 2$ with white boxes representing white nodes and grey boxes representing black nodes.

Fig. 3.

The lazy-KP simulation tree for splitting factor 2.

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 lazy-KP simulation tree $\mathsf {Tree}_{\mathsf {lazy}\text {-}\mathsf {KP}}$ into a “sparse” tree $\mathsf {Tree}_{\mathsf {sp}}$ in the following manner.

Let the root node correspond to level 0 and the leaf nodes correspond to level $c'$. The Sparsify procedure starts at level 0 and traverses down $\mathsf {Tree}_{\mathsf {lazy}\text {-}\mathsf {KP}}$, stopping at level $c'$. It performs the following steps at every level $\ell \in [c']$:

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

The simulation is performed by invoking the procedure $\textsc {GGJ}\text {-}\textsc {Simulate}$ with appropriate parameters. Let $m= \mathsf {poly}(n)$ denote the number of concurrent sessions in the adversarial schedule. Then, the $\textsc {GGJ}\text {-}\textsc {Simulate}$ procedure is invoked with input $\left( 1,m\left( N+1\right) ,\emptyset ,\emptyset \right)$, where $m(N+1)$ is the total number of adversary’s messages in a schedule of $m$ sessions. The $\textsc {GGJ}\text {-}\textsc {Simulate}$ procedure is described in Fig. 4. Note that unlike [19], where each thread is recursively divided into two parts, here we divide each thread into $n$ parts. In other words, we consider a splitting factor of $n$.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.

Fig. 4.

GGJ Simulator with splitting factor $n$. Even though the messages in $\{\widetilde{\mathsf {hist}}_{i,2}\}$ do not appear in the output, some of them do appear in $\widetilde{\mathcal {T}}$.

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 lazy-KP simulation strategy, $\lambda _{\mathsf {lazy}\text {-}\mathsf {KP}} = \mathcal {O}(\log n)$. In particular, this implies that at every recursion level $\ell$ in the lazy-KP 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 1-out-of-2 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 semi-honest 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 password-authenticated key exchange in the plain model.