Oblivious PRF on Committed Vector Inputs andApplication to Deduplication of Encrypted Data

Jan Camenisch1, Angelo De Caro2, Esha Ghosh3, and Alessandro Sorniotti2

1 DFINITY Zurich Research Lab, Switzerland, jan@dfinity.org2 IBM Research, Zurich, Switzerland, ADC,aso@zurich.ibm.com3 Microsoft Research, Redmond, USA, esha.ghosh@microsoft.com

Abstract. Ensuring secure deduplication of encrypted data is a very ac-tive topic of research because deduplication is effective at reducing stor-age costs. Schemes supporting deduplication of encrypted data that arenot vulnerable to content guessing attacks (such as Message Locked En-cryption) have been proposed recently [Bellare et al. 2013, Li et al. 2015].However in all these schemes, there is a key derivation phase that solelydepends on a short hash of the data and not the data itself. Therefore,a file specific key can be obtained by anyone possessing the hash. Sincehash values are usually not meant to be secret, a desired solution will bea more robust oblivious key generation protocol where file hashes neednot be kept private. Motivated by this use-case, we propose a new prim-itive for oblivious pseudorandom function (OPRF) on committed vec-tor inputs in the universal composable (UC) framework. We formalizethis functionality as FOOPRF, where OOPRF stands for Ownership-basedOblivious PRF. FOOPRF produces a unique random key on input a vectordigest provided the client proves knowledge of a (parametrisable) numberof random positions of the input vector.To construct an efficient OOPRF protocol, we carefully combine a hid-ing vector commitment scheme, a variant of the PRF scheme of Dodis-Yampolskiy [Dodis et al. 2005] and a homomorphic encryption schemeglued together with concrete, efficient instantiations of proofs of knowl-edge. To the best of our knowledge, our work shows for the first timehow these primitives can be combined in a secure, efficient and usefulway. We also propose a new vector commitment scheme with constantsized public parameters but (logn) size witnesses where n is the lengthof the committed vector. This can be of independent interest.

1 Introduction

Cloud storage systems are becoming increasingly popular as a way to reducecosts while increasing availability and flexibility of storage. A promising tech-nology that keeps the cost of cloud storage systems down is data deduplication,which can reduce up to 68 percent storage needs in standard file systems [26].Data deduplication avoids storing multiple copies of the same data at the cloudstorage. For example, if two clients upload the same file, the cloud server detectsthat, stores a single copy of the file and gives access to it to both clients.

However, if two clients locally encrypt their files with their individual keys,completely independent ciphertexts would result even if the underlying plaintextfile is the same, thereby making deduplication impossible. A fundamental chal-lenge in deduplicating encrypted files is the following: how can two mistrustingusers obtain a common encryption key that depends on the content of a filethey both own, without revealing anything about this fact, or about the file’scontent? Schemes that address this problem and are not vulnerable to contentguessing or offline brute-force attacks have been proposed recently [23, 24]. Butall these schemes rely on an oblivious key derivation phase, executed between akey server KS and a client C, whose input solely depends on a short hash of thefile and not on the file itself. In these systems, a file-specific key will not onlybe revealed to the legitimate owners of the file but, crucially, to anyone knowingthe hash of the file. This vulnerability will be particularly disastrous if a mali-cious party (modeling insider threat in cloud storage systems, like a maliciousadministrator) gets hold of a ciphertext and the hash of a file.

Hash values are usually not meant to be secret and are in fact openly used inmultiple contexts, e.g. for checksumming, in standard deduplication protocols,in blockchain systems, and for authentication in Merkle trees. Note that thefundamental issue here is that the key generation solely depends on a shorthash of the file, so getting this short hash is sufficient to get the key for thefile through the oblivious protocol. This concern remains unaddressed even ifdomain separation [23] is used (i.e., domain specific salt is used for generatinghash for the key server), since the oblivious key generation will still depend onthe short hash. A desired solution will be a more robust oblivious key generationprotocol where file hashes need not be kept private. In other words, any smallleakage on a file, should not be sufficient to get the legitimate file specific key.

The obvious first attempt in achieving a robust oblivious key generationprotocol is to add a proof of knowledge step in the key generation phase. Theoblivious key generation phase is usually achieved using Oblivious Pseudoran-dom Function (OPRF). An OPRF [19] is a two-party protocol between Aliceand Bob for securely computing a pseudorandom function fk(x) where Aliceholds the key k and Bob wants to evaluate the function on input x. Despite itssimplicity, OPRF has been shown to be a powerful primitive with application inmultiple contexts [22, 19, 21] and in particular for secure-deduplication [23, 24]in cloud storage systems. Security of OPRF requires that Bob learns only fk(x)while Alice learns nothing from the interaction. However, the OPRF protocolsin the literature [22, 21] can only handle large inputs with a considerable loss inefficiency when Bob is malicious. In particular, none of the OPRF functionalitiesin the literature can handle the following situation: Bob wants to evaluate thefunction on a short representation of his large input, while Alice wants Bob toprove knowledge of his large input, and not the short representation, efficiently,i.e., with communication complexity asymptotically smaller than the length ofhis input. We address this precise question here. Notice that this is exactly thequestion we are asking in the context of oblivious key generation for securededuplication.

2

Is it possible to construct an OPRF protocol that can handle large input from amalicious party with communication complexity that is asymptotically strictly

smaller than the size of the input?

In order to solve the conflict between the requirements expressed in the abovequestion, we envision a protocol where the output of the OPRF still dependssolely on the hash of the input, but that requires a user to prove knowledge of thepre-image of that hash in an efficient way, while retaining privacy. This impliesthat the system should enable efficient and compact proof of knowledge of thepreimage of a hash without revealing anything about the hash or the preimage.

These multi-fold requirements naturally suggest combining a Proof-of-Ownership (PoW) [20] with an OPRF protocol. In a PoW protocol, ownership ofa file is ascertained probabilistically by challenging the user to prove knowledgeof certain blocks of the input file. However, by definition, a PoW scheme requiresa deterministic hash of the file to be maintained at the server, and therefore, isstateful. Moreover, a PoW server, by definition, should be able to decide if twousers possess the same file or not. Therefore, any PoW scheme falls short of ourprivacy goals where we do not want to reveal any information about the file inthe proof-of-knowledge phase.

1.1 Our Result

We answer the question in the previous section in the affirmative by proposinga new OPRF primitive on committed vector inputs in the universal composable(UC) framework. We formalize this functionality as FOOPRF where OOPRF standsfor Ownership-based Oblivious PRF. FOOPRF produces a unique random key onan input vector digest, only if the client proves knowledge of a (parametrisable)number of random positions of the input vector. By carefully tuning the numberof positions to challenge the client on, bandwidth consumption can be reducedwhile ensuring that a malicious client can only cheat with negligible probability.We discuss how this tunable parameter should be set and how it affects thesoundness error of the protocol. We further describe how to make our protocolmore efficient in the weaker stand-alone security model.

Threat Model. The general setting of secure deduplication consists of three par-ties: a storage server (SS), a set of clients (Ci) who store their encrypted fileson SS and a key server (KS) who aids the deduplication process by assisting theclient to generate encryption keys that are unique for each file to be encrypted.In the first phase, the clients interact with the KS to get a key which is usedto encrypt the input file such that the resulting ciphertext can be deduplicated.This is obtained as a result of the fact that a file encrypted with the same keywill always produce the same ciphertext.

We will focus on the key generation phase that is executed between the KSand a client Ci. The clients are malicious and the KS is honest-but-curious inour threat model (we discuss how to tolerate a malicious KS in Section 4).This is a threat model that captures a wide range of realistic settings where a

3

malicious client is in possession of ciphertexts (modeling an attacker hacking intothe SS, or a malicious administrator of the SS with access to ciphertexts or anintelligence agency coercing the SS into releasing ciphertexts) and hashes of thefiles produced by an honest client. The malicious client can then try to obtain thedecryption key for the file by fooling the KS. The KS typically models a cloudservice provider that has no incentive in generating weak or incorrect keys forthe files. A more realistic scenario is where the KS may stealthily deviate fromthe protocol to learn information about the client files. But we protect againstany such information leakage. In other words, we protect the input privacy ofthe clients even against a malicious KS.

It is also easy to detect (with high probability) if KS is misbehaving ingenerating the key by sending the same file twice and observing if the same keyis generated. Since KS generates the key obliviously, it will not be able to detectthat it has received the same file. So, if KS is not faithfully generating the keys,with very high probability it will end up generating different keys and thus riskdetection.

UC Security. With the increasing popularity of cloud platforms, significant effortwent into developing customized solutions for various problems related to thesecurity and privacy of outsourced data and computations. These protocols arenot very modular by design and it is extremely challenging to compose themto achieve multiple security goals at once. In this work, we take an importantstep towards modular design by formalizing the security requirements in theUniversally Composable (UC) framework which provides composable securityguarantees.

Efficiency. Designing UC-secure protocols introduce some performance over-heads. However, it is often trivial to optimize a UC-secure protocol (making itonly secure in weaker models), whereas it is often extremely complex (if not out-right infeasible) to demonstrate UC-security for a protocol that is only secure inweaker models. For achieving stand-alone security in our protocol, it is sufficientto instantiate all the zero-knowledge proofs of knowledge in our protocol withgeneralized Schnorr proofs and using the Fiat-Shamir heuristic, which are veryefficient in practice. We discuss the concrete efficiency of the stand-alone versionof our protocol in detail in Appendix F.

