Implicit ZeroKnowledge Arguments and Applications to the Malicious Setting
 12 Citations
 2.4k Downloads
Abstract
We introduce implicit zeroknowledge arguments (\(\mathsf{iZK }\)) and simulationsound variants thereof (\(\mathsf{SSiZK }\)); these are lightweight alternatives to zeroknowledge arguments for enforcing semihonest behavior. Our main technical contribution is a construction of efficient twoflow \(\mathsf{iZK }\) and \(\mathsf{SSiZK }\) protocols for a large class of languages under the (plain) \(\mathsf{DDH }\) assumption in cyclic groups in the common reference string model. As an application of \(\mathsf{iZK }\), we improve upon the roundefficiency of existing protocols for securely computing inner product under the \(\mathsf{DDH }\) assumption. This new protocol in turn provides privacypreserving biometric authentication with lower latency.
Keywords
Hash proof systems Zeroknowledge Malicious adversaries Twoparty computation Inner product1 Introduction
ZeroKnowledge Arguments (ZK) enable a prover to prove the validity of a statement to a verifier without revealing anything else [13, 30]. In addition to being interesting in its own right, zero knowledge has found numerous applications in cryptography, most notably to simplify protocol design as in the setting of secure twoparty computation [28, 29, 46], and as a tool for building cryptographic primitives with strong security guarantees such as encryption secure against chosenciphertext attacks [19, 41].
In this work, we focus on the use of zeroknowledge arguments as used in efficient twoparty protocols for enforcing semihonest behavior. We are particularly interested in roundefficient twoparty protocols, as network latency and roundtrip times can be a major efficiency bottleneck, for instance, when a user wants to securely compute on data that is outsourced to the cloud. In addition, we want to rely on standard and widelydeployed cryptographic assumptions. Here, a standard interactive zeroknowledge argument based on the \(\mathsf{DDH }\) assumption would require at least three flows; moreover, this overhead in round complexity is incurred each time we want to enforce semihonest behavior via zero knowledge. To avoid this overhead, we could turn to noninteractive zeroknowledge proofs (\(\mathsf{NIZK }\)). However, efficient \(\mathsf{NIZK }\) would require either the use of pairings [32] and thus stronger assumptions and additional efficiency overhead, or the use of random oracles [6, 23].
We would like to point out that, contrary to some common belief, there is no straightforward way to reduce the number of rounds of zeroknowledge proofs “\(\grave{\mathrm{a}}\) la Schnorr” [42] by performing the first steps (commitment and challenges) in a preprocessing phase, so that each proof only takes one flow subsequently. Indeed, as noticed by BernhardPereiraWarinsky in [9], the statement of the proof has to be chosen before seeing the challenges, unless the proof becomes unsound.
On the Importance of RoundEfficiency. In addition to being an interesting theoretical problem, improving the round efficiency is also very important in practice. If we consider a protocol between a client in Europe, and a cloud provider in the US, for example, we expect a latency of at least 100ms (and even worse if the client is connected with 3 g or via satellite, which may induce a latency of up to 1s [14]). Concretely, using Curve25519 elliptic curve of Bernstein [10] (for 128 bits of security, and 256bit group elements) with a 10 Mbps Internet link and 100 ms latency, 100 ms corresponds to sending 1 flow, or 40,000 group elements, or computing 1,000 exponentiations at 2 GHz on one core of current AMD64 microprocessor^{1}, hence 4,000 exponentiations on a 4core microprocessor^{2}. As a final remark on latency, while speed of networks keeps increasing as technology improves, latency between two (far away) places on earth is strongly limited by the speed of light: there is no hope to get a latency less than 28 ms between London and San Francisco, for example.
Our Contributions. In this work, we introduce implicit ZeroKnowledge Arguments or \(\mathsf{iZK }\) and simulationsound variants thereof or \(\mathsf{SSiZK }\), lightweight alternatives to (simulationsound) zeroknowledge arguments for enforcing semihonest behavior in twoparty protocols. Then, we construct efficient twoflow \(\mathsf{iZK }\) and \(\mathsf{SSiZK }\) protocols for a large class of languages under the (plain) \(\mathsf{DDH }\) assumption in cyclic groups without random oracles; this is the main technical contribution of our work. Our \(\mathsf{SSiZK }\) construction from \(\mathsf{iZK }\) is very efficient and incurs only a small additive overhead. Finally, we present several applications of \(\mathsf{iZK }\) to the design of efficient secure twoparty computation, where \(\mathsf{iZK }\) can be used in place of interactive zeroknowledge arguments to obtain more roundefficient protocols.
While our \(\mathsf{iZK }\) protocols require an additional flow compared to \(\mathsf{NIZK }\), we note that eliminating the use of pairings and random oracles offers both theoretical and practical benefits. From a theoretical standpoint, the \(\mathsf{DDH }\) assumption in cyclic groups is a weaker assumption than the \(\mathsf{DDH }\)like assumptions used in GrothSahai pairingbased NIZK [32], and we also avoid the theoretical pitfalls associated with instantiating the random oracle methodology [5, 16]. From a practical standpoint, we can instantiate our \(\mathsf{DDH }\)based protocols over a larger class of groups. Concrete examples include Bernstein’s Curve25519 [10] which admit very efficient group exponentiations, but do not support an efficient pairing and are less likely to be susceptible to recent breakthroughs in discrete log attacks [4, 31]. By using more efficient groups and avoiding the use of pairing operations, we also gain notable improvements in computational efficiency over GrothSahai proofs. Moreover, additional efficiency improvements come from the structure of \(\mathsf{iZK }\) which makes them efficiently batchable. Conversely, GrothSahai \(\mathsf{NIZK }\) cannot be efficiently batched and do not admit efficient \(\mathsf{SS\hbox {}NIZK }\) (for nonlinear equations).
More precisely, \(\mathsf{iZK }\) are key encapsulation mechanisms in which the public key \(\mathsf {ipk}\) is associated with a word \(\mathsf {x}\) and a language \(\mathsf i \!\mathscr {L}\). In our case, \(\mathsf {x}\) is the flow^{3} and \(\mathsf i \!\mathscr {L}\) the language of valid flows. If \(\mathsf {x}\) is in \(\mathsf i \!\mathscr {L}\), knowing a witness proving so (namely, random coins used to generate the flow) enables anyone to generate \(\mathsf {ipk}\) together with a secret key \(\mathsf {isk}\), using a key generation algorithm \({\mathsf {iKG}}\). But, if \(\mathsf {x}\) is not in \(\mathsf i \!\mathscr {L}\), there is no polynomialtime way to generate a public key \(\mathsf {ipk}\) for which it is possible to decrypt the associated ciphertexts (soundness).
To ensure semihonest behavior, as depicted in Fig. 1, each time a player sends a flow \(\mathsf {x}\), he also sends a public key \(\mathsf {ipk}\) generated by \({\mathsf {iKG}}\) and keeps the associated secret key \(\mathsf {isk}\). To answer back, the other user generates a key encapsulation \(c\) for \(\mathsf {ipk}\) and \(\mathsf {x}\), of a random ephemeral key \(K\). He can then use \(K\) to encrypt (using symmetric encryption or pseudorandom generators and onetime pad) all the subsequent flows he sends to the first player. For this transformation to be secure, we also need to be sure that \(c\) (and the ability to decapsulate \(K\) for any \(\mathsf {ipk}\)) leaks no information about random coins used to generate the flow (or, more generally, the witness of \(\mathsf {x}\)). This is ensured by the zeroknowledge property, which states there must exist a trapdoor (for some common reference string) enabling to generate a public key \(\mathsf {ipk}\) and a trapdoor key \(\mathsf {itk}\) (using a trapdoor key algorithm \({\mathsf {iTKG}}\)), so that \(\mathsf {ipk}\) looks like a classical public key and \(\mathsf {itk}\) allows to decapsulate any ciphertext for \(\mathsf {ipk}\).
Overview of Our iZK and SSiZK Constructions. We proceed to provide an overview of our twoflow \(\mathsf{iZK }\) protocols; this is the main technical contribution of our work. Our main tool is Hash Proof Systems or Smooth Projective Hash Functions (\(\mathsf{SPHFs }\)) [18]. We observe that \(\mathsf{SPHFs }\) are essentially “honestverifier” \(\mathsf{iZK }\); our main technical challenge is to boost this weak honestverifier into fullfledged zero knowledge, without using pairings or random oracles.
Informally speaking, a smooth projective hash function on a language \(\mathscr {L}\) is a sort of hash function whose evaluation on a word \(C\in \mathscr {L}\) can be computed in two ways, either by using a hashing key \(\mathsf {hk} \) (which can be seen as a private key) or by using the associated projection key \(\mathsf {hp} \) (which can be seen as a public key). On the other hand, when \(C\notin \mathscr {L}\), the hash of C cannot be computed from \(\mathsf {hp} \); actually, when \(C\notin \mathscr {L}\), the hash of C computed with \(\mathsf {hk} \) is statistically indistinguishable from a random value from the point of view of any individual knowing the projection key \(\mathsf {hp} \) only. Hence, an \(\mathsf{SPHF }\) on \(\mathscr {L}\) is given by a pair \((\mathsf {Hash},\mathsf {ProjHash})\) with the requirements that, when there is a witness \(w\) ensuring that \(C\in \mathscr {L}\), \(\mathsf {Hash}(\mathsf {hk},\mathscr {L},C) = \mathsf {ProjHash}(\mathsf {hp},\mathscr {L},C,w)\), while when there is no such witness (i.e. \(C\notin \mathscr {L}\)), the smoothness property states that \(H = \mathsf {Hash}(\mathsf {hk},\mathscr {L},C)\) is random and independent of \(\mathsf {hp} \). In this paper, as in [26], we consider a weak form of \(\mathsf{SPHFs }\), where the projection key \(\mathsf {hp} \) can depend on C.
Concretely, if we have an \(\mathsf{SPHF }\) for some language \(\mathscr {L}\), we can set the public key \(\mathsf {ipk}\) to be empty (\(\bot \)), the secret key \(\mathsf {isk}\) to be the witness \(w\), the ciphertext \(c\) to be the projection key \(\mathsf {hp} \), and the encapsulated ephemeral key \(K\) would be the hash value. (Similar connections between \(\mathsf{SPHF }\) and zero knowledge were made in [1, 12, 25, 26]). The resulting \(\mathsf{iZK }\) would be correct and sound, the soundness coming from the smoothness of the \(\mathsf{SPHF }\): if the word C is not in \(\mathscr {L}\), even given the ciphertext \(c= \mathsf {hp} \), the hash value \(K\) looks random. However, it would not necessarily be zeroknowledge for two reasons: not only, a malicious verifier could generate a malformed projection key, for which the projected hash value of a word depends on the witness, but also there seems to be no trapdoor enabling to compute the hash value \(K\) from only \(c= \mathsf {hp} \).
These two issues could be solved using either Trapdoor \(\mathsf{SPHF }\) [7] or \(\mathsf{NIZK }\) of knowledge of \(\mathsf {hk} \). But both methods require pairings or random oracle, if instantiated on cyclic or bilinear groups. Instead we construct it as follows:
First, suppose that a projection key is wellformed (i.e., there exists a corresponding hashing key). Then, there exists an unbounded zeroknowledge simulator that “extracts” a corresponding hashing key and computes the hash value. To boost this into fullfledged zero knowledge with an efficient simulator, we rely on the “OR trick” from [22]. We add a random 4tuple \((g',h',u',e')\) to the CRS, and build an \(\mathsf{SPHF }\) for the augmented language \(C\in \mathscr {L}\) or \((g',h',u',e')\) is a \(\mathsf{DDH }\) tuple. In the normal setup, \((g',h',u',e')\) is not a \(\mathsf{DDH }\) tuple with overwhelming probability, so the soundness property is preserved. In the trapdoor setup, \((g',h',u',e') := (g',h',g'^r,h'^r)\) is a random \(\mathsf{DDH }\) tuple, and the zeroknowledge simulator uses the witness r to compute the hash value.
Second, to ensure that the projection key is wellformed, we use a second \(\mathsf{SPHF }\). The idea for building the second \(\mathsf{SPHF }\) is as follows: in most \(\mathsf{SPHF }\) schemes, proving that a projected key \(\mathsf {hp} \) is valid corresponds to proving that it lies in the column span of some matrix \(\varGamma \) (where all of the linear algebra is carried out in the exponent). Now pick a random vector \(\mathsf {tk} \): if \(\mathsf {hp} \) lies in the span of \(\varGamma \), then \(\mathsf {hp} ^\intercal \mathsf {tk} \) is completely determined given \(\varGamma ^\intercal \mathsf {tk} \); otherwise, it is completely random. The former yields the projective property and the latter yields smoothness, for the \(\mathsf{SPHF }\) with hashing key \(\mathsf {hk} \) and projection key \(\mathsf {tp} = \varGamma ^\intercal \mathsf {tk} \). Since the second \(\mathsf{SPHF }\) is built using the transpose \(\varGamma ^\intercal \) of the original matrix \(\varGamma \) (defining the language \(\mathscr {L}\)), we refer to it as a “transpose SPHF”. As it turns out, the second fix could ruin soundness of the ensuing \(\mathsf{iZK }\) protocol: a cheating prover could pick a malformed \(\varGamma ^\intercal \mathsf {tk} \), and then the hash value \(\mathsf {hp} ^\intercal \mathsf {tk} \) computed by the verifier could leak additional information about his witness \(\mathsf {hk} \) for \(\mathsf {hp} \), thereby ruining smoothness. To protect against the leakage, we would inject additional randomness into \(\mathsf {hk} \) so that smoothness holds even in the presence of leakage from the hash value \(\mathsf {hp} ^\intercal \mathsf {tk} \). This idea is inspired by the 2universality technique introduced in a very different context of chosenciphertext security [18].
Finally, to get simulationsoundness (i.e., soundness even if the adversary can see fake or simulated proofs), we rely on an additional “OR trick” (mixed up with an idea of Malkin et al. [40]): we build an \(\mathsf{SPHF }\) for the augmented language \(C \in \mathscr {L}\), or \((g',h',u',e')\) is a \(\mathsf{DDH }\) tuple (as before), or \((g',h',\mathcal {W}_1(C),\mathcal {W}_2(C))\) is not a \(\mathsf{DDH }\) tuple (with \(\mathcal {W}_k\) a Waters function [45], \(\mathcal {W}_k(m) = v_{k,0} \prod _{i=1}^{m} v_{k,i}^{m_i}\), when \(m=m_1\Vert \dots \Vert m_{m}\) is a bitstring, the \(v_{k,0},\dots ,v_{k,m}\) are random group elements, and C is seen as a bitstring, for \(k=1,2\)). In the security proof, with nonnegligible probability, \((g'',h'',\mathcal {W}_1(C),\mathcal {W}_2(C))\) is a non\(\mathsf{DDH }\) tuple for simulated proofs, and a \(\mathsf{DDH }\) tuple for the soundness challenge, which proves simulationsoundness.
Organization. First, we formally introduce the notion of implicit zeroknowledge proofs (\(\mathsf{iZK }\)) in Sect. 2. Second, in Sect. 3, we discuss some difficulties related to the construction of \(\mathsf{iZK } \) from \(\mathsf{SPHF }\) and provide an intuition of our method to overcome these difficulties. Next, we show how to construct \(\mathsf{iZK } \) and \(\mathsf{SSiZK } \) from \(\mathsf{SPHF }\) over cyclic groups for any language handled by the generic framework [7], which encompasses most, if not all, known \(\mathsf{SPHFs }\) over cyclic groups. This is the main technical part of the paper. Third, in Sect. 4, we indeed show a concrete application of our \(\mathsf{iZK }\) constructions: the most efficient 3round twoparty protocol computing inner product in the UC framework with static corruption so far. We analyze our construction and provide a detailed comparison with the GrothSahai methodology [32] and the approach based on zeroknowledge proofs “\(\grave{\mathrm{a}}\) la Schnorr” [42]. In addition, as proof of concept, we show in the full version [8] that \(\mathsf{iZK }\) can be used instead of ZK arguments to generically convert any protocol secure in the semihonest model into a protocol secure in the malicious model. This conversion follows the generic transformation of Goldreich, Micali and Wigderson (GMW) in their seminal papers [28, 29]. While applying directly the original transformation with Schnorrlike ZK protocols blows up the number of rounds by a multiplicative factor of at least three (even in the common reference string model), our conversion only adds a small constant number of rounds. Eventually, in the full version [8], we extend our construction of \(\mathsf{iZK } \) from \(\mathsf{SPHF } \) to handle larger classes of languages described by computational structures such as circuits or branching programs.
Additional Related Work. Using the “OR trick” with \(\mathsf{SPHF }\) is reminiscent of [2]. However, the methods used in our paper are very different from the one in [2], as we do not use pairings, but consider weaker form of \(\mathsf{SPHF }\) on the other hand.
A recent line of work has focused on the cutandchoose approach for transforming security from semihonest to malicious models [34, 35, 37, 38, 39, 43, 44] as an alternative to the use of zeroknowledge arguments. Indeed, substantial progress has been made towards practical protocols via this approach, as applied to Yao’s garbled circuits. However, the stateoftheart still incurs a large computation and communication multiplicative overhead that is equal to the security parameter. We note that Yao’s garbled circuits do not efficiently generalize to arithmetic computations, and that our approach would yield better concrete efficiency for natural functions F that admit compact representations by arithmetic branching programs. In particular, Yao’s garbled circuits cannot take advantage of the structure in languages handled by the GrothSahai methodology [32], and namely the ones defined by multiexponentiations: even in the latter case, GrothSahai technique requires pairings, while we will be able to avoid them.
The idea of using implicit proofs (without the zeroknowledge requirement) as a lightweight alternative to zeroknowledge proofs also appeared in an earlier work of Aiello, Ishai and Reingold [3]. They realize implicit proofs using conditional disclosure of secrets [27]. The latter, together with witness encryption [24] and \(\mathsf{SPHFs }\), only provide a weak “honestverifier zeroknowledge” guarantee.
Recently, Jarecki introduced the concept of conditional key encapsulation mechanism [36], which is related to \(\mathsf{iZK }\) as it adds a “zeroknowledge flavor” to \(\mathsf{SPHFs }\) by allowing witness extraction. The construction is a combination of \(\mathsf{SPHF }\) and zeroknowledge proofs “\(\grave{\mathrm{a}}\) la Schnorr”. Contrary to \(\mathsf{iZK }\), it does not aim at reducing the interactivity of the resulting protocol, but ensures its covertness.
Witness encryption was introduced by Garg et al. in [24]. It enables to encrypt a message M for a word C and a language \(\mathscr {L}\) into a ciphertext c, so that any user knowing a witness \(w\) that \(C\in \mathscr {L}\) can decrypt c. Similarly to \(\mathsf{SPHFs }\), witness encryption also only has this “honestverifier zeroknowledge” flavor: it does not enable to decrypt ciphertext for words \(C \notin \mathscr {L}\), with a trapdoor. That is why, as \(\mathsf{SPHF }\), witness encryption cannot be used to construct directly \(\mathsf{iZK }\).
2 Definition of Implicit ZeroKnowledge Arguments
2.1 Notations
Since we will now be more formal, let us present the notations that we will use. Let \({\{0,1\}}^*\) be the set of bitstrings. We denote by PPT a probabilistic polynomial time algorithm. We write \(y \leftarrow A(x)\) for ‘y is the output of the algorithm A on the input x’, while \(y \mathop {\leftarrow }\limits ^{{}_\$}A(x)\) means that A will additionally use random coins. Similarly, \(X \mathop {\leftarrow }\limits ^{{}_\$}\mathcal {X}\) indicates that X has been chosen uniformly at random in the (finite) set \(\mathcal {X}\). We sometimes write \(\mathsf {st}\) the state of the adversary. We define, for a distinguisher A and two distributions \(\mathcal {D}_0, \mathcal {D}_1\), the advantage of A (i.e., its ability to distinguish those distributions) by \(\mathsf {Adv}^{\mathcal {D}_0,\mathcal {D}_1}(A) = \Pr _{x \in \mathcal {D}_0}[A(x) = 1]\Pr _{x \in \mathcal {D}_1}[A(x) = 1]\). The qualities of adversaries will be measured by their successes and advantages in certain experiments \(\mathsf {Exp}^\mathtt sec _\mathcal {A}\) or \(\mathsf {Exp}^\mathtt{sec b}_\mathcal {A}\): \(\mathsf {Succ}^\mathtt sec (\mathcal {A},\mathfrak {K})=\Pr [\mathsf {Exp}^{\sec }_\mathcal {A}(1^\mathfrak {K})= 1]\) and \(\mathsf {Adv}^\mathtt{sec }(\mathcal {A},\mathfrak {K})=\Pr [\mathsf {Exp}^{\sec 1}_\mathcal {A}(1^\mathfrak {K}) = 1]\Pr [\mathsf {Exp}^{\sec 0}_\mathcal {A}(1^\mathfrak {K}) = 1]\) respectively, where \(\mathfrak {K}\) is the security parameter, and probabilities are over the random coins of the challenger and of the adversary.
2.2 Definition
Let \((\mathsf i \!\mathscr {L}_{\mathsf {crs}})_{\mathsf {crs}} \) be a family of NP languages, indexed by a common reference string \({\mathsf {crs}} \), and defined by a witness relation \(\mathsf i \mathcal {R}_{\mathsf {crs}} \), namely \(\mathsf i \!\mathscr {L}= \{ \mathsf {x}\in \mathsf i \!\mathcal {X}_{\mathsf {crs}} \mid \exists \mathsf {iw},\, \mathsf i \mathcal {R}_{\mathsf {crs}} (\mathsf {x},\mathsf {iw}) = 1 \}\), where \((\mathsf i \!\mathcal {X}_{\mathsf {crs}})_{\mathsf {crs}} \) is a family of sets. \({\mathsf {crs}} \) is generated by some polynomialtime algorithm \(\mathsf {Setup}_{{\mathsf {crs}}} \) taking as input the unary representation of the security parameter \(\mathfrak {K}\). We suppose that membership to \(\mathcal {X}_{\mathsf {crs}} \) and \(\mathsf i \mathcal {R}_{{\mathsf {crs}}}\) can be evaluated in polynomial time (in \(\mathfrak {K}\)). For the sake of simplicity, \({\mathsf {crs}} \) is often implicit.
To achieve stronger properties (namely simulationsoundness in Sect. 3.4), we sometimes also assume that \(\mathsf {Setup}_{{\mathsf {crs}}} \) can also output some additional information or trapdoor \(\mathcal {T} _{{\mathsf {crs}}} \). This trapdoor should enable to check, in polynomial time, whether a given word \(\mathsf {x}\) is in \(\mathsf i \!\mathscr {L}\) or not. It is only used in security proofs, and is never used by the \(\mathsf{iZK } \) algorithms.