Ideal Functionality. A naive attempt to define the ideal functionality, FOOPRF,is the following. A (possibly malicious) client C hands in its entire input fileto the functionality. If FOOPRF has not seen this file before, it generates a freshrandom key, stores it with the file, and returns that key to the client. Otherwise,FOOPRF just returns the key it has stored for that file. Any realization of such afunctionality would require communication between C and KS to be linear inlength of C’s input. This is because the simulator will need to extract on-line,the entire file from a malicious client, to be able to input it to the functionality.This defeats the compactness requirement we are looking for. To avoid this,we could let FOOPRF remember some succinct representation of each file and

4

then allow the simulator to input just that representation and get the key fromthe functionality. However, this would let malicious clients get away safely withknowing the succinct representation only rather than the full file. This is preciselythe security issue we are trying to overcome!

We envision a protocol where a client will just have to commit to the wholefile (e.g., with a vector commitment) and then to prove that it knows sufficientlymany blocks, it, can open sufficiently many random positions of the vector com-mitment. Vector commitments [14] allow a party to commit to a vector of mes-sages in such a way that it can later provide a witness that proves that x[i] isindeed the i-th value in the committed vector x.

To allow for such communication-efficient protocol realizations, we need tomodel inside the functionality, that a file is only provided partially. We do thisby allowing the simulator to obtain keys from FOOPRF on input a succinct repre-sentation of a file together with sufficiently many blocks of the file, where “suffi-ciently many” is defined in terms of a security parameter t. FOOPRF will choose afresh key for each representation of a file, store the key, the representation of thefile and the provided blocks. When FOOPRF sees the same representation again,it will check whether the blocks on file for that representation are consistentwith the newly provided blocks. The representation and blocks provided by thesimulator will also have to be consistent with the full file input to FOOPRF byhonest clients. So, FOOPRF will have to compute its own representation for fullfile input (it cannot ask the simulator as then the input of the honest clientwould no longer remain secret as we require). Thus, we need to provide FOOPRF

with a function (vector commit) to compute this representation.Notice that the guarantee that FOOPRF provides is that, when the input files

are same, the client will get the same key. But the client cannot get the keyby knowing a short representation for a large file; it has to show that it knows“sufficiently many” blocks of the file. This is significantly different from Proof-of-Retrievability [28] schemes where the guarantee is that the entire outsourcedfile is saved at all times (at the server).

Protocol. To construct a protocol that securely realizes FOOPRF, we combinehiding vector commitments [14], a hiding and binding commitment scheme [27], avariant of the PRF scheme of Dodis-Yampolskiy [18, 22, 15], and a homomorphicencryption scheme [17, 9] together with concrete, efficient instantiations of proofsof knowledge. At a high level, the construction is designed as follows.

The PRF is obliviously evaluated on a succinct deterministic commitment toC’s input x, say s. We implement the oblivious PRF by leveraging the homo-morphism of the encryption scheme. Now recall that C has to prove knowledgeof random positions in the preimage of s efficiently and wants to preserve theconfidentiality of its input. This can be addressed by using a randomized/hidingvector commitment. Still, the PRF needs to be evaluated on s, to ensure thatthe protocol always returns the same output given the same input. We providean efficient proof of knowledge implementation that binds the randomized vectorcommitment with a commitment to s. Our protocol ensures that all these compo-nents can inter-operate efficiently. To the best of our knowledge, our work shows

5

for the first time how these primitives can be combined in a secure, efficient anduseful way.

As a subroutine of our protocol, we construct a new vector commitment (VC)scheme with constant-sized public parameters and log n size witnesses where nis the length of the committed vector. The scheme is based on the Merkle HashTree (MHT) based accumulator construction presented in [4]. Very recently [3]proposed a non-hiding MHT based VC with efficient batching of witnesses ofposition binding in groups of unknown order. Their batch openings only saves(asymptotically) when a few of the positions in the committed vector are setand all this positions are opened in a batch. This is incompatible with ourrequirement where a few positions are opened selectively. Moreover, their proofsrequire very expensive group operations in groups of unknown order.

1.2 Organization

The rest of the paper is organized as follows. In Section 2, we describe the cryp-tographic primitives. In Section 3 we describe the ideal functionality FOOPRF andin Section 4 we give a secure realization of FOOPRF. One of the main buildingblocks of the protocol is vector commitment. In Section 5, we give an instan-tiation of VC and defer the second instantiation to Appendix D. Throughoutthe protocol and the VC implementations we use abstract PoK notation for theproofs of knowledge. In the appendix, we give the concrete implementations ofall the PoK’s (E), and the concrete efficiency analysis of our protocol (F).

2 Preliminaries

In this section we discuss the cryptographic primitives used in our protocol.

2.1 Proof Systems (PK)

By PoK(w) : statement(w) we denote a generic interactive zero-knowledgeproof protocol of knowledge of a witness w such that the statement(w) is true.A PoK system must fulfil completeness, zero-knowledge and simulation-sound ex-tractability. A PoK system consists of the two protocols: PK.Setup,PK.Prove. Oninput a security parameter 1λ, PK.Setup(1λ) outputs (parPK). PK.Prove(parPK,·) is an interactive protocol between prover and a verifier that statement(w) istrue. The additional input the prover holds is the witness w for the statement.Simulation-sound extractability for a PoK system requires the existence of anefficient algorithm SE that outputs (parPK, tds, tde) such that parPK is identi-cally distributed to the parPK generated by PK.Setup (tde is the extraction trap-door and tds is the simulation trapdoor). When we need witnesses to be online-extractable, we make this explicit by writing PoK(w1, w2) : statement(w1, w2)the proof of witnesses w1 and w2, where w1 can be extracted.

For concrete realizations of PoK’s, i.e., generalized Schnorr-signatureproofs [8], we will use notation [10] such as GSPK(a, b, c) : y = gahb∧ y = gahc.

6

Whenever a witness needs to be on-line extractable, we will use verifiable encryp-tion under a public key contained in the CRS. To allow for a proper assessmentof our protocols, we will always spell these encryptions out (so there will not beany underlined witnesses in this notation). Finally, to make the 3-move general-ized Schnorr-signature proofs concurrent zero-knowledge and simulations sound,one can use any of the standard generic techniques [16, 29], typically resultingin a 4-move protocol.

2.2 Commitment Scheme (CS)

We will instantiate CS with Pedersen commitment which satisfies correctness,hiding and binding properties. In addition to that, Pedersen commitments are ho-momorphic. We instantiate the commitment scheme in a composite order groupto be compatible with the other primitives that we will be using [4].CS.Setup(1λ): The setup algorithm picks two λ bit safe primes p, q such thatgcd(p− 1, q− 1, 7) = 1 and sets N = pq and sets message space and randomnessspace respectively as: M = Z∗N ,R = Z∗N

Then, the algorithm picks a prime ρ such that ρ = 2kN+1 where k is a smallprime. Let G = 〈G〉 = 〈H〉 be order-N subgroup of the group Z∗ρ and G and Hare two random generators of G, such that logH G is unknown. Note that G isa cyclic subgroup of Z∗ρ of order N and all the operations will happen moduloρ (i.e., reduced mod N in the exponent). Finally, the algorithm outputs publicparameters par := (ρ,N,G,G,H,M,R).CS.Commit(par,m, r): Compute com← GmHr mod ρ. Output (com, open = r)CS.Verify(par, com,m, open): Output 1 if com← GmHopen mod ρ, 0 otherwise.

Theorem 1 ([27]). The commitment scheme CS is information-theoreticallyhiding and binding under the Discrete Log assumption.

2.3 Pseudorandom Function (PRF)

We will use the PRF scheme proposed in [22, 15] which is a variant of the PRFscheme of Dodis-Yampolskiy [18] based on the Boneh-Boyen unpredictable func-tion [2], instantiated on a composite-order group instead of a prime-order group.This PRF was proven to be secure for a domain of arbitrary size based solely onsubgroup hiding in [15]. The proof for the original PRF instantiated with prime-order groups only allows for a domain which is polynomial-sized in the securityparameter. Notice that, for our application, it is crucial to have arbitrary sizedomain in order to disallow offline brute-force attack by a honest-but-curiousKS. Here we recall the PRF definition and its security [15].PRF.Setup(1λ): On input the security parameter λ, the setup algorithm picks twoλ-bit safe primes p, q and sets N = pq. Then, it generates groups (N,G, (G1,G2)) ← G(1λ), where G1,G2 are subgroups of G.4 Reasonable candidates for

4 Notice that G1,G2 are not explicitly used in the construction, but are required fromthe security proof.

7

group G are composite-order elliptic curve groups without efficient pairings orthe target group of a composite-order bilinear group. Finally, the setup algorithmpicks g ← G, sets the D = K← Z∗N ,R← G, and output par = (N,G, g,D,K,R).PRF.KeyGen(1λ, par): On input the security and public parameters λ, par, thekey generation algorithm picks k ← K and output k.PRF.Evaluate(par, k,m): On input the public parameters par, key k ∈ K and inputm ∈ D, the evaluation algorithm does the following: If gcd((k+m), N) 6= 1, then

output ⊥, else output g1

(k+m)mod N ∈ R.