\({\mathsf {i}{\mathsf {crs}}}\mathop {\leftarrow }\limits ^{{}_\$}{\mathsf {iSetup}}({\mathsf {crs}})\) generates the (normal) common reference string (CRS) \({\mathsf {i}{\mathsf {crs}}}\) (which implicitly contains \({\mathsf {crs}} \)). The resulting CRS provides statistical soundness;

\(({\mathsf {i}{\mathsf {crs}}}, {\mathsf {i}\!\mathcal {T}}) \mathop {\leftarrow }\limits ^{{}_\$}{\mathsf {iTSetup}}({\mathsf {crs}})\) ^{4} generates the (trapdoor) common reference string \({\mathsf {i}{\mathsf {crs}}}\) together with a trapdoor \({\mathsf {i}\!\mathcal {T}}\). The resulting CRS provides statistical zeroknowledge;

\((\mathsf {ipk},\mathsf {isk}) \mathop {\leftarrow }\limits ^{{}_\$}{\mathsf {iKG}}^\ell ({\mathsf {i}{\mathsf {crs}}}, \mathsf {x}, \mathsf {iw})\) generates a public/secret key pair, associated to a word \(\mathsf {x}\in \mathsf i \!\mathscr {L}\) and a label \(\ell \in {\{0,1\}}^*\), with witness \(\mathsf {iw}\);