Theorem 2 ([15]). For all λ ∈ N, if subgroup hiding holds with respect to Gfor its subgroups G1 and G2, if N = pq for distinct primes p, q ∈ Ω(2poly(λ), andif G1 is a cyclic group of prime order, then the function family defined above isa pseudorandom function family.

2.4 Homomorphic Encryption Scheme (HES)

Here we present the Projective Paillier Encryption scheme [17, 9]. This schemepreserves the homomorphic properties of Paillier encryption; however, unlike theoriginal Paillier scheme, the scheme has a dense set of public-keys.HES.Setup(1λ): On input the security parameter λ, the setup algorithm picks

two λ bit safe primes p, q and set N = pq.5 Then, generates a random elementg′ ∈ (ZN2) and sets g := g′

2Nand h := (1 + N mod N2) ∈ Z∗N2 , a special

element of order N . Finally, the algorithm outputs par := (N, g, h).HES.KeyGen(par): On input the public parameters par, the key generation algo-

rithm picks a random t ∈ [N/4] and computes epk ← gt mod N2. Finally, thealgorithm outputs (epk, esk := t).HES.Enc(epk,m): On input the public key epk and message m, the encryption

algorithm picks a random r ∈ [N/4] and computes u← gr mod N2; v← epkrhm

mod N2. Finally, the algorithm outputs ciphertext ct := (u, v). We will sometimeuse the notation [m] to mean the encryption of m.HES.Dec(esk, ct): On input the secret key esk and ciphertext ct, the decryp-

tion algorithm computes m′ ← v/uesk mod N2. If m′ is of the form (1 + Nmmod N2) for some n ∈ [N ], output m. Else output ⊥.

Theorem 3 ([17]). Under the Decision Composite Residuosity assumption, theProjective Paillier encryption scheme is semantically secure.

2.5 Vector commitments (VC)

Vector commitments (VC) [14] allow one to commit to a vector of messages insuch a way that it is later possible to open the commitment to one of the mes-sages i.e, provide a witness that proves that xi is indeed the ith value in thecommitted vector x. The size of the commitment and the opening are inde-pendent of the length of the vector. We relax the efficiency requirement of VC

5 Algesheimer et al. describe how to generate such an N distributedly [1].

8

in our definition. Let n be the length of the committed vector. We require thesize of the commitment to be independent from n, but the size of the openingshould be asymptotically smaller than n, i.e., o(n). A VC can either be non-hiding/deterministic (detVC) or hiding/randomized (randVC)6. For a detVC theonly security requirement is binding. Informally, this property requires that oncean adversary comes up with a VC, it should not be able to prove two differentvalues with respect to the same position for that VC. For a randVC, the hiding isan additional security requirement. Informally, this requirement states that theVC should conceal the committed vector, i.e., an adversary should not be ableto distinguish if a VC was created for a vector x or a vector y, where x 6= y.For the formal definition of binding, refer to [14]. Hiding can be defined as forstandard commitment.

Here we recall the primitives for a VC. Most of the inputs to the algorithmsare common for a randVC and a detVC. The inputs that are needed exclusivelyfor a randVC are highlighted.

VC.Setup(1λ, n) : On input security parameter 1λ and an upper bound n onthe size of the vector, generate the parameters of commitment scheme par ,which include a description of message space M and a description of random-ness space R. VC.Commit(par,x, r): On input public parameters par, a vector

x ∈ Ml, (l ≤ n) and r ∈ R, the algorithm outputs a commitment com to x.VC.Prove(par, i,x, r): On input public parameters par, position index i, vectorx, and r ∈ R, the algorithm generates a witness w for xi and outputs (w, xi).VC.Verify(par, i, com, w, x): On input public parameters par, position index i,commitment com and witness w for x, the algorithm outputs 1 if w is a validwitness for x being at position i and 0 otherwise.

Below we define two new algorithms (VC.RandCommitment,VC.RandWitness).Informally, VC.RandCommitment allows to update a detVC to a randVC andVC.RandWitness allows to update a detVC witness to a randVC witness.

VC.RandCommitment(par, com, r): On input public parameters par, a non-hiding

commitment com and r ∈ R, outputs a randVC com′.

VC.RandWitness(par, com, i, r, w): On input public parameters par, a detVC wit-ness w, a non-hiding commitment com and r ∈ R, outputs a randVC witnessw′.

UC Security: In Appendix A.1, we give a brief overview of UC security anddirect the readers to [7, 11, 12] for more details.

6 We will use the following terms interchangeably in the context of VC: non-hidingand deterministic, hiding and randomized.

9

3 Ideal Functionality for Ownership-based ObliviousPRF (OOPRF)

In this section we describe the ideal functionality FOOPRF. As a warm-up, westart from a bandwidth inefficient version of FOOPRF denoted as FBI−OOPRF.The functionality is designed as follows:1. FBI−OOPRF receives input x from client Ci.2. FBI−OOPRF maintains a table to store the tuples (x, rx) where x is the input

from Ci and rx is the unique random key that the functionality picks for x.3. For input x from Ci, if x is in the table, the functionality returns the corre-

sponding rx to Ci. Otherwise, it picks a fresh random key rx, stores (x, rx)in its table and returns rx to Ci.Since the client has to hand in the entire set of blocks of a file7 of length

n to the functionality, any protocol that will achieve this functionality will beinefficient in terms of communication bandwidth. This is because the protocolwill have to ensure that the entire file can be on-line extracted from a maliciousclient, which will amount to verifiably encrypting each file block. To overcomethis, we are interested in a protocol where a client will just have to commit tothe whole file (e.g., with a vector commitment) and then to prove that it knowssufficiently many blocks, i.e., can open sufficiently many random positions of thevector commitment. To allow for such a construction, we need to model insidethe functionality, that a file is only provided partially. To this end, we will have toallow the simulator to obtain keys from the functionality on input a representa-tion of a file together with sufficiently many blocks of the file, where “sufficientlymany” is defined in terms of a security parameter t. The functionality will thenchoose a fresh key for each representation of a file, store the key, the represen-tation of the file and the provided blocks. Furthermore, when in the future, thefunctionality sees the same representation again, it will check whether the blockson file for that representation are consistent with the newly provided blocks. Ofcourse, the representation and blocks provided by the simulator will also haveto be consistent with the full file input to the functionality by honest clients.To this end, the functionality will have to compute its own representation (itcannot ask the simulator as then the input of the client would no longer remainsecret as we require). Thus, we need to provide the functionality with a functionto compute this representation. Thiss could either done by asking the simulatorfor this function in the setup phase or by parameterizing the functionality withthis function. We chose the latter. Of course, the functionality will also have toenforce consistency between the blocks for the representations it computes itselfand those it receives from the adversary/simulator.

Note that in FOOPRF, both honest and malicious clients invoke the function-ality with file x. But, in case of malicious clients, the functionality generatesthe random key based on the input from the simulator and its internal state.The simulator’s input is checked only against the stored internal state of thefunctionality, and not with respect to the input x with which a malicious client

7 we use the word file and vector interchangeably

10

invokes the functionality. Thus, FOOPRF does not require the entire file to beon-line extracted from a malicious client.

Functionality FOOPRF (Parameterized with detVC.Commit(par))

Setup: Upon receiving (Setup, sid) from KS:1. Send (Setup, sid) to Sim and wait for (Setup, sid, ok) from Sim.2. Initialize an empty table Tsid.3. Store (sid,Tsid).4. Output (Setup, sid) to KS.

Evaluate: Upon receiving input (Evaluate, sid, qid,x) from Ci:1. Proceed only if (sid,Tsid) are stored.

If Ci is honest: (a) Send (Evaluate, sid, qid, startEvaluate) to Sim and waitfor (Evaluate, sid, qid, startEvaluateok) from Sim.

(b) Compute s← detVC.Commit(x).(c) If (s,x′, r) ∈ Tsid, for some x′ and r, do the following:

i. If the row corresponding to s contains x′ 6= x, set variable out←⊥. Otherwise, out← r.

ii. Output (Evaluate, sid, qid, out) to Ci.(d) Else, pick r ← R, insert (s,x, r) in Tsid and output

(Evaluate, sid, qid, r) to Ci.If Ci is malicious: (a) Send (Evaluate, sid, qid, startEvaluate) to Sim and

wait for (Evaluate, sid, qid, startEvaluateok, s, x[i1], . . . , x[it]) from Sim.(b) If (s,x′, r) ∈ Tsid, for some x′ and r, do the following:

i. If x′ contains x′[i1], . . . , x′[it] for which the receivedx[i1], . . . , x[it] are unequal at least in one position, set out← ⊥.

ii. Else, update x′ on positions i1 . . . , it with values x[i1], . . . , x[it],respectively, and set out← r.

iii. Output (Evaluate, sid, qid, out) to Ci.(c) Else, pick r ←R, insert (s, (x[i1], . . . , x[it]), r) in Tsid.(d) output (Evaluate, sid, qid, r) to Ci.

4 Secure realization of FOOPRF

In this section we describe a protocol ΠOOPRF that securely realizes functionalityFOOPRF. We present the construction here and defer the proof of security toAppendix B.

4.1 Protocol ΠOOPRF

First we give the high level intuition behind our construction. The protocol isdesigned in the CRS model, so each party receives the public parameters of thescheme from a trusted party. KS additionally picks a key for a PRF. The protocolhas two major building blocks, namely VC and PRF. Recall that the requirementsfor the key that KS will generate for Ci’s input file were (1) the key should be

11

random (2) it should be unique for a file and (3) the key should not be publiclycomputable. All these properties are provided if the file key is a PRF evaluationon a succinct deterministic and binding vector commitment to its input file x.Let us denote this deterministic vector commitment as s.

The PRF evaluation has to be carried out obliviously as KS should learnno information about Ci’s input. We implement the oblivious PRF evaluationprotocol between KS (holding k) and Ci (holding s) for the PRF described inSection 2.3. To design this part of the protocol (Steps 7-13) we leverage thehomomorphic encryption scheme that we described in Section 2.4. In order totolerate malicious Ci’s, we require that Ci commits to its input s, i.e., computecom = CS.Commit(s, r) (where r is the randomness used to compute com using astandard commitment scheme as described in Section 2.2) and proves knowledgeof its opening, r to KS before KS engages in computing the PRF (PoKπc2).

But committing to s is not sufficient; Ci has to prove knowledge of thepreimage of s efficiently. This is where the properties of VC can be leveraged.A VC lets Ci prove knowledge of some random positions of the preimage. Weutilize this property as follows: we let KS challenge Ci to prove knowledge of trandom positions of its input, where t is much less than the length of x. Ci cando this efficiently. The question of how to decide on the parameter t dependson the soundness error the protocol is ready to accept. We discuss this in moredetail following the construction.

Notice however that Ci does not want to reveal any information about x toKS. A hiding (or randomized) VC scheme tackles this issue but a hiding vectorcommitment cannot be used directly as the PRF input. This is because, forthe same input x, if the PRF is computed on two randomized VC’s for x, thenit will generate different outputs. So we require that PRF is computed on adeterministic vector commitment to the input vector. Let s′ be a randomizedvector commitment to Ci’s input x.

We solve problem above by having Ci send both com and s′ and a proof thatensures that com and s′ are appropriately related, namely that they both referto the same deterministic vector commitment s.

Armed with this intuition, we are ready to give full construction of the pro-tocol. In Appendix E we give the full implementations of the PoK’s used here.

Setup: On input of (Setup, sid), the key server KS executes:1. Receive (par) on the FPRF.Setup,VC.Setup,CS.Setup,PK.Setup,HES.Setup,sp

CRS interface.2

2. Run k ← PRF.KeyGen(1λ, par) and store k.3. Output (Setup, sid)

Evaluate: On input (Evaluate, sid, qid,x = (x1, . . . , xn) ∈ par.Mn) to client Ci,the following protocol is executed between Ci and KS:1. Receive (par) on the FPRF.Setup,VC.Setup,CS.Setup,PK.Setup,HES.Setup,sp

CRS interface.2. Ci picks a random r1 ← par.R and computes s← VC.Commit(par,x) and

s′ ← VC.RandCommitment(par, s, r1).Additionally, Ci does the following:(a) Pick a random r2 ← par.R

12

(b) Compute com← CS.Commit(par, s, r2)(c) Then, Ci generates the following proof of knowledge

πc00 := PoK(s, r2) : com = CS.Commit(par, s, r2)

(d) Additionally, Ci computes the following proof of knowledge

πc01 := PoK

(s, r1, r2) : com = CS.Commit(par, s, r2) ∧

s′ = VC.RandCommitment(par, s, r1)

and sends (s′, com, πc00, πc01) to KS.3. KS verifies πc00, πc01 if the verifications pass through, then it proceeds to

the next step.4. KS picks a set of indices I = j1, . . . , jt from [1, n] randomly and sends

them to Ci5. For each challenged index j ∈ I, Ci computes

(w′j , xj)← VC.Prove(par, j,x) ,

(wj)← VC.RandWitness(par, s, j, r1, w′j)

and generates the following proof of knowledge

πj = PoK

(wj , xj) : 1 = VC.Verify(par, j, s′, wj , xj)

Let πc1 = πj |j ∈ I. Ci sends πc1 back to KS.6. KS verifies πc1 and if the verification passes, KS proceeds to the next step.7. KS picks (epk, esk)← HES.KeyGen(par), computes [k]← HES.Enc(epk, k)

and sends epk, [k] to Ci.8. Then Ci picks r3 ∈ par.R and computes

ct← ([k][s])r3 ,

where [s]← HES.Enc(epk, s)9. Next, Ci generates the following proof of knowledge

πc2 = PoK

(s, r2, r3) : com = CS.Commit(par, s, r2) ∧

ct = ([k][s])r3

Ci sends ct, πc2 to KS.10. KS verifies πc2 and if the verifications succeed, KS continues.11. KS computes V ← HES.Dec(esk, ct)12. Then KS computes K′ ← PRF.Evaluate(par, k, V ) and sends it to Ci.

13. If K′ = ⊥, output ⊥. Otherwise compute K ← K′(r3 mod par.N)and

output K.8

13

Choosing parameter t: Parameter t is a tuning parameter that trades commu-nication bandwidth for efficiency. In order to achieve high confidence that theprover (i.e., the client) owns the entire file, t has to be adjusted accordingly.Intuitively, for higher confidence that the prover possesses the entire file, theverifier can set t to a large value. To minimize soundness error, a file can beerasure coded first and then a VC commitment can be computed on the erasurecoded file. If the erasure code is resilient to erasures of up to α fraction of thebits and ε is the desired soundness bound, then t should be picked as follows:t should be the smallest integer such that (1− α)

t< ε. [20] discusses in detail

how to tune t. Even though this scheme achieves a high level of soundness, gooderasure codes for very large files are expensive to compute. In [20], the authorspropose a pairwise hash function with public parameters that can be used tohash the input file down to a constant size and then run VC on it. This schemeachieves a weaker level of security than the erasure coded version.

Discussion on tolerating malicious KS. The functionality is independent ofwhether or not KS is honest-but-curious or not. This only matters for the im-plementation and to what extent it realizes the functionality, i.e., our protocolΠOOPRF realizes the functionality under the assumption that KS is honest orhonest-but-curious. Notice that, in the functionality, the key server KS does notlearn any information about Ci’s input by design. So the functionality protectsthe privacy of Ci’s input even from a malicious KS.

The choice of making KS honest-but-curious merits further discussion. InΠOOPRF, KS can be made to commit to its PRF key and to return a proof ofknowledge that it has computed the OPRF correctly as Jarecki and Liu do [22].However, this does not guarantee that KS will pick a strong key or keep that keysecret both of which would defeat the purpose of the protocol. Thus, to addressa fully malicious KS, we need to ensure that KS has chosen its PRF key bysampling randomly the desired key space. We notice that this is not addressedby Jarecki et al. [22] either, even though they claim to handle fully malicious KS(i.e., PRF evaluator). Handling this aspect is left as future work.

5 Merkle Tree-based Vector Commitment

In this section we present a new VC construction scheme based on the MerkleHash Tree (MHT) based accumulator construction presented in [4]. Unlike [4],we do not need to hide the index position of the leaf. This allows for someefficiency enhancement since the prover does not need to hide if a node is theleft child or the right child of its parent. We first provide a detVC construction

2 Note that par = (parPRF, parVC, parCS, parPK, parHES), but by the choice of our schemes,they all work in the same setting with shared parameters. To simplify notation, whenthe primitive used is clear from the context, we will just refer to par and not to thespecific parameters of that primitive.

8 It is clear that the randomness r3 cancels out only with algebraic PRF’s with appro-priate codomains as the one chosen in our construction.

14

and then describe algorithms RandCommitment,RandWitness to convert it torandVC. Notice that in this VC construction, the public parameter is constant-sized as opposed to the CDH and RSA based VC schemes proposed in [14]. Thedrawback is that the proofs have length logarithmic in n as opposed to constant.

5.1 detVC and randVC Constructions

VC.Setup(1λ, n) :On input security parameter 1λ and an upper bound n, the

algorithm invokes CS.Setup(1λ). Let CS.Setup(1λ) return (ρ,N,G,G,H,M,R).This algorithm appends the tuple with the collision-resistant hash function H :(ZN )

2 → ZN defined as follows [4]: H(x, y) = x7 + 3y7 mod N and return it aspar. For further details on the hash function, see [4].

VC.Commit(par,x): On input public parameters par and input x = x1, . . . , xn,the algorithm, using H(·, ·), recursively builds a Merkle Hash Tree on x (asdescribed in Section A). (If n is not a power of two, insert “dummy” elementsinto x until n is a perfect power of 2.) Let MR be the root of the MHT. Thealgorithm outputs commitment com = MR.

VC.Prove(par, i,x): On input public parameters par, position i and input x =x1, . . . , xn, the algorithm does the following: Let us denote the node values alongthe path from the root node with value MR, to the leaf node, with value x[i],in the MHT as: P = (p0, p1, . . . , pd). Note that p0 = MR and pd = x[i]. LetPS = (p′1, . . . , p

′d) be the sibling path of P (note that p0 has no sibling). Then,

the algorithm computes PS and outputs witness (w = PS , xi).VC.Verify(par, i, com, w, x): On input public parameters par, position i, commit-

ment com = MR, witness (w, x), the algorithm parses w as PS = (p′1, . . . , p′d)

and sets pd = x. For each j = d, . . . 1, the algorithm recursively computes theinternal nodes by hashing the left and right child. Let p0 = H(p1, p

′1) (if p1 is the

left sibling, H(p′1, p1) otherwise.). This algorithm checks if MR = p0. It outputs1 if the equality holds, 0 otherwise.

VC.RandCommitment(par, com, r): On input public parameters par, non-hidingvector commitment com = MR and randomness r ∈ R, the algorithm invokesCS.Commit(par,MR, r). Let CS.Commit(par,MR, r) return (comMR, openMR).Output com′ = comMR.

VC.RandWitness(par, com, i, r, w): On input public parameters par, non-hidingvector commitment com = MR, position i, randomness r ∈ R and a deter-ministic witness w, the algorithm does the following: 1) parses w as PS =((p′1, . . . , p

′d), v) 2) computes (comMR, openMR) = CS.Commit(par,MR, r) 3) com-