\((\mathsf {ipk},\mathsf {itk}) \mathop {\leftarrow }\limits ^{{}_\$}{\mathsf {iTKG}}^\ell ({\mathsf {i}{\mathsf {crs}}}, {\mathsf {i}\!\mathcal {T}}, \mathsf {x})\) generates a public/trapdoor key pair, associated to a word \(\mathsf {x}\in \mathcal {X}\) and a label \(\ell \in {\{0,1\}}^*\);

\((c,K) \mathop {\leftarrow }\limits ^{{}_\$}{\mathsf {iEnc}}^\ell ({\mathsf {i}{\mathsf {crs}}}, \mathsf {ipk},\mathsf {x})\) outputs a ciphertext \(c\) of a value \(K\) (an ephemeral key), for the public key \(\mathsf {ipk}\), the word \(\mathsf {x}\), and the label \(\ell \in {\{0,1\}}^*\);

\(K\leftarrow {\mathsf {iDec}}^\ell ({\mathsf {i}{\mathsf {crs}}}, \mathsf {isk}, c)\) decrypts the ciphertext \(c\) for the label \(\ell \in {\{0,1\}}^*\), and outputs the ephemeral key \(K\);

\(K\leftarrow {\mathsf {iTDec}}^\ell ({\mathsf {i}{\mathsf {crs}}}, \mathsf {itk}, c)\) decrypts the ciphertext \(c\) for the label \(\ell \in {\{0,1\}}^*\), and outputs the ephemeral key \(K\).
The three last algorithms can be seen as key encapsulation and decapsulation algorithms. Labels \(\ell \) are only used for \(\mathsf{SSiZK }\) and are often omitted. The CRS \({\mathsf {i}{\mathsf {crs}}}\) is often omitted, for the sake of simplicity.
Normally, the algorithms \({\mathsf {iKG}}\) and \({\mathsf {iDec}}\) are used by the user who wants to (implicitly) prove that some word \(\mathsf {x}\) is in \(\mathsf i \!\mathscr {L}\) (and we often call this user the prover), while the algorithm \({\mathsf {iEnc}}\) is used by the user who wants to (implicitly) verify this (and we often call this user the verifier), as shown in Figs. 1 and 3. The algorithms \({\mathsf {iTKG}}\) and \({\mathsf {iTDec}}\) are usually only used in proofs, to generate simulated or fake implicit proofs (for the zeroknowledge property).
2.3 Security Requirements
 Correctness. The encryption is the reverse operation of the decryption, with or without a trapdoor: for any \({\mathsf {i}{\mathsf {crs}}}\mathop {\leftarrow }\limits ^{{}_\$}{\mathsf {iSetup}}({\mathsf {crs}})\) or with a trapdoor, for any \(({\mathsf {i}{\mathsf {crs}}},{\mathsf {i}\!\mathcal {T}}) \mathop {\leftarrow }\limits ^{{}_\$}{\mathsf {iTSetup}}({\mathsf {crs}})\), and for any \(\mathsf {x}\in \mathcal {X}\) and any \(\ell \in {\{0,1\}}^*\),