putes w′ = (PS , v, comMR, openMR) and outputs w′.

VC.Verify for randomized witness: the only changes in the verification algo-rithm are the following: 1) parse w as (PS = (p′1, . . . , p

′d), xi, comMR, openMR) 2)

in the last step instead of checking if MR = p0, check if CS.Verify(par, comMR,MR,openMR) = 1. The algorithm will output 1 if the equality holds, 0 otherwise.

15

References

1. Algesheimer, J., Camenisch, J., Shoup, V.: Efficient computation modulo a sharedsecret with application to the generation of shared safe-prime products. In: Yung,M. (ed.) CRYPTO 2002. LNCS, vol. 2442, pp. 417–432. Springer, Heidelberg (Aug2002)

2. Boneh, D., Boyen, X.: Short signatures without random oracles. In: Cachin, C.,Camenisch, J. (eds.) EUROCRYPT 2004. LNCS, vol. 3027, pp. 56–73. Springer,Heidelberg (May 2004)

3. Boneh, D., Bunz, B., Fisch, B.: Batching techniques for accumulators with ap-plications to iops and stateless blockchains. Cryptology ePrint Archive, Report2018/1188 (2018)

4. Boneh, D., Corrigan-Gibbs, H.: Bivariate polynomials modulo composites and theirapplications. In: Sarkar, P., Iwata, T. (eds.) ASIACRYPT 2014, Part I. LNCS, vol.8873, pp. 42–62. Springer, Heidelberg (Dec 2014)

5. Bootle, J., Cerulli, A., Chaidos, P., Groth, J.: Efficient Zero-Knowledge Proof Sys-tems, pp. 1–31. Springer International Publishing, Cham (2016)

6. Boschini, C., Camenisch, J., Neven, G.: Relaxing lattice-based signatures for shortproofs (2017), manuscript

7. Camenisch, J., Dubovitskaya, M., Rial, A.: UC commitments for modular proto-col design and applications to revocation and attribute tokens. In: Robshaw, M.,Katz, J. (eds.) CRYPTO 2016, Part III. LNCS, vol. 9816, pp. 208–239. Springer,Heidelberg (Aug 2016)

8. Camenisch, J., Kiayias, A., Yung, M.: On the portability of generalized Schnorrproofs. In: Joux, A. (ed.) EUROCRYPT 2009. LNCS, vol. 5479, pp. 425–442.Springer, Heidelberg (Apr 2009)

9. Camenisch, J., Shoup, V.: Practical verifiable encryption and decryption of discretelogarithms. In: Boneh, D. (ed.) CRYPTO 2003. LNCS, vol. 2729, pp. 126–144.Springer, Heidelberg (Aug 2003)

10. Camenisch, J., Stadler, M.: Efficient group signature schemes for large groups(extended abstract). In: Kaliski Jr., B.S. (ed.) CRYPTO’97. LNCS, vol. 1294, pp.410–424. Springer, Heidelberg (Aug 1997)

11. Canetti, R.: Universally composable security: A new paradigm for cryptographicprotocols. In: 42nd FOCS. pp. 136–145. IEEE Computer Society Press (Oct 2001)

12. Canetti, R.: Universally composable signatures, certification and au-thentication. Cryptology ePrint Archive, Report 2003/239 (2003),http://eprint.iacr.org/2003/239

13. Canetti, R.: Universally composable signature, certification, and authentication.In: CSFW. pp. 219–. CSFW ’04, IEEE Computer Society, Washington, DC, USA(2004), https://doi.org/10.1109/CSFW.2004.24

14. Catalano, D., Fiore, D.: Vector commitments and their applications. In: Kurosawa,K., Hanaoka, G. (eds.) PKC 2013. LNCS, vol. 7778, pp. 55–72. Springer, Heidelberg(Feb / Mar 2013)

15. Chase, M., Meiklejohn, S.: Deja Q: Using dual systems to revisit q-type assump-tions. In: Nguyen, P.Q., Oswald, E. (eds.) EUROCRYPT 2014. LNCS, vol. 8441,pp. 622–639. Springer, Heidelberg (May 2014)

16. Damgard, I.: Efficient concurrent zero-knowledge in the auxiliary string model. In:Preneel, B. (ed.) EUROCRYPT 2000. LNCS, vol. 1807, pp. 418–430. Springer,Heidelberg (May 2000)

16

17. Dodis, Y., Shoup, V., Walfish, S.: Efficient constructions of composable commit-ments and zero-knowledge proofs. In: Wagner, D. (ed.) CRYPTO 2008. LNCS, vol.5157, pp. 515–535. Springer, Heidelberg (Aug 2008)

18. Dodis, Y., Yampolskiy, A.: A verifiable random function with short proofs andkeys. In: Vaudenay, S. (ed.) PKC 2005. LNCS, vol. 3386, pp. 416–431. Springer,Heidelberg (Jan 2005)

19. Freedman, M.J., Ishai, Y., Pinkas, B., Reingold, O.: Keyword search and obliviouspseudorandom functions. In: Kilian, J. (ed.) TCC 2005. LNCS, vol. 3378, pp. 303–324. Springer, Heidelberg (Feb 2005)

20. Halevi, S., Harnik, D., Pinkas, B., Shulman-Peleg, A.: Proofs of ownership in remotestorage systems. In: Chen, Y., Danezis, G., Shmatikov, V. (eds.) ACM CCS 11.pp. 491–500. ACM Press (Oct 2011)

21. Jarecki, S., Kiayias, A., Krawczyk, H., Xu, J.: Highly-efficient and composablepassword-protected secret sharing (or: How to protect your bitcoin wallet online).In: (EuroS&P). pp. 276–291 (March 2016)

22. Jarecki, S., Liu, X.: Efficient oblivious pseudorandom function with applicationsto adaptive OT and secure computation of set intersection. In: Reingold, O. (ed.)TCC 2009. LNCS, vol. 5444, pp. 577–594. Springer, Heidelberg (Mar 2009)

23. Keelveedhi, S., Bellare, M., Ristenpart, T.: Dupless: Server-aided encryp-tion for deduplicated storage. In: USENIX Security 13. pp. 179–194.USENIX (2013), https://www.usenix.org/conference/usenixsecurity13/technical-sessions/presentation/bellare

24. Liu, J., Asokan, N., Pinkas, B.: Secure deduplication of encrypted data withoutadditional independent servers. In: Ray, I., Li, N., Kruegel:, C. (eds.) ACM CCS15. pp. 874–885. ACM Press (Oct 2015)

25. Merkle, R.C.: A certified digital signature. In: Brassard, G. (ed.) CRYPTO’89.LNCS, vol. 435, pp. 218–238. Springer, Heidelberg (Aug 1990)

26. Meyer, D.T., Bolosky, W.J.: A study of practical deduplication. Trans. Storage7(4), 14:1–14:20 (Feb 2012), http://doi.acm.org/10.1145/2078861.2078864

27. Pedersen, T.P.: Non-interactive and information-theoretic secure verifiable secretsharing. In: Feigenbaum, J. (ed.) CRYPTO’91. LNCS, vol. 576, pp. 129–140.Springer, Heidelberg (Aug 1992)

28. Shacham, H., Waters, B.: Compact proofs of retrievability. In: Pieprzyk, J. (ed.)ASIACRYPT 2008. LNCS, vol. 5350, pp. 90–107. Springer, Heidelberg (Dec 2008)

29. Visconti, I.: Efficient zero knowledge on the Internet. In: Bugliesi, M., Preneel, B.,Sassone, V., Wegener, I. (eds.) ICALP 2006, Part II. LNCS, vol. 4052, pp. 22–33.Springer, Heidelberg (Jul 2006)

A Preliminaries

Collision Resistant Hash Function (CRHF). A family of functions H is collisionresistant if no efficient algorithm can find, on input a random H ∈ H, twodifferent inputs x 6= y such that H(x) = H(y) (except with probability negligiblein the security parameter). We will use the CRHF proposed in [4].

Merkle Hast Tree (MHT). A Merkle hash tree (MHT) [25] provides a succinctcommitment to a vector, such that it is later possible to open and verify individualvalues in the vector without opening the entire vector. Given a vector x =

17

(x1, . . . , xn), a MHT is constructed on it as follows: group the value pairs andthen use a CRHF to hash each pair. The hash values are again grouped in pairsand each pair is further hashed, and this process is repeated until only a singlehash value remains. This results in a binary tree with the leaves correspondingto the blocks of the vector and the root corresponding to the last remaining hashvalue. The root serves as the commitment to x and later individual positionscan be opened such that the opening can be verified against the root.

A.1 Universally Composable (UC) Security

A protocols that securely realizes a given task f are defined in three steps, asfollows.

1. A protocol Π for executing the given task f is formalized. This is called thereal world protocol.

2. An ideal functionality, F for carrying out f is formalized. In the ideal processthe parties do not communicate with each other. Instead they hand theirinput to F which computes f on the received inputs and gives back toeach player the appropriate output. F is essentially an incorruptible trustedparty that is programmed to capture the functionality of f . In this idealizedsetting, security is inherently guaranteed as any adversary, controlling someof the parties, can only learn/modify the data of corrupted parties.

3. The designed protocol Π is said to securely realize the ideal functionalityif the process of running the real world protocol amounts to emulating theideal process for F .

The last step is formalized by considering an environment Z that is allowedto provide inputs to all the participants. Z chooses the inputs of the parties andcollects their outputs. In the real world, Z can communicate freely with an ad-versary A, controlling the corrupt parties and the communication among them.In the ideal world, Z interacts with dummy parties who simply relays inputs andoutputs between Z and F and an ideal adversary Sim also interacting with F . Zaims to distinguish the case where it receives the outputs produced from a realexecution of the protocol from the case where it receives outputs obtained froman ideal execution of the protocol. Π realizes the functionality F if for every(polynomially bounded) A, there exists a (polynomially bounded) Sim such thatno (polynomially bounded) Z can distinguish a real execution of the protocolfrom an ideal one with a significant advantage. The universal composability the-orem assures that Π continues to behave like the ideal functionality even if it iscomposed with other arbitrary protocols.