if \(\mathsf {x}\in \mathsf i \!\mathscr {L}\) with witness \(\mathsf {iw}\), \((\mathsf {ipk},\mathsf {isk}) \mathop {\leftarrow }\limits ^{{}_\$}{\mathsf {iKG}}^\ell ({\mathsf {i}{\mathsf {crs}}}, \mathsf {x}, \mathsf {iw})\), and \((c, K) \mathop {\leftarrow }\limits ^{{}_\$}{\mathsf {iEnc}}^\ell (\mathsf {ipk}, \mathsf {x})\), then we have \(K= {\mathsf {iDec}}^\ell (\mathsf {isk}, c)\);

if \((\mathsf {ipk},\mathsf {itk}) \mathop {\leftarrow }\limits ^{{}_\$}{\mathsf {iTKG}}^\ell ({\mathsf {i}\!\mathcal {T}}, \mathsf {x})\) and \((c, K) \mathop {\leftarrow }\limits ^{{}_\$}{\mathsf {iEnc}}^\ell (\mathsf {ipk},\mathsf {x})\), then we have \(K= {\mathsf {iTDec}}^\ell (\mathsf {itk}, c)\).

 Setup Indistinguishability. A polynomialtime adversary cannot distinguish a normal CRS generated by \({\mathsf {iSetup}}\) from a trapdoor CRS generated by \({\mathsf {iTSetup}}\). More formally, no PPT can distinguish, with nonnegligible advantage, the two distributions:$$\begin{aligned}&\{{\mathsf {i}{\mathsf {crs}}} \mid {\mathsf {i}{\mathsf {crs}}}\mathop {\leftarrow }\limits ^{{}_\$}{\mathsf {iSetup}}({\mathsf {crs}}) \}&\{ {\mathsf {i}{\mathsf {crs}}} \mid ({\mathsf {i}{\mathsf {crs}}},{\mathsf {i}\!\mathcal {T}}) \mathop {\leftarrow }\limits ^{{}_\$}{\mathsf {iTSetup}}({\mathsf {crs}})\}. \end{aligned}$$
 Soundness. When the CRS is generated as \({\mathsf {i}{\mathsf {crs}}}\mathop {\leftarrow }\limits ^{{}_\$}{\mathsf {iSetup}}({\mathsf {crs}})\), and when \(\mathsf {x}\notin \mathscr {L}\), the distribution of \(K\) is statistically indistinguishable from the uniform distribution, even given \(c\). More formally, if \(\varPi \) is the set of all the possible values of \(K\), for any bitstring \(\mathsf {ipk}\), for any word \(\mathsf {x}\notin \mathsf i \!\mathscr {L}\), for any label \(\ell \in {\{0,1\}}^*\), the two distributions:are statistically indistinguishable (\({\mathsf {iEnc}}\) may output \((\perp ,K)\) when the public key \(\mathsf {ipk}\) is not well formed).$$\begin{aligned}&\{(c,K) \mid (c,K) \mathop {\leftarrow }\limits ^{{}_\$}{\mathsf {iEnc}}^\ell (\mathsf {ipk},\mathsf {x})\}&\{(c,K') \mid (c,K) \mathop {\leftarrow }\limits ^{{}_\$}{\mathsf {iEnc}}^\ell (\mathsf {ipk},\mathsf {x}); K' \mathop {\leftarrow }\limits ^{{}_\$}\varPi \} \end{aligned}$$

ZeroKnowledge. For any label \(\ell \in {\{0,1\}}^*\), when the CRS is generated using \(({\mathsf {i}{\mathsf {crs}}},{\mathsf {i}\!\mathcal {T}}) \mathop {\leftarrow }\limits ^{{}_\$}{\mathsf {iTSetup}}^\ell ({\mathsf {crs}})\), for any message \(\mathsf {x}^* \in \mathsf i \!\mathscr {L}\) with the witness \(\mathsf {iw}^*\), the public key \(\mathsf {ipk}\) and the decapsulated key \(K\) corresponding to a ciphertext \(c\) chosen by the adversary, either using \(\mathsf {isk}\) or the trapdoor \(\mathsf {itk}\), should be indistinguishable, even given the trapdoor \({\mathsf {i}\!\mathcal {T}}\). More formally, we consider the experiment \(\mathsf {Exp}^{\mathtt{iZK\hbox {}zk }\hbox {}b}\) in Fig. 2. The \(\mathsf{iZK }\) is (statistically) zeroknowledge if the advantage of any adversary \(\mathcal {A}\) (not necessarily polynomialtime) for this experiment is negligible.
We defined our security notion with a “composable” security flavor, as Groth and Sahai in [32]: soundness and zeroknowledge are statistical properties, the only computational property is the setup indistinguishability property. This is slightly stronger than what is needed, but is satisfied by our constructions and often easier to use.
 Simulation Soundness. The soundness holds (computationally) even when the adversary can see simulated public keys and decryption with these keys. More formally, we consider the experiment \(\mathsf {Exp}^\mathtt{iZK\hbox {}ss \mathtt  b}\) in Fig. 2, where the oracle \(\mathcal {O}\), and the lists L and \(L'\) are defined as follows:

on input \((\ell ,\mathsf {x})\), \(\mathcal {O}\) generates \((\mathsf {ipk},\mathsf {itk}) \mathop {\leftarrow }\limits ^{{}_\$}{\mathsf {iTKG}}({\mathsf {i}{\mathsf {crs}}},{\mathsf {i}\!\mathcal {T}}, \mathsf {x})\), stores \((\ell ,\mathsf {x},\mathsf {ipk},\mathsf {itk})\) in a list L, and outputs \(\mathsf {ipk}\);

on input \((\mathsf {ipk}, c)\), \(\mathcal {O}\) retrieves the record \((\ell ,\mathsf {x},\mathsf {ipk},\mathsf {itk})\) from L (and aborts if no such record exists), removes it from L, and adds it to \(L'\), computes \(K\leftarrow {\mathsf {iTDec}}^\ell ({\mathsf {i}{\mathsf {crs}}},\mathsf {itk},c)\), and outputs \(K\).
The \(\mathsf{iZK }\) is (statistically) simulationsound if the advantage of any adversary \(\mathcal {A}\) (not necessarily polynomialtime) for this experiment is negligible.

Remark 1
An \(\mathsf{iZK }\) for some language \(\mathsf i \!\mathscr {L}\) directly leads to a 3round zeroknowledge arguments for \(\mathsf i \!\mathscr {L}\). The construction is depicted in Fig. 3 and the proof is provided in the full version [8]. If the \(\mathsf{iZK }\) is additionally simulationsound, the resulting zeroknowledge argument is also simulationsound.
Remark 2
For the sake of completeness, in the full version [8], we show how to construct \(\mathsf{iZK }\) from either \(\mathsf{NIZK }\) or Trapdoor \(\mathsf{SPHFs }\). In the latter case, the resulting \(\mathsf{iZK }\) is not statistically sound and zeroknowledge but only computationally sound and zeroknowledge. In both cases, using currently known constructions over cyclic groups, strong assumptions such as the random oracle model or pairings are needed.
3 Construction of Implicit ZeroKnowledge Arguments
Let us first recall the generic framework of \(\mathsf{SPHFs }\) [7] for the particular case of cyclic groups, and when the projection key \(\mathsf {hp} \) can depend on the word C, as it is at the core of our construction of \(\mathsf{iZK }\). Second, we explain in more details the limitations of \(\mathsf{SPHFs }\) and the fact they cannot directly be used to construct \(\mathsf{iZK }\) (even with a concrete attack). Third, we show how to overcome these limitations to build \(\mathsf{iZK }\) and \(\mathsf{SSiZK }\).
3.1 Review of the Generic Framework of \(\mathsf{SPHFs }\) over Cyclic Groups
Languages. Let \(\mathbb {G}\) be a cyclic group of prime order p and \(\mathbb {Z}_p\) the field of integers modulo p. If we look at \(\mathbb {G}\) and \(\mathbb {Z}_p\) as the same ring \((\mathbb {G},+,\bullet )\), where internal operations are on the scalars, many interesting languages can be represented as subspaces of the vector space \(\mathbb {G}^n\), for some n. Here are some examples.
Example 3
Example 4
Example 5
Example 6
For the sake of clarity, we will omit the C argument, and write \(\varGamma \), instead of \(\varGamma (C)\).
3.2 Limitations of Smooth Projective Hash Functions

\({\mathsf {iSetup}}({\mathsf {crs}})\) and \({\mathsf {iTSetup}}({\mathsf {crs}})\) outputs the empty CRS \({\mathsf {i}{\mathsf {crs}}}:=\perp \);

\({\mathsf {iKG}}({\mathsf {i}{\mathsf {crs}}},\mathsf {x},\mathsf {iw})\) outputs an empty public key \(\mathsf {ipk}:=\perp \) together with the secret key \(\mathsf {isk}:=(\mathsf {x}, \mathsf {iw})\);

\({\mathsf {iEnc}}(\mathsf {ipk},\mathsf {x})\) generates a random hashing key \(\mathsf {hk} \mathop {\leftarrow }\limits ^{{}_\$}\mathsf {HashKG}({\mathsf {crs}},\mathsf {x})\) and outputs the ciphertext \(c:=\mathsf {hp} \leftarrow \mathsf {ProjKG}(\mathsf {hk},{\mathsf {crs}},\mathsf {x})\) together with the ephemeral key \(K:=H \leftarrow \mathsf {Hash}(\mathsf {hk},{\mathsf {crs}},\mathsf {x})\);

\({\mathsf {iDec}}(\mathsf {isk},c)\) outputs the ephemeral key \(K:={\mathsf {proj}H} \leftarrow \mathsf {ProjHash}(\mathsf {hp},{\mathsf {crs}},\mathsf {x},\mathsf {iw})\).
This construction is sound: if \(\mathsf {x}\notin \mathscr {L}\), given only \(c=\mathsf {hp} \), the smoothness ensures that \(K=H\) looks random. Unfortunately, there seems to be no way to compute \(K\) from only \(c\), or in other words, there does not seem to exist algorithms \({\mathsf {iTKG}}\) and \({\mathsf {iTDec}}\).
Example 6 Is Not ZeroKnowledge. Actually, with the \(\mathsf{SPHF }\) from Example 6, no such algorithm \({\mathsf {iTKG}}\) or \({\mathsf {iTDec}}\) (verifying the zeroknowledge property) exists. It is even worse than that: a malicious verifier may get information about the witness, even if he just has a feedback whether the prover could use the correct hash value or not (and get the masked value or not), in a protocol such as the one in Fig. 1. A malicious verifier can indeed generate a ciphertext \(c= \mathsf {hp} \), by generating \(\mathsf {hp} _1\) honestly but by picking \(\mathsf {hp} _2\) and \(\mathsf {hp} _3\) uniformly at random. Now, a honest prover will compute \({\mathsf {proj}H} = \mathsf {hp} _1^r\mathsf {hp} _2^b\mathsf {hp} _3^{rb}\), to get back the ephemeral key (using \({\mathsf {iDec}}\)). When C is an encryption of \(b=1\), this value is random and independent of H, as \(\mathsf {hp} _2\) and \(\mathsf {hp} _3\) have been chosen at random, while when \(b=0\), this value is the correct \({\mathsf {proj}H}\) and is equal to \(H\). Thus the projected hash value \({\mathsf {proj}H} \), which is the ephemeral output key by the honest prover, reveals some information about b, part of the witness.
If we want to avoid such an attack, the prover has to make sure that the \(\mathsf {hp}\) he received was built correctly. Intuitively, this sounds exactly like the kind of verifications we could make with an \(\mathsf{SPHF }\): we could simply build an \(\mathsf{SPHF }\) on the language of the “correctly built” \(\mathsf {hp}\). Then the prover could send a projection key for this new \(\mathsf{SPHF }\) and ask the verifier to XOR the original hash value H with the hash value of this new \(\mathsf{SPHF }\). However, things are not that easy: first this does not solve the limitation due to the security proof (the impossibility of computing H for \(\mathsf {x}\notin \mathsf i \!\mathscr {L}\)) and second, in the \(\mathsf{SPHF }\) in Example 6, all projection keys are valid (since \(\varGamma \) is fullrank, for any \(\mathsf {hp} \), there exists necessarily a \(\mathsf {hk} \) such that \(\mathsf {hp} = \varGamma \bullet \mathsf {hk} \)).
3.3 \(\mathsf{iZK }\) Construction
Let us consider an \(\mathsf{SPHF }\) defined as in Sect. 3.1 for a language \(\mathsf i \!\mathscr {L}= \mathscr {L}\). In this section, we show how to design, step by step, an \(\mathsf{iZK }\) for \(\mathsf i \!\mathscr {L}\) from this \(\mathsf{SPHF }\), following the overview in Sect. 1. At the end, we provide a summary of the construction and a complete proof. We illustrate our construction on the language of ElGamal ciphertexts of bits (Examples 4 and 6), and refer to this language as “our example”. We suppose a cyclic group \(\mathbb {G}\) of prime order p is fixed, and that \(\mathsf{DDH }\) is hard in \(\mathbb {G}\) ^{5}.
We have seen the limitations of directly using the original \(\mathsf{SPHF }\) are actually twofold. First, \(\mathsf{SPHFs }\) do not provide a way to compute the hash value of a word outside the language, with just a projection key for which the hashing key is not known. Second, nothing ensures that a projection key has really been derived from an actually known hashing key, and in such a bad case, the projected hash value may leak some information about the word C (and the witness).
To better explain our construction, we first show how to overcome the first limitation. Thereafter, we will show how our approach additionally allows to check the validity of the projection keys (with a nontrivial validity meaning). It will indeed be quite important to notice that the projection keys coming from our construction (according to one of the setups) will not necessarily be valid (with a corresponding hashing key), as the corresponding matrix \(\varGamma \) will not always be full rank, contrary to the projection keys of the \(\mathsf{SPHF }\) in Example 6. Hence, the language of the valid projection keys will make sense in this setting.

\(r',s'\) two random distinct scalars in \(\mathbb {Z}_p\), for the normal CRS generated by \({\mathsf {iSetup}}\), so that \((g',h',u',e')\) is not a \(\mathsf{DDH }\) tuple;

\(r'=s'\) a random scalar in \(\mathbb {Z}_p\), for the trapdoor CRS generated by \({\mathsf {iTSetup}}\), with \({\mathsf {i}\!\mathcal {T}}=r'\) the trapdoor, so that \((g',h',u',e')\) is a \(\mathsf{DDH }\) tuple.
 If \(\lambda _{t,6} \ne 0\), looking at the second and the third columns of \(\varGamma _t\) gives that:or in other words \((u',e')\) is a \(\mathsf{DDH }\) tuple in basis \((g',h')\);$$\begin{aligned} \lambda _{t,5} \bullet (g',\; h') +\lambda _{t,6} \bullet (u',\;e') = (1,1) {\,\text {, i.e.,}\,} (u',e') = (g'^{\lambda _{t,5}/\lambda _{t,6}},\;h'^{\lambda _{t,5}/\lambda _{t,6}}), \end{aligned}$$

if \(\lambda _{t,4} \ne 0\), looking at the last four columns of \(\varGamma _t\) gives that: \(\lambda _{t,4} \bullet \mathbf {\hat{C}}= \lambda _{t,4} \bullet (u,e,1,1)\) is a linear combination of rows of \(\varGamma \), hence \(\mathbf {\hat{C}}\) too. As a consequence, by definition of \(\mathscr {L}\), \(C \in \mathscr {L}\).
However, the latter way to compute \({\mathsf {proj}H} \) gives the same result as the former way, only if \(\mathsf {hp} _{t,5}\) and \(\mathsf {hp} _{t,6}\) involve the correct value for \(\mathsf {hk} _1\). A malicious verifier could decide to choose random \(\mathsf {hp} _{t,5}\) and \(\mathsf {hp} _{t,6}\), which would make \(\mathbf {\lambda '_t} \bullet \mathsf {hp} \) look random and independent of the real hash value!
Ensuring the Validity of Projection Keys. The above construction and trapdoor would provide zeroknowledge if we could ensure that the projection keys \(\mathsf {hp} \) (generated by a potentially malicious verifier) is valid, so that, intuitively, \(\mathsf {hp} _{t,5}\) and \(\mathsf {hp} _{t,6}\) involve the correct value of \(\mathsf {hk} _1\). Using a zeroknowledge proof (that \(\mathsf {hp} \) derives from some hashing key \(\mathsf {hk} \)) for that purpose would annihilate all our efforts to avoid adding rounds and to work under plain \(\mathsf{DDH }\) (interactive ZK proofs introduce more rounds, and GrothSahai [32] \(\mathsf{NIZK }\) would require assumptions on bilinear groups). So we are left with doing the validity check again with \(\mathsf{SPHFs }\).
Fortunately, the language of valid projection keys \(\mathsf {hp} \) can be handled by the generic framework, since a valid projection key \(\mathsf {hp} \) is such that: \(\mathsf {hp} = \varGamma _t \bullet \mathsf {hk} \), or in other words, if we transpose everything \(\mathsf {hp} ^\intercal = \mathsf {hk} ^\intercal \bullet \varGamma _t^\intercal \). This is exactly the same as in Eq. (1), with \(\mathbf {\hat{C}}\leftrightarrow \mathsf {hp} ^\intercal \), \(\varGamma \leftrightarrow \varGamma _t^\intercal \) and witness \(\mathbf {\lambda }\leftrightarrow \mathsf {hk} ^\intercal \). So we can now define a smooth projective hash function on that language, where the projection key is called transposed projection key \(\mathsf {tp} \), the hashing key is called transposed hashing key \(\mathsf {tk} \), the hash value is called transposed hash value \({\mathsf {t}H} \) and the projected hash value is called transposed projected hash value \({\mathsf {t}{\mathsf {proj}H}} \).
Finally, we could define an \(\mathsf{iZK }\), similarly to the one in Sect. 3.2, except, \(\mathsf {ipk}\) contains a transposed projection key \(\mathsf {tp} \) (generated by the prover from a random transposed hashing key \(\mathsf {tk} \)), and c contains the associated transposed projected hash value \({\mathsf {t}{\mathsf {proj}H}} \) in addition to \(\mathsf {hp} \), so that the prover can check using \(\mathsf {tk} \) that \(\mathsf {hp} \) is valid by verifying whether \({\mathsf {t}{\mathsf {proj}H}} = {\mathsf {t}H} \) or not.
An Additional Step. Unfortunately, we are not done yet, as the above modification breaks the soundness property! Indeed, in this last construction, the prover now learns an additional information about the hash value H: \({\mathsf {t}{\mathsf {proj}H}} = \mathsf {hk} ^\intercal \mathsf {tp} \), which does depend on the secret key \(\mathsf {hk} \). He could therefore choose \(\mathsf {tp} = \mathbf {\hat{C}}_t^\intercal \), so that \({\mathsf {t}{\mathsf {proj}H}} = \mathsf {hk} ^\intercal \mathbf {\hat{C}}_t^\intercal = \mathbf {\hat{C}}_t \mathsf {hk} \) is the hash value \(H = K\) of C under \(\mathsf {hk} \).
We can fix this by ensuring that the prover will not know the extended word \(\mathbf {\hat{C}}_t\) on which the \(\mathsf{SPHF }\) will be based when he sends \(\mathsf {tp}\), using an idea similar to the 2universality property of \(\mathsf{SPHF }\) introduced by Cramer and Shoup in [18]. For that purpose, we extend \(\varGamma _t\) and make \(\mathbf {\hat{C}}_t\) depends on a random scalar \(\zeta \in \mathbb {Z}_p\) chosen by the verifier (and included in \(c\)).
Detailed Construction. Let us now formally show how to build an \(\mathsf{iZK }\) from any \(\mathsf{SPHF }\) built from the generic framework of [7], following the previous ideas. We recall that we consider a language \(\mathscr {L}=\mathsf i \!\mathscr {L}\), such that a word \(\mathsf {x}=C\) is in \(\mathsf i \!\mathscr {L}\), if and only if \(\mathbf {\hat{C}}= \theta (C)\) is a linear combination of the rows of some matrix \(\varGamma \in \mathbb {G}^{k \times n}\) (which may depend on C). The coefficients of this linear combination are entries of a row vector \(\mathbf {\lambda }\in \mathbb {Z}_p^{1 \times k}\): \(\mathbf {\hat{C}}= \mathbf {\lambda }\bullet \varGamma \), where \(\mathbf {\lambda }= \mathbf {\lambda }(\mathsf {iw})\) can be computed from the witness \(\mathsf {iw}\) for \(\mathsf {x}\).
Variants. In numerous cases, it is possible to add the trapdoor in a slightly more efficient way, if we accept to use worddependent CRS. While the previous construction would be useful for security in the \(\mathsf{UC }\) framework [15], the more efficient construction with a worddependent CRS is enough in the standalone setting. Independently of that improvement, it is also possible to slightly reduce the size of \(\mathsf {hp} \), by computing \(\zeta \) with an entropy extractor, and so dropping it from \(\mathsf {hp} \). Details for both variants are given in the full version [8].
3.4 \(\mathsf{SSiZK }\) Construction
Our \(\mathsf{SSiZK }\) construction is similar to our \(\mathsf{iZK }\) construction, except that, in addition both \({\mathsf {iSetup}}\) and \({\mathsf {iTSetup}}\) add the CRS \({\mathsf {i}{\mathsf {crs}}}\), a tuple \((v_{k,i})^{k=1,2}_{i=0,\dots ,2\mathfrak {K}}\) of group elements constructed as follows: for \(i=0\) to \(2\mathfrak {K}\) (with \(\mathfrak {K}\) the security parameter): \(r'_i \mathop {\leftarrow }\limits ^{{}_\$}\mathbb {Z}_p, v_{1,i} \leftarrow {g'}^{r'_i}, v_{2,i} \leftarrow {h'}^{r'_i}.\) We also define the two Waters functions [45] \(\mathcal {W}_k: {\{0,1\}}^{2\mathfrak {K}} \rightarrow \mathbb {G}\), as \(\mathcal {W}_k(m) = v_{k,0} \prod _{i=1}^{2\mathfrak {K}} v_{k,i}^{m_i}\), for any bitstring \(m = m_1\Vert \dots \Vert m_{2\mathfrak {K}} \in {\{0,1\}}^{2\mathfrak {K}}\). Finally, the CRS is also supposed to contain a hash function \(\mathcal {H}: {\{0,1\}}^*\rightarrow {\{0,1\}}^{2\mathfrak {K}}\) drawn from a collisionresistant hash function family \(\mathcal {HF}\).
Here is an overview of the security proof. Correctness, setup indistinguishability, and zeroknowledge are straightforward. Soundness follows from the fact that \((g',h',u'',e'')\) is a \(\mathsf{DDH }\)tuple, when parameters are generated by \({\mathsf {iSetup}}\) (and also \({\mathsf {iTSetup}}\) actually), and so \((g',1)\) is never in the subspace generated by \((g',h')\) and \((u'',e'')\) (as \(h' \ne 1\)), hence the corresponding language \(\mathscr {L}_t\) is the same as for our \(\mathsf{iZK }\) construction. Finally, to prove simulationsoundness, we use the programmability of the Waters function [33] and change the generation of the group elements \((v_{k,i})\) so that for the challenge proof (generated by the adversary) \((g',h',u'',e'')\) is not a \(\mathsf{DDH }\)tuple, while for the simulated proofs it is a \(\mathsf{DDH }\)tuple. Then, we can change the setup to \({\mathsf {iSetup}}\), while still being able to simulate proofs. But in this setting, the word \(\mathbf {\hat{C}}_t\) for the challenge proof is no more in \(\mathscr {L}_t\), and smoothness implies simulationsoundness.
4 Application to the Inner Product
In case of biometric authentication, a server \(\mathcal {S}\) wants to compute the Hamming distance between a fresh user’s feature and the stored template, but without asking the two players to reveal their own input: the template y from the server side and the fresh feature x from the client side. One can see that the Hamming distance between the \(\ell \)bit vectors x and y is the sum of the Hamming weights of x and y, minus twice the inner product of x and y. Let us thus focus on this private evaluation of the inner product: a client \(\mathcal {C}\) has an input \(x = (x_i)_{i=1}^\ell \in \{0,1\}^\ell \) and a server \(\mathcal {S}\) has an input \(y = (y_i)_{i=1}^\ell \in \{0,1\}^\ell \). The server \(\mathcal {S}\) wants to learn the inner product \(\mathsf{IP} = \sum _{i=1}^\ell x_i y_i \in \{0, \dots , \ell \}\), but nothing else, while the client \(\mathcal {C}\) just learns whether the protocol succeeded or was aborted.
SemiHonest Protocol. \(\mathcal {C}\) can send an ElGamal encryption of each bit under a public key of her choice and then \(\mathcal {S}\) can compute an encryption of \(\mathsf{IP }+R\), with \(R \in \mathbb {Z}_p\) a random mask, using the homomorphic properties of ElGamal, and sends this ciphertext. \(\mathcal {C}\) finally decrypts and sends back \(g^{\mathsf{IP }+R}\) to \(\mathcal {S}\) who divides it by \(g^R\) to get \(g^\mathsf{IP }\). Since \(\mathsf{IP }\) is small, an easy discrete logarithm computation leads to \(\mathsf{IP }\).
Proofs  Pairings  Exponentiations  Communication  Rounds 

\(\varSigma \)proofs  0  \(38\ell \)  \(20\ell \)  5 
GS proofs  \({>}14\ell \)  \({\gg } 28\ell (\mathbb {G}_1) + 6\ell (\mathbb {G}_2)\)  \({>}11\ell (\mathbb {G}_1) + 10\ell (\mathbb {G}_2)\)  3 
\(\mathsf{iZK }\) (this paper)  0  \(67\ell \)  \(21\ell \)  3 
Footnotes
 1.
According to [20], an exponentiation takes about 200,000 cycles.
 2.
Assuming exponentiations can be made in parallel, which is the case for our \(\mathsf{iZKs }\).
 3.
In our formalization, actually, it is the flow together all the previous flows. But we just say it is the flow to simplify explanations.
 4.
When the CRS is worddependent, i.e., when the trapdoor \({\mathsf {i}\!\mathcal {T}}\) does only work for one word \(\mathsf {x}^*\) previously chosen, there is a second argument: \(({\mathsf {i}{\mathsf {crs}}}, {\mathsf {i}\!\mathcal {T}}) \mathop {\leftarrow }\limits ^{{}_\$}{\mathsf {iTSetup}}({\mathsf {crs}},\mathsf {x}^*)\). Security notions are then slightly different. See details in the full version [8].
 5.
The construction can be trivially extended to \(\mathsf{DLin }\), or any \(\mathsf{MDDH }\) assumption [21] though.
 6.
Contrary to [2] however, our matrix \(\varGamma _t\) depends on the words \(C_t\), which is why we get this more efficient construction.
Notes
Acknowledgments
This work was supported in part by the CFM Foundation, ANR14CE280003 (Project EnBid), and the European Research Council under the European Community’s Seventh Framework Programme (FP7/20072013 Grant Agreement no. 339563 – CryptoCloud).
References
 1.Abdalla, M., Benhamouda, F., Blazy, O., Chevalier, C., Pointcheval, D.: SPHFfriendly noninteractive commitments. In: Sako, K., Sarkar, P. (eds.) ASIACRYPT 2013, Part I. LNCS, vol. 8269, pp. 214–234. Springer, Heidelberg (2013) CrossRefGoogle Scholar
 2.Abdalla, M., Benhamouda, F., Pointcheval, D.: Disjunctions for hash proof systems: New constructions and applications. Cryptology ePrint Archive, Report 2014/483 (2014). http://eprint.iacr.org/2014/483
 3.Aiello, W., Ishai, Y., Reingold, O.: Priced oblivious transfer: how to sell digital goods. In: Pfitzmann, B. (ed.) EUROCRYPT 2001. LNCS, vol. 2045, p. 119. Springer, Heidelberg (2001) CrossRefGoogle Scholar
 4.Barbulescu, R., Gaudry, P., Joux, A., Thomé, E.: A heuristic quasipolynomial algorithm for discrete logarithm in finite fields of small characteristic. In: Nguyen, P.Q., Oswald, E. (eds.) EUROCRYPT 2014. LNCS, vol. 8441, pp. 1–16. Springer, Heidelberg (2014) CrossRefGoogle Scholar
 5.Bellare, M., Boldyreva, A., Palacio, A.: An uninstantiable randomoraclemodel scheme for a hybridencryption problem. In: Cachin, C., Camenisch, J.L. (eds.) EUROCRYPT 2004. LNCS, vol. 3027, pp. 171–188. Springer, Heidelberg (2004) CrossRefGoogle Scholar
 6.Bellare, M., Rogaway, P.: Random oracles are practical: a paradigm for designing efficient protocols. In: Ashby, V. (ed.) ACM CCS 1993, pp. 62–73. ACM Press, November 1993Google Scholar
 7.Benhamouda, F., Blazy, O., Chevalier, C., Pointcheval, D., Vergnaud, D.: New techniques for SPHFs and efficient oneround PAKE protocols. In: Canetti, R., Garay, J.A. (eds.) CRYPTO 2013, Part I. LNCS, vol. 8042, pp. 449–475. Springer, Heidelberg (2013) CrossRefGoogle Scholar
 8.Benhamouda, F., Couteau, G., Pointcheval, D., Wee, H.: Implicit zeroknowledge arguments and applications to the malicious setting. Cryptology ePrint Archive, Report 2015/246 (2015). http://eprint.iacr.org/2015/246
 9.Bernhard, D., Pereira, O., Warinschi, B.: How not to prove yourself: pitfalls of the fiatshamir heuristic and applications to helios. In: Wang, X., Sako, K. (eds.) ASIACRYPT 2012. LNCS, vol. 7658, pp. 626–643. Springer, Heidelberg (2012) CrossRefGoogle Scholar
 10.Bernstein, D.J.: Curve25519: new diffiehellman speed records. In: Yung, M., Dodis, Y., Kiayias, A., Malkin, T. (eds.) PKC 2006. LNCS, vol. 3958, pp. 207–228. Springer, Heidelberg (2006) CrossRefGoogle Scholar
 11.Beuchat, J.L., GonzálezDíaz, J.E., Mitsunari, S., Okamoto, E., RodríguezHenríquez, F., Teruya, T.: Highspeed software implementation of the optimal ate pairing over barreto–naehrig curves. In: Joye, M., Miyaji, A., Otsuka, A. (eds.) Pairing 2010. LNCS, vol. 6487, pp. 21–39. Springer, Heidelberg (2010) CrossRefGoogle Scholar
 12.Blazy, O., Pointcheval, D., Vergnaud, D.: Roundoptimal privacypreserving protocols with smooth projective hash functions. In: Cramer, R. (ed.) TCC 2012. LNCS, vol. 7194, pp. 94–111. Springer, Heidelberg (2012) CrossRefGoogle Scholar
 13.Brassard, G., Chaum, D., Crépeau, C.: Minimum disclosure proofs of knowledge. J. Comput. Syst. Sci. 37(2), 156–189 (1988). http://dx.doi.org/10.1016/00220000(88)90005–0 CrossRefzbMATHGoogle Scholar
 14.Brodkin, J.: Satellite internet faster than advertised, but latency still awful, Feb 2013. http://arstechnica.com/informationtechnology/2013/02/satelliteinternetfasterthanadvertisedbutlatency
 15.Canetti, R.: Universally composable security: a new paradigm for cryptographic protocols. In: 42nd FOCS, pp. 136–145. IEEE Computer Society Press, October 2001Google Scholar
 16.Canetti, R., Goldreich, O., Halevi, S.: The random oracle methodology. J. ACM 51(4), 557–594 (2004). revisited. http://doi.acm.org/10.1145/1008731.1008734 MathSciNetCrossRefzbMATHGoogle Scholar
 17.Cramer, R., Shoup, V.: A practical public key cryptosystem provably secure against adaptive chosen ciphertext attack. In: Krawczyk, H. (ed.) CRYPTO 1998. LNCS, vol. 1462, p. 13. Springer, Heidelberg (1998) CrossRefGoogle Scholar
 18.Cramer, R., Shoup, V.: Universal hash proofs and a paradigm for adaptive chosen ciphertext secure publickey encryption. In: Knudsen, L.R. (ed.) EUROCRYPT 2002. LNCS, vol. 2332, p. 45. Springer, Heidelberg (2002) CrossRefGoogle Scholar
 19.Dolev, D., Dwork, C., Naor, M.: Nonmalleable cryptography (extended abstract). In: 23rd ACM STOC, pp. 542–552. ACM Press, May 1991Google Scholar
 20.ECRYPT II: eBATS. http://bench.cr.yp.to/resultsdh.html
 21.Escala, A., Herold, G., Kiltz, E., Ràfols, C., Villar, J.: An algebraic framework for diffiehellman assumptions. In: Canetti, R., Garay, J.A. (eds.) CRYPTO 2013, Part II. LNCS, vol. 8043, pp. 129–147. Springer, Heidelberg (2013) CrossRefGoogle Scholar
 22.Feige, U., Lapidot, D., Shamir, A.: Multiple noninteractive zero knowledge proofs based on a single random string (extended abstract). In: 31st FOCS, pp. 308–317. IEEE Computer Society Press, October 1990Google Scholar
 23.Fiat, A., Shamir, A.: How to prove yourself: practical solutions to identification and signature problems. In: Odlyzko, A.M. (ed.) CRYPTO 1986. LNCS, vol. 263, pp. 186–194. Springer, Heidelberg (1987) CrossRefGoogle Scholar
 24.Garg, S., Gentry, C., Sahai, A., Waters, B.: Witness encryption and its applications. In: Boneh, D., Roughgarden, T., Feigenbaum, J. (eds.) 45th ACM STOC, pp. 467–476. ACM Press, June 2013Google Scholar
 25.Gennaro, R., Lindell, Y.: A framework for passwordbased authenticated key exchange. In: Biham, E. (ed.) EUROCRYPT 2003. LNCS, vol. 2656, pp. 524–543. Springer, Heidelberg (2003). http://eprint.iacr.org/2003/032.ps.gz CrossRefGoogle Scholar
 26.Gennaro, R., Lindell, Y.: A framework for passwordbased authenticated key exchange. ACM Trans. Inf. Syst. Secur. 9(2), 181–234 (2006)CrossRefGoogle Scholar
 27.Gertner, Y., Ishai, Y., Kushilevitz, E., Malkin, T.: Protecting data privacy in private information retrieval schemes. In: 30th ACM STOC, pp. 151–160. ACM Press, May 1998Google Scholar
 28.Goldreich, O., Micali, S., Wigderson, A.: How to play any mental game or A completeness theorem for protocols with honest majority. In: Aho, A. (ed.) 19th ACM STOC, pp. 218–229. ACM Press, May 1987Google Scholar
 29.Goldreich, O., Micali, S., Wigderson, A.: How to prove all NPstatements in zeroknowledge and a methodology of cryptographic protocol design. In: Odlyzko, A.M. (ed.) CRYPTO 1986. LNCS, vol. 263, pp. 171–185. Springer, Heidelberg (1987) CrossRefGoogle Scholar
 30.Goldwasser, S., Micali, S., Rackoff, C.: The knowledge complexity of interactive proof systems. SIAM J. Comput. 18(1), 186–208 (1989)MathSciNetCrossRefzbMATHGoogle Scholar
 31.Granger, R., Kleinjung, T., Zumbrägel, J.: Breaking ‘128bit Secure’ supersingular binary curves. In: Garay, J.A., Gennaro, R. (eds.) CRYPTO 2014, Part II. LNCS, vol. 8617, pp. 126–145. Springer, Heidelberg (2014) Google Scholar
 32.Groth, J., Sahai, A.: Efficient noninteractive proof systems for bilinear groups. In: Smart, N.P. (ed.) EUROCRYPT 2008. LNCS, vol. 4965, pp. 415–432. Springer, Heidelberg (2008) CrossRefGoogle Scholar
 33.Hofheinz, D., Kiltz, E.: Programmable hash functions and their applications. J. Cryptol. 25(3), 484–527 (2012)MathSciNetCrossRefzbMATHGoogle Scholar
 34.Huang, Y., Katz, J., Evans, D.: Efficient secure twoparty computation using symmetric cutandchoose. In: Canetti, R., Garay, J.A. (eds.) CRYPTO 2013, Part II. LNCS, vol. 8043, pp. 18–35. Springer, Heidelberg (2013) CrossRefGoogle Scholar
 35.Ishai, Y., Kushilevitz, E., Lindell, Y., Petrank, E.: Blackbox constructions for secure computation. In: Kleinberg, J.M. (ed.) 38th ACM STOC, pp. 99–108. ACM Press, May 2006Google Scholar
 36.Jarecki, S.: Practical covert authentication. In: Krawczyk, H. (ed.) PKC 2014. LNCS, vol. 8383, pp. 611–629. Springer, Heidelberg (2014) CrossRefGoogle Scholar
 37.Lindell, Y.: Fast cutandchoose based protocols for malicious and covert adversaries. In: Canetti, R., Garay, J.A. (eds.) CRYPTO 2013, Part II. LNCS, vol. 8043, pp. 1–17. Springer, Heidelberg (2013) CrossRefGoogle Scholar
 38.Lindell, Y., Pinkas, B.: An efficient protocol for secure twoparty computation in the presence of malicious adversaries. In: Naor, M. (ed.) EUROCRYPT 2007. LNCS, vol. 4515, pp. 52–78. Springer, Heidelberg (2007) CrossRefGoogle Scholar
 39.Lindell, Y., Pinkas, B.: Secure twoparty computation via cutandchoose oblivious transfer. In: Ishai, Y. (ed.) TCC 2011. LNCS, vol. 6597, pp. 329–346. Springer, Heidelberg (2011) CrossRefGoogle Scholar
 40.Malkin, T., Teranishi, I., Vahlis, Y., Yung, M.: Signatures resilient to continual leakage on memory and computation. In: Ishai, Y. (ed.) TCC 2011. LNCS, vol. 6597, pp. 89–106. Springer, Heidelberg (2011) CrossRefGoogle Scholar
 41.Naor, M., Yung, M.: Publickey cryptosystems provably secure against chosen ciphertext attacks. In: 22nd ACM STOC, pp. 427–437. ACM Press, May 1990Google Scholar
 42.Schnorr, C.P.: Efficient identification and signatures for smart cards. In: Brassard, G. (ed.) CRYPTO 1989. LNCS, vol. 435, pp. 239–252. Springer, Heidelberg (1990) Google Scholar
 43.Shelat, A., Shen, C.: Twooutput secure computation with malicious adversaries. In: Paterson, K.G. (ed.) EUROCRYPT 2011. LNCS, vol. 6632, pp. 386–405. Springer, Heidelberg (2011) CrossRefGoogle Scholar
 44.Shelat, A., Shen, C.H.: Fast twoparty secure computation with minimal assumptions. In: Sadeghi, A.R., Gligor, V.D., Yung, M. (eds.) ACM CCS 13, pp. 523–534. ACM Press, November 2013Google Scholar
 45.Waters, B.: Efficient identitybased encryption without random oracles. In: Cramer, R. (ed.) EUROCRYPT 2005. LNCS, vol. 3494, pp. 114–127. Springer, Heidelberg (2005) CrossRefGoogle Scholar
 46.Yao, A.C.C.: How to generate and exchange secrets (extended abstract). In: 27th FOCS, pp. 162–167. IEEE Computer Society Press, October 1986Google Scholar