More formally, let REALΠ,A,Z(λ, a) denote the distribution given by the out-put of Z on input a withA and parties running protoolΠ and IDEALF,Sim,Z(λ, a)denote the distribution given by the output of Z on input a with Sim and dummyparties relaying to F . Protocol Π safely realizes F if, for all polynomial-time Athere exists a polynomial-time Sim such that, for all polynomial-time Z, the twodistributions REALΠ,A,Z and IDEALF,Sim,Z are indistinguishable.

18

A protocol ΠG securely realizes F in the G-hybrid model when Π is allowedto invoke ideal functionality G.

Session ID: In the UC framework there may be many copies of the ideal func-tionality running in parallel. Each copy is supposed to have a unique sessionidentifier (sid) that describes which session or instance it belongs to. Every timea message has to be sent to a specific copy of F , such a message should containthe sid of the copy it is intended for.

Ideal Functionalitiy FCRS [11]: We extend the functionality in [11] by makingthe common reference string depend on the system parameters. FCRS is param-eterized by a ppt algorithm CRS.Setup and by system parameters sp.

Functionality Fcrs (parametarized with system parameters sp): On input(startCRSgen, sid) from any party P,

– If (sid, crs) is stored, set crs′ ← crs. Otherwise, run crs′ ← CRS.Setup(sp) andstore (sid, crs′)

– Send (endCRSgen, sid, crs′) to P .

B ΠOOPRF securely realizes FOOPRF

To prove that our construction ΠOOPRF securely realizes the ideal functionalityFOOPRF, we have to show that, for any environment Z and any adversary A,a simulator Sim exists such that Z cannot distinguish whether it is interactingwith A and the protocol in the real world or with Sim and FOOPRF. The simulatorplays the role of all honest parties in the real world and interacts with FOOPRF

for all corrupt parties in the ideal world. In the next section, we present thesimulator Sim and the proof of security.

B.1 Simulator.

We are proving the security of ΠOOPRF in the (F1−auth,FCRS)-hybrid model wherewe use functionality F1−auth (one-side authenticated communication as we wantthe clients to remain anonymous to KS) [13] to realize the communication be-tween the parties. In this model, Sim will always simulate F1−auth,FCRS towardsthe malicious party. Sim simulates FCRS as follows:

On input (startCRSgen, sid) from SimCRS, if par is not stored, Sim sets param-eters par and trapdoor td as follows.

– Run (parPRF)← PRF.Setup(sp)– Run (parVC)← VC.Setup(sp, n)– Run (parHES)← HES.Setup(sp)– Run (parCS)← CS.Setup(sp)– Run (parPK, tdstde)← SE(sp).– Set par := (parPRF, parVC, parHES, parCS, parPK) and td := (tds, tde)

19

as we want the client to remain anonymous from KS. a functionality Fch torealize the communication between party.

We address first the case of a malicious client and honest server, and thenthe case of an honest client and honest-but-curious server.

Malicious Ci and honest KS: On input (Setup, sid) from FOOPRF, Sim simulatesFCRS towards Ci. Then Sim sends (Setup, sid, ok) to FOOPRF.

At some point after the setup, Sim receives (Evaluate, sid, qid) from an anony-mous client. Here, Sim plays the role of an honest KS with the client as per theprotocol. When Ci sends (s′, com, πc00, πc01), then Sim uses the extractor of πc00to extract s (recall that πc00 := PoK(s, r2) : com = CS.Commit(par, s, r2)).Then, Sim receives (Evaluate, sid, qid, startEvaluate) from FOOPRF and does thefollowing:– Picks a set of random t indices: I = [i1, . . . , it] from [1, n], where n is the

upper bound on the length of the files send them to Ci.– Let Ci respond with πc1 = πj |j ∈ I. Sim extracts (xj , wj) from each πj

and– Runs b ← detVC.Verify(s, x[j], wj) for all j ∈ I. If at least one verification

fails, Sim aborts.– Else, sends (Evaluate, sid, qid, startEvaluateok, s, xj , wjj∈I) to FOOPRF

Finally, Sim gets back (Evaluate, sid, qid, r) from FOOPRF.Now, if the verificationof πc2 fails then Sim returns ⊥. Otherwise, Sim sets K ′ ← r and forwards it toCi.

Honest Ci and honest-but-curious KS: FPRF.Setup,VC.Setup,CS.Setup,PK.Setup,HES.Setup,spCRS

is simulated by Sim towards KS. Sim will then invoke FOOPRF with (Setup, sid).Sim recieves (Setup, sid) from FOOPRF and responds with (Setup, sid, ok).

Then, Sim runs the Evaluate part of ΠOOPRF playing the role of an honestclient Ci. Sim does that by picking a random file x, simulates the proofs for thechallenged positions and runs the necessary steps of the protocol.

At some point, Sim receives (Evaluate, sid, qid, startEvaluate) from FOOPRF andif the protocol execution above succeeded, then Sim sends (Evaluate, sid, qid,startEvaluate, ok) to FOOPRF causing FOOPRF to output to Ci.

B.2 Proof of Security

Theorem 4. In the FPRF.Setup,VC.Setup,CS.Setup,PK.Setup,HES.Setup,spCRS -hybrid model,

protocol ΠOOPRFPSF securely realizes FOOPRF if the underlying vector commit-ment scheme VC is hiding and binding, CS is a hiding and binding commit-ment scheme, HES is a semantically secure encryption scheme and the non-interactive proof of knowledge scheme PK is zero knowledge and simulation-sound extractable.

Proof. We now show by means of a series of hybrid games that the environ-ment Z cannot distinguish between the ensemble REALΠOOPRF,A,Z and the en-semble IDEALFOOPRF,Sim,Z with non-negligible probability. The idea is that we

20

start with the real world protocol and then modify it until the simulator incor-porates FOOPRF.

We first address the case of malicious client and honest server and thenthe case of a honest client and honest-but-curious server. At a high level, theproof for the malicious client and honest server case requires simulation soundextractability of the underlying proof system, IND-CPA security of the homo-morphic encryption scheme and the pseudorandomness of the PRF. Leveragingeach of these security properties at the intermediate game hops, we move fromthe ensemble REALΠOOPRF,A,Z to the ensemble IDEALFOOPRF,Sim,Z .

The honest client and honest-but-curious server is simpler. It requires sim-ulation soundness of the proof system to be able to simulate the proofs for thechallenged positions and hiding property of the randomized vector commitmentscheme. Leveraging these security properties at the intermediate game hops, wemove from the ensemble REALΠOOPRF,A,Z to the ensemble IDEALFOOPRF,Sim,Z .

Malicious Ci and honest KS:

Game 0: This game corresponds to the execution of the real-world protocolΠOOPRF.

Game 1: Same as the previous game, except the following: Game 1 replaces theparameters parPK computed by PK.Setup by parameters computed by SE . Bythe simulation-sound extractability of the PoK, Game 0 is indistinguishablefrom Game 1.

Game 2: Same as the previous game, except the following: Game 2 calls theextractor of the PoK πc00 to extract s. The probability that the extractorextracts s is non-negligible by the simulation-sound extractability of the PoK.Therefore, Game 1 is indistinguishable from Game 2.

Game 3: Same as the previous game, except the following: Game 3 uses theextractor of πj for all πj ∈ πc1

9 to extract (xj , wj). By the simulation-sound extractability of the PoK, the extractor will extract (xj , wj) with non-negligible probability.

Now notice that if for some j ∈ I, the malicious client is able to produce, intwo different runs, (xj , wj), (x

′j , w

′j) such that

xj 6= x′j , wj 6= w′j ,

and still

VC.Verify(par, s′, j, xj , wj) = VC.Verify(par, s′, j, x′j , w′j) = 1 ,

then the real protocol ΠOOPRF will accept and move to the next step whereasthe ideal functionality FOOPRF will reject and stop.Therefore, Z’s views will clearly be different in this two cases and Z can usethis strategy to distinguish between the real and the ideal world.

9 Notice that actually, the tuples (xj , wj) are extracted once at the time. Therefore,t = poly(λ) sub games are needed. We did not include them to avoid burdening theflow of the proof.

21

We prove that this can happen only with negligible probability by reducing tothe binding property of VC scheme. The reduction can use (xj , wj , x

′j , w

′j , s)

as a response to the VC binding game, thereby breaking VC’s binding. Hence,this happens with negligible probability and Z’s view in Game 2 is indistin-guishable from Z’s view in Game 3.

Game 4: Same as the previous game, except the following: Game 4 calls the ex-tractor of the PoK πc2 to extract r3. By the simulation-sound extractability ofthe PoK, πc2, the probability that the extractor extracts r3 is non-negligible.Z’s view in these two games are indistinguishable.

Game 5: Same as the previous game, except the following: Game 5, insteadof decrypting ct, computes K ′ as follows. Notice that if a malicious clientsends a malformed ciphertext, then πc2 will not verify and the Sim will abortexcept with negligible probability.

1. If gcd(k + s,N) 6= 1, send ⊥ to Ci and abort. Else proceed to the nextstep.

2. Set K ′ ← g1

(k+s)r3mod N

Note that if gcd(k+ s,N) 6= 1 then β = r3(k+ s) is not co-prime with N forany r3, so gcd(HES.Dec(epk, ct), N) 6= 1. Hence, in the real protocol, the KSwill also send ⊥. Thus Z’s views in these two games are indistinguishable.

Game 6: Same as the previous game, except the following: In Game 6, [k] isreplaced with [k′] for some random k′ in the PRF key space.

If Z can distinguish between these two games, then we can use Z to breakthe IND-CPA security of the underlying encryption scheme.

In more detail, the reduction receives epk from the IND-CPA challenger andpick a random k′ 6= k. It then sends k, k′ as its challenge messages andreceive c as its challenge ciphertext. Sim sends epk and c to Ci as [k]. If thechallenge ciphertext contains k, then the reduction simulates Game 4, else itsimulates Game 5. If Z can distinguish between these two games, then thereduction uses Z to break the IND-CPA security.

Hence Z’s views in these two games are indistinguishable.

Game 7: Same as the previous game, except the following: In Game 7 thecomputation of K ′ is replaced by the following computation: K ′ ← gr forsome random r ∈ R. If Z can distinguish the between these two games, thenit breaks the security of the PRF.

In details, the reduction gets oracle access to either the PRF or a randomfunction. To compute K ′, the reduction invokes its oracle on input s andreceives output v. Then the reduction sets K ′ ← v(r3

−1 mod N) (r3 wasextracted in Game 4). If the oracle was the PRF, then the reduction is simu-lating Game 6, else Game 7. So, if Z can distinguish between this two games,then the reduction uses this Z to break the PRF security.

Hence, Z’s views in this two games are indistinguishable.

Game 8: Same as the previous game, except the following: instead of using K ′,Game 8, uses the key it receives from FOOPRF as K ′. Clearly, Z’s views inthese two games are indistinguishable.

22

The distribution produced by Game 8 is identical to that of our simulation.Sim interacts with the adversary A and the ideal functionality FOOPRF asdescribed above.

Honest Ci and honest-but-curious KS:

Game 0: This game corresponds to the execution of the real-world protocolΠOOPRF.

Game 1: Same as the previous game, except the following: Game 1 replaces theparameters parPK computed by PK.Setup by parameters computed by SE . Bythe simulation-sound extractability of the PoK, Game 0 is indistinguishablefrom Game 1.

Game 2: Same as the previous game, except the following: Game 2 generatesthe proof for each position by running the simulator for the proof system10.The zero-knowledge property ensures that proofs computes by the simulatorare indistinguishable from the proofs computed by the prove algorithm ofthe PoK system. So Z’s views in these two games are indistinguishable.

Game 3: Same as the previous game, except the following: Game 3 picks a arandom vector x. At this point, the proofs of positions are simulated proofs.The hiding property of the underlying randVC scheme guarantees that acommitment to a given vector is indistinguishable from a commitment to arandom vector. Hence Z’s views in these two games are indistinguishable.The distribution produced by Game 3 is identical to that of our simulation.Sim interacts with the adversary KS and the ideal functionality FOOPRF asdescribed above. Sim sends (Evaluate, sid, qid, endEvaluate, ok) to FOOPRF ifall the protocol steps succeed causing FOOPRF to output to Ci.

ut

C Security Proof of the VC in Section 5

Theorem 5. The VC scheme satisfies correctness and binding, if CS is hidingand binding and H is a CRHF.

Proof. (Sketch) Correctness is easy to see.Hiding (for the randVC): The scheme is information theoretically hiding bythe hiding property of Pedersen commitment.Binding: Here we prove that if H is a CRHF, then the scheme above is bind-ing. Given an adversary A that breaks the binding property with non-negligibleprobability, we construct an algorithm A′ that breaks the CR with non-negligibleprobability. A receives the description of H and picks the rest of the parametersas per the construction and send par to A. A returns a commitment MR, a posi-tion index i and two (x,w, x′, w′) for position i such that the verification passesbut x 6= x′ and w 6= w′. Let us denote the two witness paths P1 = (p1, . . . , pd)

10 Again, we avoided here the intermediate games to generate the simulated proofsonce at the time just for the sake of clarify.

23

and P2 = (p′1, . . . , p′d) and p0, p

′0 as the two recovered roots from P1,P2 respec-

tively. Since p0 = p′0 = MR and pd 6= p′d, it must be the case that there is at leastone node where the paths collide. More formally, there exists 1 ≤ j ≤ d− 1 suchthat pj = p′j even though their children are not equal, i.e., Lj 6= L′j∨Rj 6= R′j . A′outputs (Lj , Rj), (L

′j , R

′j) as the collision pair.

D RSA-based Vector Commitment

In this section we recall the RSA based non-hiding VC scheme presented in [14]with two main changes: (1) We make the commitment scheme hiding and (2)we add a PoK to prove ith index instead of providing the value and the witnessdirectly. This is the second instantiation VC that can be plugged in to ΠOOPRF.We give concrete implementations of all the accompanying PoK’s in Appendix E.

D.1 Construction

We now recall the RSA-based vector commitment construction in [14] and pointout that these vector commitments are randomizable.

VC.Setup(1λ, n) : On input security parameter 1λ and an upper bound n, thealgorithm does the following:1. Pick two λ bit safe primes p = 2p′ + 1 and q = 2q′ + 1 and set N = pq.2. Pick l = poly(λ) to be the upper bound on the length of the messages.3. Choose n, l + 16111 bit primes e1, . . . , en that do not divide φ(N).4. Pick a random b← Z∗N .

5. For j = 1, . . . , n, compute Kj ← b∏n

i=1,i 6=j ei mod N6. Set K0 ← b

∏ni=1 ei mod N

7. Output the parameters par := (N, b, e1, . . . , en,K0, . . . ,Kn,M = 0, 1l,R = Z∗N )

VC.Commit(par,x): On input public parameters par and input x = x1, . . . , xn,the algorithm computes com ← Kxi

1 . . .Kxnn mod N and outputs commit-

ment com.VC.Prove(par, i,x): On input public parameters par, position i and input x =

x1, . . . , xn, the algorithm computes w ← (∏Nj=1,j 6=i Kj

x[j])1ei mod N and

outputs witness (w, xi).VC.Verify(par, i, com, w, x): On input public parameters par, position i, commit-

ment com, witness (w, x), the algorithm outputs 1 if Kxi wei mod N = com

and x ∈M, 0 otherwise.Note that the verification algorithm is the same for both the randVC and thedetVC versions. Only instead of com, the algorithm will take com′ as input.

11 We require this to be larger than the message length l, But for an efficient rangeproof that the message is within the correct range, we need to allow the buffer forthe length of the challenge space and the statistical parameter, which is 160 bitstotal. The implementation is in Section E.

24

VC.RandCommitment(par, com, r): On input public parameters par, non-hidingvector commitment com and randomness r ∈ R, the algorithm computescom′ ← com · Kr0 mod N and outputs com′.

VC.RandWitness(par, com, i, r, w): On input public parameters par, non-hidingvector commitment com, position i, randomness r ∈ R and partial witnessw, the algorithm computes w′ ← w · (b

∏nj=1,j 6=i ej )r = w · K0

rei mod N and

outputs w′.

D.2 Security Proof

Theorem 6. The VC scheme presented above is correct, hiding and binding un-der the RSA assumption.

Proof. (Sketch) The completeness is easy to see.

Hiding (for the randVC): Hiding is satisfied information theoretically since theblinding factor is completely random.

Binding: If the RSA assumption holds, then the scheme defined above is bind-ing. More precisely, if there exists an efficient adversary that produces two validopenings to two different messages at the same position, then we can constructa PPT adversary that breaks the RSA assumption. The reduction is identicalto the reduction proof of Theorem 6 in [14]. We note that the sole difference ofour construction from that of [14] is that we have the hiding factor Kr0. But the

reduction uses the equality Kixwei = Ki

x′w′ei to extracts response for the RSA

challenge; so the effect of the hiding factor cancels out in the reduction.

E GSPK Proofs

In the following, we give the concrete implementations of our PoK protocols. Tothis end we require the CRS to contain the public key of the CPA version ofthe Camenisch-Shoup encryption scheme [9]. We already have the modulus Nin the CRS which we can use. Recall that N is a product of two safe primeswhich can be generated distributedly [1]. Furthermore, let g’ and y’ and be arandom elements of Z∗N2 contained in the CRS and set g = g’2N , y = y’2N ,and h = 1 + N mod N2. We first describe the implementations of the PoK’sthat are common to both the VC instantiations we presented and then give theimplementations specific to each VC.

E.1 GSPK common to both the VC’s:

In this Section we show how proof protocols πc00 and πc2 are realized. Morespecifically, the proof protocol

πc00 = PoK(s, r) : com = CS.Commit(par, s, r)

25

is realized by first computing Es = (gr1 mod N2, hsyr1 mod N2), Er = (gr2 modN2, hryr2 mod N2), and with r1 and r2 being randomly drawn from [N/4], send-ing these values to the verifier, and the executing the following proof protocolwith the verifier:

GSPK(s, r, r1, r2) : com = GsHr ∧ Es = (gr1 , hsyr1) ∧ Er = (gr2 , hryr2)

where we have dropped modρ and modN2 from the terms for brevity.

On the other hand, the proof protocol

πc2 = PoK(s, r2, r3) : com = CS.Commit(par, s; r2) ∧ ct = ([k][s])r3

is realized as follows: Let us denote [k] = (e1, e2). The prover first computes Er =(gur mod N2, hr3yur mod N2) , where ur being randomly drawn from [N/4],sends these values to the verifier, and executes the following proof protocol withthe verifier:

GSPK(s, r2, r3, w, r) : com = GsHr2 ∧ 1 = com−r3GwHr′∧

ct = (er31 epkBhw, er32 gB) ∧ Er = (gur , hr3yur )

Here, the term 1 = com−r3GwHr′

shows that w = sr3 and hence thatct = ([k][s])r3 with B being the value that the prover used to randomize theencryption.

E.2 GSPK for the MHT-VC:

For our OOPRF scheme we need three accompanying PoK’s that we need toimplement efficiently. Here, we explain which proofs can actually be avoidedfor the MHT- VC instantiation, and which need more care. Notice that,VC.RandCommitment is the same as CS.Commit algorithm, which computes aPedersen commitment to the detVC, MR. So, πc01 will be just a standard proofof equality [9]. In fact, the following optimisation can be done: use s′ as comthroughout the protocol and skip π01.

For the proofs πj : PoK

(w, x) : 1 = randVC.Verify(par, j, com, w, x), prov-

ing these relations is a bit more involved and requires the following steps:1. The algorithm parses w as (PS = (p′1, . . . , p

′d), comMR, openMR). Let us denote

the node values along the path from the root node with value MR, to theleaf node, with value xi, in the MHT as: P = (p0, p1, . . . , pd). The algorithmrecovers this path recursively bottom up using H(·, ·) on PS . Note that theindex position j uniquely decides the left and the right child at each step.

2. Then, the algorithm commits to every value pj in this path and to the valuesof the left and right children of pj in the MHT, i.e., if lj is the left child andrj is the right child of pj , then the algorithm computes

(Pj , sj)← CS.Commit(par, pj , sj), (Lj , s′j)← CS.Commit(par, lj , s

′j),

(Rj , s′′j )← CS.Commit(par, rj , s

′′j )

26

3. Then, the algorithm generates a proof that P0 is indeed a commitment tothe root.12

PoKMR(MR, r, s) : com = CS.Commit(par,MR, r) ∧ P0 = CS.Commit(par,MR, s)

4. Next, for j = 0, . . . , d− 1, the following proof of knowledge that each triplet(Pj , Lj , Rj) is well formed. Note that Lj (or Rj) is used as Pj+1.

PoKj(l, r, s, s′, s′′) : Pj = CS.Commit(par, l7 + 3r7, s)∧Lj = CS.Commit(par, l, s′) ∧Rj = CS.Commit(par, r, s′′)

This proof requires some sub steps which are the following:(a) This proof uses the homomorphic property of Pedersen commitment

scheme and a subprotocol for PoKmult for multiplication of two values.This protocol is instantiated using standard techniques [9, 5].

PoKmult(x, y, z, sx, sy, sz) : Cx = CS.Commit(par, x, sx)∧Cy = CS.Commit(par, y, sy) ∧ Cz = CS.Commit(par, z, sz) ∧ z = x · y

(b) The prover computes Cl, Cl2 , Cl4 , Cl6 , Cl7 and Cr, Cr2 , Cr4 , Cr6 , Cr7 andinvokes PoKmult on each of the following triplets to prove the correctnessof the commitments and sends them to the verifier.

(Cl, Cl, Cl2) (Cl2 , Cl2 , Cl4) (Cl2 , Cl4 , Cl6) (Cl, Cl6 , Cl7)

(Cr, Cr, Cr2) (Cr2 , Cr2 , Cr4) (Cr, Cr4 , Cr6) (Cr, Cr6 , Cr7)

Now we show how to realize proof protocols PoKMR and PoKmult for ourMHT-VC. In details, the proof protocol

PoKMR(MR, r, s) : com = CS.Commit(par,MR, r)∧P0 = CS.Commit(par,MR, s)

is done as first computing EMR = (gr1 mod N2, hMRyr1 mod N2), Er = (gr2 modN2, hryr2 mod N2), and Es = (gr3 mod N2, hsyr3 mod N2), with r1, r2, and r3being randomly drawn from [N/4], sending these values to the verifier, and thenexecuting the following proof protocol with the verifier

GSPK(MR, r, s, r1, r2, r3) : com = GMRHr ∧ P0 = GMRHr ∧EMR = (gr1 , hMRyr1) ∧ Er = (gr2 , hryr2) ∧ Es = (gr3 , hsyr3) ,

where we have dropped modρ and modN2 from the terms for brevity.

12 We are going to abuse the notation a little and ignore the open in the output ofCS.Commit for notational convenience.

27

On the other hand, proof protocol

PoKmult(x, y, z, sx, sy, sz) : Cx = CS.Commit(par, x, sx)∧Cy = CS.Commit(par, y, sy) ∧ Cz = CS.Commit(par, cz, sz) ∧ z = x · y

is done by first computing Ex = (gu1 mod N2, hxyu1 mod N2) and Ey =(gu2 mod N2, hyyu2 mod N2), with r1 and r2 being randomly drawn from [N/4],sending these values to the verifier, and then executing the following proof pro-tocol with the verifier:

GSPK(x, y, z, sx, sy, sz, s′, u1, u2) : Cx = GxHsx ∧ Cy = GyHsy∧

Cz = GzHsz ∧ Cz = CxyHs′ ∧ Ex = (gu1 , hxyu1) ∧ Ey = (gu2 , hyyu2) .

Notice that we do not need to verifiably encrypt the witness z as this one canbe computed from x and y. Similarly, a number of encryptions can be droppedwhen combing these proofs into the bigger proof of the hash-tree path. We leavethese optimizations to the reader.

E.3 GSPK for the RSA-VC:

In this section we show how to realize proof protocols πc01 and πj for our RSA-VC. In details, the following statement

πc01 := PoK(s, r1, r2) : coms = CS.Commit(par, s, r2) ∧s′ = VC.RandCommitment(par, s; r1)

proves that s′ is a randomized version of the vector commitment s to which inturn coms commits. In other words, that s′ = sKr00 holds for some value of r0and for the s committed in coms. This statement can be proved by the followingproof protocol

GSPK01(r1, r′2) : Gs′

= comK0r1

s Hr′2) mod ρ .

Here r′2 absorbs the randomness −r2K0r1 , i.e., r′2 = −r2K0

r1 , but we do needto prove anything about r′2. Note that this protocol only works with binarychallenges as it involved a “double discrete logarithm” relation (thus the suffice01 for GSPK01).

On the other hand, for proof

πj = PoK(w, x) : 1 = VC.Verify(par, com′, j, x, w)

we further require that the CRS also contain elements z1, z2, and z3 fromZ∗N of order p′q′ so that that w can be verifiably ElGamal-encrypted w.r.t.to z1, and to do range proofs for x w.r.t. z2 and z3. Thus, the prover firstcomputes E1 = wzr1 mod N , E2 = zr2 mod N , E′ = zx2z

r3 mod N , and Ex =

28

(gux mod N2, hxyux mod N2) , where ux and r being randomly drawn from[N/4], sends E1, E2, E′, and Ex to the verifier and executes the proof with it

GSPK(x,w, r) : com′/Eej1 = Kxi (z

−ej1 )r ∧ E2 = zr2∧

Ex = (gux , hxyux) ∧ E′ = zx2zr3 ∧ x ∈ [−2l+160, 2l+160] .

This proofs shows that e1/zr1 is a witness for x and that x is in the required

range. The witnesses w and x can be on-line extracted by having the simulatorset the CRS such that it knows logz1 z2 and logg y, respectively.

F Concrete Efficiency Analysis

In this section, we look at the concrete efficiency analysis for Evaluate of ΠOOPRF

(Section 4) implemented with the vector commitment scheme in Section 5. Wefocus on the scenario where stand-alone security is sufficient and we can realizeall the PoK’s with generalized Schnorr proofs. We count the exact number ofExp for each of the PoK’s as generalized Schnorr proof operations. Note thatwe count both binary exponentiation and a single exponentiation as one Exp.13

Recall that n is the size of the file and t is the number of challenges positions.Step 2: VC.Commit: 2n hash computations (where the hash function H :

ZN2 → ZN is defined as H(x, y) = x7 + 3y7 mod N) andVC.RandCommitment requires 1 Exp (in an order N sub-group of Z2kN+1)

Step 2b: 1Exp (in an order N sub-group of Z2kN+1)Step 2c, πc00: Prover: 1Exp, Verifier: 2Exp (in an order N sub-group of Z2kN+1)Step 2d, πc01: Prover: 2Exp, Verifier: 4Exp (in an orderN sub-group of Z2kN+1)PoKmult: Prover: 3Exp, Verifier: 6Exp (this is a sub-protocol used in computing

πj , see Section 5) (in an order N sub-group of Z2kN+1)Step 5, πj: Prover: (8∗3)t log n = 24t log n Exp, Verifier: (8∗6)t log n = 48t log n

Exp (in an order N sub-group of Z2kN+1)Step 7: 3Exp (in group ZN2)Step 8: 3Exp (in group ZN2)Step 9,πc2: Prover: 2Exp(in an order N sub-group of Z2kN+1) and 2Exp (in

group ZN2), Verifier: 4Exp (in an order N sub-group of Z2kN+1) and 4Exp(in group ZN2)

Step 11: 1Exp (in group ZN2)Step 12: 1Exp (in the target group of a order N bilinear group)Step 13: 1Exp (in the target group of a order N bilinear group)

13 We do not consider the transformation of generalized Schnorr protocols for simu-lation soundness as they are standard and their costs largely independent of thenumber of operations of the Schnorr proof (e.g., one method is to use a signaturescheme to sign the third message and to embed the verification key in the hash-function) [6].

29