ZQL: A Compiler for Privacy-Preserving Data · PDF filequeries for smart-meter billing, for...

Open access to the Proceedings of the 22nd USENIX Security Symposium

is sponsored by USENIX

This paper is included in the Proceedings of the 22nd USENIX Security Symposium.August 14–16, 2013 • Washington, D.C., USA

ISBN 978-1-931971-03-4

ZQL: A Compiler for Privacy-Preserving Data Processing

Cédric Fournet, Markuld Kohlweiss, and George Danezis, Microsoft Research; Zhengqin Luo, MSR-INRIA Joint Centre

USENIX Association 22nd USENIX Security Symposium 163

ZQL: A Compiler for Privacy-Preserving Data Processing

Cedric FournetMicrosoft Research

Markulf KohlweissMicrosoft Research

George DanezisMicrosoft Research

Zhengqin LuoMSR-INRIA Joint Centre

AbstractZQL is a query language for expressing simple compu-tations on private data. Its compiler produces code tocertify data, perform client-side computations, and verifythe correctness of their results. Under the hood, it synthe-sizes zero-knowledge protocols that guarantee both in-tegrity of the query results and privacy for all other data.

We present the ZQL language, its compilation schemedown to concrete cryptography, and the security guaran-tees it provides. We report on a prototype compiler thatproduces F# and C++. We evaluate its performance onqueries for smart-meter billing, for pay-as-you-drive in-surance policies, and for location-based services.

1 Introduction

A variety of private user data is used to tailor modern ser-vices, and some go as far as billing based on fine grainedcustomer readings. For example, smart meters are usedto charge a different tariff depending on the time of elec-tricity usage; pay-as-you-drive insurance premiums de-pend on detailed driving pattern of drivers. Such schemesare currently implemented by collecting fine-grained in-formation, and processing it on the service side—an ar-chitecture that has led to serious privacy concerns.

This paper supports an alternative approach: clientscould perform sensitive computations on their own datacertified by meters or car on-board units [55, 60], andupload only the results, together with a proof of correct-ness to ensure their integrity. We propose ZQL, a simplequery language to express at a high level such compu-tations, without any cryptographic details. Queries arecompiled to code for the data sources, the clients, andthe verifiers by synthesizing zero-knowledge protocols.

The most popular language for querying and perform-ing computations on user data is SQL [29] based on re-lational algebra. The ZQL feature set was chosen to sup-port a subset of SQL. Data is organized into tables ofrows, with private and public columns. Queries accept

tables as inputs, and can iterate over them to produceother tables, or aggregate values. Simple arithmetic oper-ations on rows are supported natively, and so is a limitedform of SQL joins through table lookups.

ZQL offers advantages over hand-crafted protocols, inthat computations are flexible and can be expressed at ahigh level by application programmers. The computa-tions can also be modified and recompiled, without theneed to involve cryptography experts.

The ZQL compiler is free to synthesize custom zero-knowledge protocols behind the scene, and we currentlysupport two main branches, for RSA and Elliptic Curveprimitives. We also support a symbolic execution back-end to derive estimates of the cost of evaluating and ver-ifying queries. Synthesized protocols themselves are in-ternally represented and optimized as fragments of anextended ZQL language until the final code is emitted.Intermediate ZQL is strongly typed, and precise refine-ment types can be used to verify security properties onthe final compiled code, using F7 [16] or F* [58].

Informally, for a given source query, the desired secu-rity properties on the resulting ZQL-compiled code are:

• Correctness. For any given source inputs, the se-quential composition of the cryptographic queriesfor the data sources, the user, and the verifier yieldsthe same result as the source query.

• Integrity. An adversary given the capabilities ofthe user cannot get the verifier to accept any otherresult—except with a negligible probability.

• Privacy. An adversary given the capabilities of theverifier, able to choose any two collections of in-puts such that the source query yields the same re-sult, and given the result of the user’s cryptographicquery, cannot tell which of the two inputs was used.

This corresponds to the source query being executed bya fictional trusted third party sitting between the datasources, the user, and the verifier.

1

164 22nd USENIX Security Symposium USENIX Association

Contents The rest of the paper is organized as fol-lows. §2 introduces our query language using a series ofprivacy-preserving data processing examples. §3 speci-fies our target privacy and integrity goals. §4 reviews themain cryptographic mechanisms used by our compiler.§5 describes the compilation process. §6 gives our mainsecurity theorems. §7 discusses applications and §8 pro-vides experimental results and discusses future work.

This short version of the paper omits many detailsand discussions; an extended version with auxiliary def-initions, proofs, and examples is available at http://research.microsoft.com/zql.

Related work The ZQL language provides private dataprocessing. The zero-knowledge protocols synthesizedare standard Σ-protocols [32, 30, 33], but in ZQL they areused for proving the correctness of general computationsrather than for cryptographic protocol design.

Arguably, previous works on zero-knowledge compil-ers focused on the latter as the primary use-case [19,51, 2, 1]. The use of zero-knowledge for authenticationand authorization as in credential and e-cash technolo-gies [23, 51, 4] received particular attention, but, to ourknowledge, no-one considered the use of Σ-protocols toprove the execution of general programs.

More specifically, a long line of work [19, 7, 2]culminating in the CACE compiler tackles the prob-lem of automatically translating proof goals specifiedin the Camenisch-Stadler notation [22] into efficient Σ-protocols. Intermediate translations steps of ZQL (theshared translation) are at a similar level of abstractionto the Camenisch-Stadler notation but ZQL also syn-thesizes those representations from source code, andthen proceeds to compile them to low level operations.ZKPDL [51], an alternative compiler for Σ-protocols,uses a natural language inspired specification of zero-knowledge proof goals. This specification language maybe even closer in spirit to our intermediary notation, asit allows for the possibility to specify the generation ofthe protocol inputs. The authors of the CACE compilerdiscuss the difference and similarity between these twoapproaches in a Usenix poster [9]. The cryptographicprototyping language Charm [1] also includes a zero-knowledge proof compiler for Camenisch-Stadler state-ments which is currently primarily a proof of conceptand thus less sophisticated than CACE and ZKPDL. Weare also aware of an embedding of a zero-knowledge lan-guage in C++ [45].

ZQL differs from standard multi-party computationcompilers [49], in that it assumes the client knows allprivate data. This assumption allows for single roundprotocols, and the efficient non-interactive implementa-tion of non-linear operations including joins.

ZQL SourceQuery

VerifierCode

Prover Code

Data Sourcecode

Data Sources Client Service

Certified Data Certified Query Results

Figure 1: ZQL in a privacy friendly computation system.

2 A Language for Private Data Processing

Why ZQL? We design ZQL to support privacy proto-cols that rely on client-side computation while requiringhigh integrity [35]. In this setting, a number of (possiblyindependent) data sources provide signed personal dataitems to a user. The signed data is then used as an input tosome computation performed on a user device on whichthe operation of a service relies (for example billing fora utility, determining the proximity of to a specific path,or profiling the shopping habits of a user). The resultsof the computation are then sent to the relying service,while private input data is kept secret. The ZQL compilertakes a high level description of the computation and isresponsible for producing the code executed by the datasources to sign personal data, the computation prover andthe computation verifier, as illustrated in Figure 1.

It is assumed that communications take place over pri-vate authenticated channels; the data sources are trustedby all to maintain the privacy of the raw personal datathey produce, and to securely sign them. Given this,our protocols guarantee integrity through cryptographicproofs that establish the authenticity of the personal datainputs and the correctness of a particular computation.Thus, a malicious client cannot manipulate the result ofthe computation. On the other hand, the private inputsto the computations are kept secret by the user, and theproofs do not leak anything about them. Thus, privacy ispreserved, and only the result of the computations (andany inferences that can be drawn from them) becomeknown to the relying service. Compiling allows us tostatically verify the security of the resulting protocols us-ing refinement types (see the full paper). Hence, both theprover and the verifier, or anyone they trust, can sepa-rately review the source query, compile the protocol, andverify its security by typing.

There are advantages in de-coupling data sources fromspecific computations. It allows for meters, or servicesproviding personal data, to remain simple, cheap, andgeneric. In turn, the computations, such as billing, can be

2


e ::= Expressions| x variable| op e application| let ρ = e in e let binding| ↓ e declassification

op ::= Operators| ( , ) | ( , , ) | . . . tuples| + | − | ∗ arithmetic| = | ∧ boolean| map (ρ → e) map iterator| fold (ρ → e) fold iterator| lookup ρ table lookup

τ ::= Types| int [pub] security type| ρ table table| ρ lookuptable lookup table

ρ,θ ,Γ ::= ε | x : τ,ρ Tuple types

Figure 2: ZQL Syntax

updated without changing the devices that certify read-ings. Finally, private computations can aggregate dis-parate data sources that are not aware of one another, ormay not trust one another with the privacy or integrity ofthe computations.

We first provide a brief description of our source lan-guage and then illustrate its primitives through simpleexamples. §7 provides larger examples of protocols thathave been proposed in the literature.

The ZQL language At its core, ZQL is a pure expres-sion language, with built-in operators that act on integersand tables. Figure 2 gives its abstract syntax. A queryθ → e consists of the declaration of input variables (θ )that can be either public or private, and of an expressionbody (e).

Expressions consist of variables, operators applied tosub-expressions e (including constants as a special casewhen e is empty), and let bindings for sequential com-position. Expressions evaluate to tuples of values: forexample, the expression let x : int,y : int = e in e0 firstevaluates the sub-expression e to a pair of integers vx,vy,then evaluates e0 after substituting vx and vy for x and y.

A variety of operators support arithmetic (0, 1, +, ∗),booleans (=, ∧), and operations on tables (map, fold,lookup). The iterators map and fold are parametrizedby a ZQL expression, conceptually acting as the body ofthe corresponding loop. (We write these expressions asfunctions, but they can only specialize the iterator; theycannot be assigned to variables.)

Query inputs and expression results are specified us-ing tuples of typed variables (θ for query inputs and ρfor sub-expressions). Each base type can be marked as

public, and is otherwise treated as private. Types also in-clude tables, where ρ indicates the type of each row inthe table. Tables can contain mixtures of public and pri-vate columns; for example, (time:int pub, reading: int) tableis the type of tables of private readings indexed by pub-lic times. On the other hand, the current ZQL compilerdoes not attempt to hide the query definition itself, or thenumber of rows in tables.

Intermediate expressions are automatically classifiedas public or private, depending on the types of their vari-ables, following a standard information flow discipline:public inputs can flow to private results, but not the con-verse. Alternatively, a ZQL expression can be explicitlydeclassified, using the special operator ↓ e which speci-fies that the result of e can be released to the verifier, andmarks it as public.

A ZQL query itself defines the privacy goals of thesynthesized zero-knowledge protocols. For example, aquery θ →↓ e, where e does not contain any declassi-fication, states that only the final result of the query isreleased, and that the protocol should not leak any sideinformation on inputs marked as private in θ . A key fea-ture of the language is that the underlying cryptographicmechanisms are totally hidden in the definition of theZQL query. Since the ZQL query defines what resultsare declassified, it is important that users, or their prox-ies, review it to ensure no more than the necessary in-formation leaks from it. Additional privacy mechanisms,such as differential privacy [37], could be used to mea-sure or minimize any leakage resulting from the querydeclassification.

The ZQL language is strongly typed, with a type sys-tem simple enough to allow for automated type checkingand type inference, which means that the programmeronly has to write the input types of the query. We writeΓ � e : ρ to state that expression e has type ρ in environ-ment Γ. The type system ensures both runtime safety: ereturns only to values of types ρ , and non-interference:in the absence of declassification, e does not leak inputstyped as private in Γ to results typed as public in ρ . Thetype system can also be used to track the maximal lengthof private variables to statically prevent arithmetic over-flows. We omit the formal definition of the languagesemantics and type system, which are standard. Inter-nally, ZQL relies on a richer type system with refine-ments types [14, 42] to keep track of various propertiesand to structure our security proofs—see the full paper.

ZQL by example We present the ZQL language andsemantics through simple concrete examples, building tofuller queries that address problems in the literature in §7.The first example query computes the discriminant of thepolynomial xk2 + zk+ y, for public x and private y and z.

let discriminant (x:int pub) (y:int) (z:int) = ↓ (z∗z − 4∗x∗y)

3


Anticipating on its compilation, the part of the expres-sion that is linear in the secrets, namely −4 ∗ x ∗ y, canbe proved efficiently through homomorphisms of Peder-sen commitments, while the non-linear z ∗ z requires aΣ-protocol to prove the correctness of the private multi-plication. The ZQL compiler will choose to synthesizethe right proof mechanisms for each case.

The query declassifies its result, which leaks some in-formation about y and z. For instance, given x = 30 anddiscriminant x y z = 1000, if the verifier knows a priori that0≤ y< 200 and 0≤ z< 200, then it can infer that (y,z) isone of the pairs (5,40), (45,80), (75,100) or (155,140),but our privacy theorem ensures that its does not learnwhich pair was actually used.

Our next examples illustrate the use of tables and it-erators map and fold. The first query computes the sumof all integers in table X , while the second returns thesum of their squares. The third query takes a table with apublic column and two secret columns and returns a tablewith the same public column, and the element-wise sumof the secret columns. By design, the size of the tablesis not hidden by ZQL. (Hiding table sizes naively wouldinvolve padding the computation to the maximum size ofallowed tables, which would be very expensive.)

let sum of x (X : int table) =↓ (fold ((s, x) →s + x) 0 X)

let sum of square (X : int table) =↓ (fold ((s, x) →s + x∗x) 0 X)

let linear (T: (int pub ∗ int ∗ int) table) =↓ (map ((a,x,y) →a, x+y) T)

In these queries, the iterators are parametrized by a sub-query, which is applied to every row of the table, accu-mulating the sums in s, or building another table of re-sults. The equivalent SQL statements would be writtenselect SUM(x) from X, select SUM(x*x) from X, and se-

lect a, x+y from T. The first and third queries computelinear combinations of secrets; we compile them withoutthe use of any expensive Σ-protocols.

We found sum queries to be frequent enough to jus-tify some derived syntax: we write sum (ρ → e) T assyntactic sugar for fold (s,ρ → s+ e) 0 T .

A key feature of the ZQL language is the ability toperform lookups on input tables. This provides a lim-ited form of join and enable the computation of arbitraryfunctions with small domains. The expression lookup x Tfinds a row x,v1, . . .vn in T that matches x, and returnsv1, . . . ,vn. From an information-flow viewpoint, the re-sult of a lookup on a private variable is also private (evenif the lookup table is public); in that case, ZQL leaksno information about which row is returned. If multi-ple rows match x, the verifier is only able to assert thatany matching row was used. If no row matches x, a run-time exception is raised on the prover side, and the prooffails. This semantics allow the implementation of func-

tions, set membership tests, and half-joins.To enable lookups, each row of the input table cur-

rently needs to be signed using a re-randomizable signa-ture by a trusted source, so these tables are given a spe-cial type (ρ lookuptable) and lookups on intermediate,computed tables are not supported.

The example blur, listed below, repeatedly uses alookup to map private city identifiers to their respectivecountries; the resulting table is then declassified.

let blur (X: int table) (F: (int ∗ int) lookuptable ) =↓ (map (city → lookup city F) X)

The equivalent SQL statement would be select F.country

from X, F where F.city = X.city. The query implementa-tion relies on a data source that issues a signed table fromcities to countries.

3 Security

The next two sections provide rigorous security defini-tions for what the ZQL compiler achieves and the crypto-graphic building blocks it uses, necessary for formulatingour security theorems in §6. The mere fact that we cangive formal cryptographic definitions for a large class ofcryptographic protocols relies on our simple expressionlanguage having a formal semantic for both source andcompiled programs. Readers interested in compiler ar-chitecture can jump straight to §5, or those curious aboutapplications can find them in §7.

Notations Consider a well-typed ZQL source queryQ

�= θ →↓ e, with � input variables θ = (xi : τi)i=0..�−1,

that declassifies only its result. As explained in §2, thetyped variables θ specify the data sources and privacypolicy. Let �T range over values of type θ , and R =Q(�T )be the corresponding query result. Given Q, our com-piler produces queries (S,(Ki,Di)i=0..�−1,P,V) with for-mal parameters indicated in parentheses as follows. (Weuse primed variables for compiled values.)

• S, the setup generator, generates global parametersχ used by the commitment scheme;

• (Ki)i=0..�−1, the data sources key generation, gener-ate key pairs ski,vki := Ki(χ) used to sign data andverify their signatures;

• (Di)i=0..�−1, the data sources, extend and sign eachinput: T ′

i := Di(χ,ski,Ti);

• P, the prover, produces an extended result from ex-tended inputs: R′ := P(χ, �vk,�T ′);

• V, the verifier, returns either some source resultR := V(χ, �vk,R′) or a verification error.

Main Properties We first define functional correctnesswhen all participants comply with the protocol.

4


Definition 1 (S,(Ki,Di)i=0..�−1,P,V) correctly imple-ments the source query Q when, for any source inputs�T : θ and χ := S, (ski,vki := Ki(χ))i=0..�−1, we have

V(χ, �vk,P(χ, �vk,Di(χ,ski,Ti)i=0..�−1)) = Q(�T ).

We define privacy as indistinguishability between twoseries of chosen inputs that yield the same query result.

Definition 2 Given a source query Q and an adver-sary A , let AdvPriv

A = |2Pr[A wins]−1| where the event‘A wins’ is defined by the following game:

(1) The challenger runs S and Ki to generate setup χand keys �sk, �vk; it provides χ and �vk to A .

(2) The adversary A provides two vectors of input data�T 0 : θ and �T 1 : θ such that (a) they coincide on pub-lic data and (b) Q(�T 0) = Q(�T 1).

(3) The challenger picks a random bit b, encodes thecorresponding inputs �T ′ := (Di(χ,ski,T b

i ))i=0..�−1,and generates R′ := P(χ, �vk,�T ′).

(4) Given R′, A returns his guess b′, and wins iff b= b′.

(S,(Ki)i=0..�−1,(D)i=0..�−1,P,V) is (t,ε)-private when,for all A running at most for time t, we have AdvPriv

A ≤ ε .

Note that we do not formally provide privacy protectionagainst corrupted data sources. To strengthen our schemeagainst data source attacks, we would have to rerandom-ize all cryptographic material flowing from data sourcesto verifiers, which precludes our efficient use of homo-morphic commitments.

We define integrity as a game in which an adversaryhas to produce an invalid but accepted response.

Definition 3 Given a source query Q and an adver-sary A , let AdvSnd

A = Pr[A wins] where the event‘A wins’ is defined by the following game:

(1) The challenger runs S and Ki to generate setup χand keys �sk, �vk; it provides χ and �vk to A .

(2) The adversary A can adaptively corrupt datasources Di to get their signing keys ski and, atthe same time, it can obtain signed inputs T ′

i :=Di(χ,ski,Ti) for source inputs Ti : τi of its choice.

(3) Valid results are source values R = Q(�T ) suchthat, for each i, either i was corrupted or Ti wassigned. The adversary wins if he outputs R′ suchthat V (χ, �vk,R′) returns any invalid result R�.

(S,(Ki)i=0..�−1,(D)i=0..�−1,P,V) is (t,ε)-sound when,for all A running at most for time t, we have AdvSnd

A ≤ ε .

Depending on the adversary, there can be zero, one,or numerous valid responses. In fact, depending on thequery and the input tables, whether a response is validmay not even be efficiently checkable. The definition is,however, still meaningful.

4 Main Cryptographic Tools (Review)

Signatures A digital signature scheme allows every-one in possession of the verification key vk to verify theauthenticity of data signed by the owner of the corre-sponding signing key sk. We use signatures to let veri-fiers authenticate data sources. Instead of signing privatedata in the clear, data sources sign public commitments;thus, the resulting signature tags are also public.

Cryptographic groups Besides conventional digitalsignatures, for which we use standardized schemes, ourremaining cryptographic tools can either be specified forcomposite order groups, obtained by computing moduloan RSA modulus, or for prime order groups with a bi-linear pairing. We use the latter for our presentation andformal analysis as it offers both performance and con-ceptual advantages.

Let G, G, and GT be groups of prime order q. Letg ∈ G and g ∈ G be generators of G and G respectively.A bilinear pairing is an efficiently computable functione : G∗G→GT that is bilinear, i.e. ∀a,b∈Fq : e(ga, gb)=e(g, g)ab and non-degenerate, i.e. e(g, g) �= 1. Wheneverpossible we perform all operations in the base group Gwith the shortest representation.

Commitments A commitment scheme allows a user tocommit to a hidden value such that he can reveal the com-mitted value at a later stage. The properties of a commit-ment scheme are hiding: the committed value must re-main hidden until the reveal stage, and binding: the onlyvalue which may be revealed is the one that was chosenin the commit stage. We use the perfectly hiding commit-ment scheme proposed by Pedersen [54]: given a groupG of prime order q with generators g and h, generate acommitment Cx to x ∈ Fq by sampling a random openingox ← Fq and computing Cx = gxhox. The commitment isopened by revealing both x and ox.

Two useful properties of Pedersen commitments are(i) their homomorphic property that allows to derive acommitment to the linear combination of input values;and (ii) their algebraic structure that allows for efficientzero-knowledge proofs. For RSA groups, we use com-mitments with similar properties [43, 34].

Zero-knowledge proofs [59, 39, 11] provide a verify-ing algorithm with an efficient means for checking thetruth of a statement by guaranteeing that given accessto a successful proof generation algorithm one can ex-tract a secret witness for said truth. At the same time,zero-knowledge proofs [47, 46], and the related conceptsof witness indistinguishable proofs [38, 32], allow theprover to keep this witness secret. We make use of along line of work on efficient proofs of conjunctions ofdiscrete logarithm (DL) representations [57, 28, 52, 32,30, 18, 26, 33, 50]. For non-linear computations such as

5


multiplication, we use the approach of Brands [18], Ca-menisch [26], and Cramer and Damgard [31].

DL representation proofs are interactive protocols ofthree or more messages. To ease deployment and min-imize communications, we use the Fiat-Shamir Heuris-tic [40] and replace random messages sent by the verifierwith hash function computations. The resulting proto-cols can still be formally analyzed in the random oraclemodel [12, 62].

Proof compatible signatures The combination ofzero-knowledge proofs and digital signatures allows usto prove authentication properties on private data, suchas, for instance, the existence and properties of a match-ing row when performing a private lookup.

We use CL signatures [20], as they are compatiblewith DL representation proofs. The original scheme wasproven secure under the Strong RSA assumption and re-quires groups with hidden order [6, 24]. Other CL signa-ture proposals rely on a variety of assumptions based onbilinear pairings [21, 17, 3, 25] and require more stan-dard prime order DL-representation proofs. We also usethe scheme of [25], a good trade-off between security andperformance. An additional benefit is that it is syntacti-cally very close to RSA-based CL signatures.

To certify our lookup tables, data sources extend eachrow of the table with a CL signature. For instance,tables of triples of private integers (x0,x1,x2) are ex-tended to tables with rows of the form (x0,x1,x2,e,v,A).The verification equations for RSA and bilinear pairingbased CL signatures are of the form Z = AeRx0

0 Rx11 Rx2

2 Sv

and e(Z, g) = e(A,pk∗ge)e(Rx00 Rx1

1 Rx22 Sv, g) respectively,

where (Z,R0,R1,R2,S,pk) are group elements that formthe components of the verification key vk. Both verifi-cation equations can be proven using efficient DL repre-sentations. The security of these two schemes is based onthe strong RSA assumption and the strong Diffie-Hellman(SDH) assumption respectively.

5 Compiler ArchitectureProtocol Overview The ZQL compiler takes a sourcequery, which contains no cryptographic computations,and automatically produces programs for each datasource, for the prover, and for the verifier.

First, the compiler augments the source query withvarious cryptographic commitments to secrets and repre-sentation equations to generate a shared translation thatwill lead to both prover and verifier code. Some com-mitments are computed and signed by the data sourcesthat certify the computation inputs, and simply passed tothe prover and verifier programs. Others, representingintermediate secrets in the query, are interleaved with thesource computation: for any such secret x, the provermay sample a secret opening ox, compute a Pedersen

commitment Cx =G gxhox, and send it to the verifier; andthe verifier may check it using a zero-knowledge proof.

Linear relations between secrets do not require com-plex zero knowledge proofs, as they can be checked bythe verifier simply by using the homomorphisms of Ped-ersen commitments. For example, a private sum z= x+ywill have commitment Cz =G Cx ∗Cy. Such commit-ments need not be transmitted, as they can be recom-puted by the verifier. On the other hand, non-linear re-lations between secrets, including multiplication and ta-ble lookup, require Σ-protocol proofs to be synthesized.For instance, to prove that z is the product of a secret xcommitted in Cx and a secret y, one proves the con-junction of the representation equations Cx =G gxhox and1 =G (Cx)

−ygzhoz. Note that the second equation uses avariable commitment Cx as a base.

All Σ-protocols used in the compiler come down toproving knowledge of the secret values underlying thediscrete logarithm representations of public group el-ements, and equality relations between the secret val-ues. Assume the ZQL query reduces to proving in zero-knowledge the representations �C =G �e[x] of a number ofcommitments �C, represented by public group elements,using a number of secrets x (including secret openings).For the multiplication example above, we have two equa-tions on five secrets: �C ≡ (Cx,1), x ≡ (x,ox,y,z,oz)and �e[(α,β ,γ,δ ,ε)] ≡ (gα ∗ hβ ,C−γ

x gδ hε). The zero-knowledge protocol synthesized works as follows. Theprover

(1) samples a vector of random values t, one for eachsecret in x; We call t values the proof randomness;

(2) computes the challenge c = H(�e[t]);(3) computes the responses r = t − c∗ x, for all secrets.

The proof sent to the verifier consists of the public pa-rameters and values, the commitments �C, the global chal-lenge c, and the responses r. The verifier checks thatH(�Cc ∗G�e[r]) = c, which ensures that the prover knowsthe secret values in the commitments [40, 12]. As de-tailed below, our compiled prover and verifier programsintroduce secrets and process equations on the fly, de-pending on the query and its inputs.

Once the shared translation is decided, its specializa-tion into prover and verifier code is relatively straight-forward. It involves mainly ensuring the right data flowswithin the query processing to compute all commitmentsand responses, and to correctly verify them in the sameorder. The inputs of the shared translation also deter-mine the data source programs that generate keys, com-pute commitments, and sign extended data.

Embedding cryptography within ZQL Our compilermostly operates within ZQL, with F# and C++ back-endsto turn the compiled queries into executable code. This

6


e ::= . . . Expressions| assert ϕ;e static assertion

op ::= . . . Operators| −1,0,1, . . . constants| sample | random | div exponents (mod q)| *G |=G| expG group operations| e : G∗ G → GT EC bilinear form| extend | finalize cryptographic hash| keygen | sign | verify plain signatures| mapP | mapV| foldP | foldV translated iterators

τ ::= . . . Types| num | x opening | x rand exponents (mod q)| eltG | x ox commitment group elements| hash cryptographic hash| tagi | ski | vki plain signatures

Figure 3: ZQL internal constructs

enables us to reason about code in a simple, domain-specific language. To this end, Figure 3 supplementsthe source language of Figure 2 with the types and op-erators for expressing cryptographic operations. Expres-sions are extended with assert, used in the shared trans-lation to embed proof obligations. As an invariant, allasserted equations ϕ must hold at runtime. We havetypes and operations for integers modulo q (Fq, writtennum), for group elements (eltG), and for bitstrings, andmore specific sub-types to keep track of their usage. Forinstance, hash is the sub-type of bitstrings representingcryptographic hashes, and xopening is a sub-type of numtracking openings generated for the secret value x. In ourpresentation, we use standard abbreviated forms for theiroperations; for instance we often omit group parameters,writing gx for expG g x.

Setup and Key Generation The abstract setup S pro-duces global parameters χ supplied by our cryptographicruntimes, including q, the prime order of G, G, and GT ;and independent, random generators g, h, (Ri)i=0..n, S,Z in G; and g in G. Its fixed code is provided by ourcryptographic libraries.

We use DLT ⊆ 0..�− 1 to denote the subset of datasources that sign lookup table. The key generationKi is defined as keygen χ when τi is a scalar or a ta-ble (i /∈ DLT ), and as the CL-key generation let sk =sample() in sk,(g)sk when τi is a lookup table (i ∈ DLT ).The data source code Di is explained below, as we dis-cuss these two representations.

Shared Translation We extend the source query withopenings and commitments, but not yet with the corre-sponding proof randomness and responses.

The main difficulty of the translation is to select cryp-tographic mechanisms, and notably intermediate com-

mitments, to run the private computation: for every pri-vate sub-expression, our compiled protocol may rely onzero, one, or more Pedersen openings and commitments,and it may allocate some proof randomness or not.

In this presentation, for simplicity, we give a formaltranslation that assumes that all source private integervariables are handled uniformally, with a commitment inthe same group, sharing the same bases, and (later) witha proof randomness for the secret and for its opening.Figure 4 and 5 show how we translate types and expres-sions, respectively, in this special case. We discuss ourgeneral, more efficient compilation scheme below.

A source expression is public in a typing environmentwhen all its free variables have public types. The trans-lation leaves public types (1) and expressions (3) un-changed. The translation of a private integer expressionis a triple of an integer for the source value, its opening,and its commitment, with the types given on line (2).Fresh commitments Our compilation rules may requireopenings and commitments on their arguments, and maynot produce openings and commitments on their re-sults. Our compiler attempts to minimize those cases.Nonetheless, assuming for instance that we need a com-mitment for z, we produce it on demand, using the ex-pression abbreviation Commit z below

Commit z �=

let oz : z opening = sample() inlet Cz : zoz commitment = gz ∗G hoz inassert Cz = gz ∗G hoz;z,oz,Cz

The translation is compositional, as can be seen onlines (4,5,6) in the figure. For instance, we translate letexpressions by translating their two sub-expressions, andwe translate source maps to maps that operate on theirtranslated arguments.

The translation assumes prior rewriting of the sourcequery into simpler sub-expressions. For instance, tocompile the discriminant query of §2, we first introduceintermediate variables for the private product and the de-classification, rewriting expression ↓ (z∗z−4∗x∗y) into

ed�= let p = z∗ z in let d = p−4∗ x∗ y in ↓ d.

As a sanity check, our translation preserves typing, inan environment extended with the constants used in ourcryptographic libraries; variants of this lemma with moreprecise refinement types for the prover and verifier trans-lation can be used to verify their privacy and integrity.

Lemma 1 (Typing the shared translation) Let Γ0�=

g,h,Z,R0, . . .Rn,S : eltG, g,(pki)i∈DLT : eltG. If Γ � e : ρ ,then Γ0, [[Γ]] � [[Γ � e]] : [[ρ]].

Next, we explain and illustrate the base cases of theshared translation on private expressions.

7


[[x : τ{ϕ}]] = x : τ{ϕ} when τ is public; (1)

otherwise:

[[x : int{ϕ}]] = x : int{ϕ},ox : x opening,Cx : x ox commitment

(2)

[[ρ table]] = [[ρ]] table,s : tag

[[ρ lookuptable]] = (ρ,σ) table

σ = e : num,v : num,A : eltG[[ε]] = ε

[[x : τ{ϕ},ρ]] = [[x : τ{ϕ}]], [[ρ]]

Figure 4: Shared translation of types and environments

Expressions affine in private variables are translatedby supplementing the expression with a linear expres-sion on openings and an homomorphic product of com-mitments (7); we easily check that the resulting triple(z,oz,Cz) is such that Cz = gz ∗G hoz. Note that the publicconstant a0 is not included in the opening computation.

Expressions polynomial in private variables are trans-lated using an auxiliary representation equation for everyproduct of private expressions, depending on the avail-ability of openings and commitments—see translationrule (8). To illustrate affine and quadratic expressions,let us translate the discriminant query θ → ↓(ed) wherethe source environment θ = x : int pub,y : int,z : int spec-ifies that x is public, whereas y and z are private. Bydefinition, the translated environment [[θ ]] is

x : int pub,y : int,oy : y opening,Cy : y oy commitment,z : int,oz : z opening,Cz : z oz commitment

and, from the translation invariant, we already know thatCy =G gyhoy and Cz =G gzhoz. Applying rules (4), (8), (7),and (10) and inlining the definition of Commit we arriveat the shared translation

let p, op , Cp =let p = z∗z inlet o′ = oz∗ z inassert 1 = (Cz)

z ∗G g−p ∗G h−o′ ; (E1)let op = sample() inlet Cp = gp ∗G hop inassert Cp = gp ∗G hop; (E2)(p, op, Cp)

let d, od , Cd =(p−4∗ x∗ y),(op−4∗ x∗oy),(Cp ∗C−4∗x

y )

↓ d

and we easily check that Cd is a commitment to z2 −4xywith opening op−4x∗oy. The code of the shared transla-tion makes explicit the two representation equations forthe private multiplication, presented more abstractly atthe beginning of §5. Anticipating on the next stages of

[[Γ � e]] = e when e is public (3)

[[Γ � x]] = [[Γ(x)]] otherwise

[[Γ � let ρ = e in e0]] = (4)

let [[ρ]] = [[Γ � e]] in [[Γ,ρ � e0]]

[[Γ � map (ρ → e)T ]] = (5)

map ([[ρ]] → [[Γ,ρ � e]]) [[Γ � T ]]where Γ(T ) = ρ table and Γ,ρ � e : ρ ′

[[Γ � fold (a : τ,ρ → e)a T ]] = (6)

fold ([[a : τ,ρ]] → [[Γ,a : τ,ρ � e]])[[Γ � a]] [[Γ � T ]]

where Γ(T ) = ρ table and Γ,a : τ,ρ � e : τ

[[Γ � a0 +∑ni=1 ai ∗ xi]] = (7)

a0 +∑ni=1 ai ∗ xi,

∑ni=1 ai ∗oxi,

ga0 ∗G ∏nG,i=1(Cxi)

ai

when the ai are public and the xi private

[[Γ � x∗ y]] = (8)

let p : int = x∗ y inlet o′ : num = ox∗ y inassert 1 = (Cx)

y ∗G g−p ∗G h−o′ ;Commit pwhen x and y private

[[Γ � lookup x0 Ti]] = (9)

let x1, . . . ,xn,e,v,A = lookup x0 Ti inlet d,od,Cd = Commit (random()) inlet p = d ∗ e inlet o′ = od ∗ e inassert 1 =G Cd

eg−ph−o′

let A′ = A∗h−d inassert e(Z, g)e(1/A′,pki) =GT

(∏ni=0 e(Ri, g)xi)e(A′, g)e

e(S, g)ve(h, g)pe(h,pki)d

Commit x1, . . . ,Commit xnwhere Γ(Ti) = (xi : int)i∈0..n−1 lookuptable

[[Γ �↓ x]] = ↓ x when x private (10)

Figure 5: Shared translation of typed source expressions

the translation, the prover will compute Cp, pass it to theverifier, and extend its challenge computation with equa-tion E2, whereas the verifier will receive some Cp anduse it to check this equation. Note that the cryptographicoverhead depends on the target level of privacy: giveninstead a source environment θ declaring that x is alsoprivate, the same discriminant expression would involverepresentation proofs for two private products.

Private lookups are translated using proofs of knowl-edge of signatures. To enable this, data sources extendinput tables T : ρ lookuptable, where ρ is of the formx0 : int, . . . ,xn : int, into tables T ′ : (ρ,σ)table with a CLsignature at the end of each row, as follows:

8


Di�= χ,sk,T → map (x0 . . . xn →

let e = random() inlet v = random() inlet A = (∏n

G,i=0 Rixi SvZ−1)

1sk+e in

x0, . . ., xn, e, v, A)T

Although this pre-processing may be expensive for largetables, it can be amortized over many queries.

A lookup within a source query, such as the one fromthe blur query of §2, is translated to a proof of posses-sion of a CL signature. For instance, let us translate theexpression lookup c F in environment

ρ = F : (city : int,country : int) lookuptable,c : int.

The environment is first translated to

[[ρ]] = (city : int,country : int,σ)table,c : int,oc : c opening,Cc : c oc commitment

The lookup itself is translated (using rule 9) to[[Γ � lookup c F ]]=

let country, e,v,A = lookup c F inlet d, od, Cd = Commit(random()) inlet p, o′ = d ∗ e, od ∗ e inassert 1 =G Cd

eg−ph−o′ ;let A′ = A∗h−d inassert e(Z, g) · e(1/A′,pki) =GT

e(R0, g)c · e(R1, g)country·e(A′, g)e · e(S, g)v · e(h, g)p · e(h,pki)

d ;Commit country

This code first looks for a signed tuple (city,country,e,v,A) in F such that c = city and retrieves the remainingelements; it then proves knowledge of this tuple, withoutrevealing which tuple is used in the proof, by blindingthe element A of the signature. (Note that this proof in-ternally relies on a proof of multiplication.)Iterators and Committed Tables ZQL supports tableswith mixed public and private columns, as well as itera-tors map and fold. To enable processing on their privatecontents, data sources extend tables with commitmentsand sign them. For instance, here is the code for theprovider of the table of cities for the blur query.

Di�= χ,sk,X →

let X ′ = map (x: int →Commit x) X inlet H = fold (H,x,ox,Cx →extend H Cx) H0 X ′ inX ′, sign sk H

This code first uses map to extend each source inte-ger with a fresh opening and commitment, using theCommit abbreviation; this yield the extended table X ′

passed to the prover. It then uses fold to compute thejoint hash of these commitments, and finally signs the re-sult. (In the hash computation, H0 is some fixed tag, andwe omit a conversion from eltG to hash). As outlinedat the end of this section, both the prover and the veri-fier perform some initial processing for these extended

tables: the prover must show his knowledge of the repre-sentation for these commitments, and the verifier mustverify the signature and the representation proofs forthese commitments.

We illustrate the translation of the map iterator (5) onthe blur query from §2. The translation of fold (6) issimilar. The map expression of blur is translated to an-other map expression, in a translated environment thatprovides the extended input X : [[x : int]] table:

[[Γ � map(c → lookup c F) X ]] =map (c,oc,Cc → [[Γ,c : int � lookup c F ]])X

and the translation continues with the lookup expression,as explained above.

Prover Translation Continuing from the result of theshared translation, the prover translation uniformly turnsits assertions into a custom non-interactive Σ-protocol, intwo passes, written [[ ]]1 and [[ ]]2, that produce code firstfor the message randomness, then for the responses.

Figure 6 defines these two passes, as well as the top-level query translation [[ ]]PROVER that combines [[ ]]1and [[ ]]2 with additional glue. Overall, the prover for asource query θ → e is thus defined using this translationafter the shared translation: P �

= [[ [[θ � e]] ]]PROVER.First-message translation In the first pass, H is the pub-lic hash incrementally computing the global challenge;a is the accumulated cryptographic evidence that will besent to the verifier; and every private variable x is re-placed with a pair x, tx where tx is the proof random-ness for x. (Openings are treated as any other secrets.)In combination with the shared translation, every privatesource expression becomes a tuple of the form [[[[e]]]]1 :(x, tx,ox, tox,Cx) where x is the value of e, tx is the ran-domness for x, ox is an opening for x, tox is the random-ness for ox, and Cx is a commitment to x. For efficiency,all these additional values are optional in our compiler.

Compositionally, the type translation [[ρ]]1 mapsshared environments to environments extended with anentry for each proof randomness, and leaves the other en-tries unchanged; the expression translation [[ ]]1 takes Hand a as free variables and returns their updated values ofthe form extend . . . (extend H E1) ... En, with one exponen-tial expression Ei for each assertion in e, and a, a1, . . .am

for each additional evidence a j produced by e.We explain the main cases of the first-pass translation.

Public expressions are (still) unaffected. Note that theymay includes public expressions generated by the sharedtranslation, such as products of commitments. Affine pri-vate expressions are translated homomorphically, addinga corresponding linear expression on the proof random-ness. Private exponential computations yields evidencethat must be communicated to the verifier; we add theirresults to a. More complex private expression are supple-mented with the sampling of a fresh message randomness

9


for their result—we rely on the assertions introduced bythe shared translation to prove those expressions.

Assertions of equations of the form eP = ex are trans-formed into extensions of the global-challenge compu-tation. The left-hand-side must be a public expression,and is discarded. The right-hand-side must be an ex-pression on private variables. Let et be the expressionsobtained by replacing each of theses variables x with tx.The translation computes it, and extends H with the re-sult. Declassifications are similarly translated: the de-classified value x is added to a, and the hash is extendedwith gtx to link it to its proof randomness (as if we weretranslating assert gx=gx). Continuing with our example,we give below the expression e1, obtained by translatingthe shared-translation of the discriminant query, after re-moving the unnecessary commitment Cd . (This code hasbeen rearranged for simplicity; the full code produced bythe translation rules appears in the full paper.)

let p = z∗z inlet tp = random() inlet o′ = oz ∗ z inlet to′ = random() inlet H = extend H ((Cz)

tz ∗G g−tp ∗G h−to′ ) inlet op = sample() inlet top = random() inlet Cp = gp ∗G hop inlet H = extend (extend H Cp) (gtp ∗G htop) inlet d = p−4∗ x∗ y inlet td = tp − 4 ∗ x ∗ ty inlet H = extend (extend H gd) gtd inlet a = a, (p,tp), (o′,to′ ), (op, top), Cp, d in(H, a, d)

Response Translation In the second pass, after complet-ing the computation of the global challenge c, we revisitthe collected evidence a, and we replace every pair of aprivate value x and associated proof randomness tx withthe response rx = tx−c∗x. This pass is defined by induc-tion on the type of a, produced by the first-message trans-lation, which indicates where those pairs are. (Techni-cally, this pass also needs to re-balance nested tuples, asthe prover produces (. . .(a0,a1),a2, . . . ,an) whereas theverifier consumes (a0,(a1,(. . .an) . . .)); we omit thosedetails.) Continuing with the discriminant prover, the re-sulting evidence a : δ binds the series of variables

(z, tz), (oz, toz), (p,tp), (o′,to′ ), (op, top), Cp, d

and thus [[δ ]]2 simply computes the responses for the fivepairs of secret and associated proof randomness:

[[δ ]]2�= let (z,tz), (oz,toz), (p,tp), (o′,to′ ), (op, top), Cp, d = a

let rz = tz − c∗ zlet roz = toz − c∗ozlet rp = tp − c∗ plet r′o = to′ − c∗o′

let rop = top − c∗op(rz, roz, rp, ro′ , rop, Cp, d)

Top-Level Prover Translation (P) We arrive at the fol-lowing code for the prover, given here for the discrim-inant query. (See Figure 6 for the general case.) Thisprover relies on data sources extending both privatesource inputs y and z with an opening, a commitment,and a signature on that commitment

x, (y, oy, Cy, σy), (z, oz, Cz, σz) →let H = extend (extend H0 Cy) Czlet tz = random()let toz = random()let a = (z, tz), (oz, toz)let H = extend H (gtz ∗G htoz)let H, a: δ , d = [[[[θ ]] � [[e]]]]1 // phase 1 detailed abovelet c = finalize H inlet a = [[δ ]]2 // phase 2 detailed above(x, (Cy, σy), (Cz, σz), a, c)

In this code, H0 is the hash of all public values used asbases in the Σ-protocol, [[θ ]]D is the tuple type of the(extended) provided data, and [[θ ]]pub is an expressionthat extracts their public parts (including the plain signa-tures, excluding lookup tables). The type δ of the ad-ditional evidence depends on the first-pass of the transla-tion, and is used to drive the second part. In-between, thefinal value H : hash is finalized into the global challengec : num. The last line assembles the message passed fromthe prover to the verifier, which consists of (1) the publicparts of the input data and of the result; (2) the additionalevidence for proving this result; and (3) the global chal-lenge for verifying this proof.

Verifier Translation Also following the shared trans-lation, the prover translation leaves the public parts ofthe query unchanged, and it incrementally re-computesthe challenge using the responses and additional evi-dence prepared by the prover for the private parts of thequery. Figure 7 gives the compositional translation ap-plied to the result of the shared translation, and the top-level translation [[ ]]VERIFIER. In combination, the verifieris defined as V �

= [[ [[θ � e]] ]]VERIFIER.Compositional translation [[ ]]v In the verification pass,H is the public hash incrementally re-computing theglobal challenge, a is the received evidence consumedby the verifier, and every private variable x is replacedwith a (public) response variable rx—the type translation[[ρ]]v performs this replacement. In combination with theshared translation, every private source expression nowyields a tuple of the form rx,rox,Cx where rx and rox are(presumably) responses associated with the exponentscommitted to Cx. (Again, all these values are actuallyoptional in the compiler.)

The verifier expression [[e]]v takes free variables Hand a, and additionally returns the updated H and the restof a. Public expressions are unchanged. Private expres-sions are discarded, and replaced with response expres-sions, either computed (for affine expressions) or read

10


off the evidence a (for more complex expressions). Notethat the translation of affine expressions includes a term−c∗a0 for the constant, to ensure that, given correct re-sponses for its free variables, the translation of an expres-sion also produces a correct response.

Assertions of equations of the form eP = ex are trans-lated to hash computations, by computing the expression(eP)

c ∗ er, where er is obtained from ex by replacing ev-ery variable x with rx, and by extending H with the result.Declassifications ↓ x are similarly translated by reading xoff the evidence a and extending the hash with gx+c∗rx .

For instance, continuing with the discriminant query,the (simplified) verifier translation [[[[ρ]] � [[ed ]]]]v is

let rp,ro′ ,rop, Cp, d, a = a inlet H = extend H ((Cz)

rz ∗G g−rp ∗G h−ro′ ) inlet H = extend (extend H Cp) ((Cp)

c ∗G grp ∗G hrop) inlet rd = rp − 4 ∗ x ∗ ry inlet H = extend (extend H gd) ((gd)c ∗G grd ) in(H, a ,d)

Top-Level Verifier We finally give below the top-levelverifier translation, also for our sample discriminantquery; see Figure 7 for additional details.

x, Cy, σy, Cz, σz, a, c →verify vky Cy σy;verify vkz Cz σz;let H = extend (extend H0 Cy) Czlet rz, roz, a = a inlet H = extend H Cc

z ∗G grz ∗G hroz in

let H, a, d = [[[[θ ]] � [[e]]]]v in // translation detailed abovecheck c = finalize H;d

The prover first verifies the signatures on the two re-ceived commitments for y and z; it starts the challengere-computation on the representation equation for input z(since we need a response for z an oz to check the proofof the square z2), then proceeds with the verification forthe query expression; it checks that the received and re-computed challenges match; it finally returns the publicresult d (unless of course verify or check raised an error.)

6 Security TheoremsConsider a well-typed ZQL source query Q

�= θ →↓ e,

with � input variables θ = (xi : τi)i=0..�−1, that declassi-fies only its result and its translation (S,(Ki,Di)i=0..�−1,P,V). We give our main results based on the definitionsof §3. We refer to the full paper for the proof outlines,and for a discussion of automated, type-based verifica-tion for the compiled protocols. For functional correct-ness and soundness, we also suppose that there is nosource-program overflow—formally, integers and theiroperations are computed modulo q.

Theorem 1 (Functional Correctness)(S,(Ki,Di)i=0..�−1,P,V) is correct.

Theorem 2 (Perfect Privacy)(S,(Ki,Di)i=0..�−1,P,V) is (t,0)-private.

Our soundness theorem below is in the random-oraclemodel, requiring that extend and finalize are indepen-dent random oracles. It assumes that the Discrete Loga-rithm (DL) and Strong Diffie Hellman (SDH) assump-tions hold—to guarantee the security of commitmentsand CL signatures, respectively—and assuming that the�CMA conventional signatures primitives of data-sourcesare chosen message attack secure (CMA).

Theorem 3 (Computational Soundness)(S,(Ki,Di)i=0..�−1,P,V) is (t,ε)-sound, where theexecution time t and success probability ε are respec-tively lower- and upper-bounded by the correspondingparameters of the assumptions.

Concretely, let tDL, tSDH , tCMA and εDL, εSDH , εCMAbe those parameters, for large enough bounds on thenumber of calls to their primitives. If t < tCMA − tred1,t < (tDL − tred2)/2, and t < (tSDH − tred3)/2, where thetredi are small constants, then ε < �CMA · εCMA + Q ·√

εDL +(�− �CMA) · εSDH +Q2/q, where Q is the num-ber of random oracle queries made by A and q is theorder of G and thus also the size of the challenge.

In contrast with our privacy theorem, which isinformation-theoretic, our concrete-security soundnesstheorem is somewhat more cumbersome than the asymp-totic security theorems often found in theoretical cryp-tography, but it remains closer to reality, in which cryp-tographic primitives come with concrete security bounds,and thus provides guidance for configuring these primi-tives to achieve adequate security.

7 ZQL applicationsThe expressivity of ZQL stems from the ease with whichthe primitive operators can be composed to build largerqueries. We illustrate this by providing queries for appli-cations in prior literature.

In the setting of smart metering, a meter issues signedprivate readings, and a household needs to compute theirbill on the basis of a public tariff policy that maps eachreading to a fee over time. A number of custom privacyprotocols have been proposed to do this [55, 48]. Onesuch billing policy takes a table of public times and pri-vate readings, as well as a lookup table from readings toprices to be summed:

let smart meter bill(R: (int pub ∗ int) table) // time, reading(T: (int ∗ int) lookuptable) = // reading, fee↓ (sum ((time, reading) → lookup reading T) R)

The query looks up the non-linear price of each readingin the table T using lookup and sums the results.

11


Another popular application in the literature involvespay-as-you-drive insurance schemes. Such schemes re-quire drivers to fit a black box in their car that recordstheir driving habits, and allow the insurer to compute apremium based on the safety of the driving, as well asdistance or time. The use of zero-knowledge protocolsto support such automotive settings, including road us-age billing and tolling has been well established in theliterature [5, 61, 44].

An example policy used by a UK auto insurance pi-lot scheme involves recording the segment of road trav-elled, the distance and the speed and use those to sub-tract “points” from a virtual driving license. Points arelinked to the magnitude of speed violations on the roadsegments travelled. The insurance rate per mile is thencomputed as a function of the points subtracted, up toa threshold where the insurance becomes invalid. Wecan express such a policy in ZQL using a table for therecorded road segments used, and lookup tables to en-code the speed limit of road segments, the penalty pointsper magnitude of violation, and finally the insurance pre-mium for a certain number of points:

let pay as you go(Segments : (int ∗ int ∗ int ∗ int) table)(Limits : (int ∗ int) lookuptable )(Penalties : (int ∗ int) lookuptable )(Rates : (int ∗ int) lookuptable ) =let points =

sum ((time, road, speed, miles) →let limit = lookup road Limitslookup (speed − limit) Penalties) Segments

let rate = lookup points Rateslet miles =

sum ((time, road, speed, miles) →miles) Segments↓ (miles ∗ rate)

The pay as you go application makes extensive use oflookup tables to simulate traditional database half-joinsbetween tables. The values of these tables are largely ar-bitrary and related to the insurance policy. We note thatto fully secure this insurance mechanism, some informa-tion about the start and end times of the segments mustalso be signed by the black box and verified to avoid ma-licious replays or omissions. We also note that, depend-ing on policies, the query leaks information from indi-vidual secret inputs to the computed premium. Securingagainst source query leakage is beyond the remit of ZQL,but could be achieved by adapting differentially privateschemes [36].

The final example illustrates how ZQL lookups can beused to approximate functions on real numbers. A verycommon problem in privacy preserving protocols for lo-cation based services is to prove that the reading from atrusted sensor is at a certain distance from a specific loca-tion. For example privacy friendly theft prevention sys-tem may need to periodically prove that a trusted reading

is within a certain distance from their (secret) home lo-cation [56]. Similar protocols can be of use for offendermonitoring, curfew enforcement or tracking of trucks ofgoods. Previous work has proposed zero-knowledge dis-tance protocols, such as [15].

The gps distance protocol takes as secret inputs thelongitude and latitude of two points, as well as someprecomputed tables, and returns an approximation of thedistance between the two points in meters. The approxi-mation used works for small distances under the assump-tion that the curvature of the earth is negligible. It stillrequires the computation of the trigonometric functioncos(x/2). To achieve this, we assume the input longitudeand latitudes are in the units rad/105, and that interme-diate computations are precise to two decimal points.

let gps distance (lat1: int) (lon1: int) (lat2: int) (lon2: int)(hcos: (int ∗ int) lookuptable )(red: (int ∗ int) lookuptable)(dist: (int ∗ int) lookuptable) =

let latsum = lat1 + lat2// Table: hcos(x) = round(cos((x)/2 ·105) ·102)let hc = lookup latsum hcoslet dlat = lat2 − lat1let dlon = lon2 − lon1let lon cos = dlon ∗ hc// Table: red(x) = round(x/102)in(rad/105)2

let r2 = lookup lon cos redlet squares = dlat∗dlat + r2// Table: dist(x) = round(

√x ·R/105)

// where R is earth’s radius (meters).↓ (lookup squares dist)

In this example, lookups are used to approximate realfunctions, including trigonometric functions and divisionwhich is not yet natively supported. The hcos table has alarge domain (∼ 1 million items) but can be reused acrossmultiple operations. Other tables have a relatively smalldomain related to the distances of the points compared.

8 Discussion

Prototype implementation & limitations Our com-piler uses the language development and testing facili-ties of F#: we program source queries as (a small sub-set of) F#, then extract the ZQL abstract syntax tree(AST) through reflection. The compilation pipeline per-forms ZQL type-checking, applies the shared translation,and finally produces the data-source, prover and verifiercode. Each of these steps operates on well-typed ZQLexpressions. This enables us to share many optimizationsas ZQL-to-ZQL transformations.

Besides standard optimizations, the compiler supportsa more general variant of lookup primitive, named find,that returns any lookup-table row that meets a conditionexpressed as a boolean expression on the whole content

12


of the row. This provides more flexibility on the use oflookup tables, but its compilation is more complex.

In addition to cryptographic code, ZQL also synthe-sizes a custom marshaller and un-marshaller for the cryp-tographic evidence and results of the query. Followingthe ZQL approach, this code is specialized and compiledfor a specific proof. Hence, the size and location of allfields, parametrized on the input table lengths, in knownat compile time and there is no need to rely on a general-purpose parser, a component that is traditionally a sourceof security flaws.

We support three distinct compiler back-ends:

Concrete F# The main branch of the compiler trans-forms and compiles the final ZQL data source, proverand verifier into F# code, linked either to the standard.NET big integer libraries, or to proprietary managed li-braries that support pairing based cryptography.

Symbolic F# The second branch of the compiler islinked against symbolic execution libraries for all the op-erators and primitives. Interestingly, since the F# branchmakes extensive use of abstract types in the final proverand verifier, there is no need to write a separate symbolicexecution environment: the mathematical functions cansimply be replaced with equivalents computing on sym-bolic polynomials. The resulting code jointly computesthe execution time and the proof size, as polynomial ex-pressions of the input lengths and the unit costs of eachcryptographic operation. We use symbolic execution topredict the performance of the compiler, and hope to useit in the future to chose between alternative optimizationstrategies at compile time.

Concrete C++ Finally, we support compilation of theverifier to native C++ code, linked with high perfor-mance native big integer libraries. This branch in-volves transforming the functional ZQL verifier and un-marshaller code into an imperative program and optimiz-ing it using standard low-level techniques such as remov-ing dead code, removing spurious copies, and minimiz-ing memory re-allocations. The resulting native programtakes a proof as an input, and outputs the verified result.The native branch does not support on-the-fly compila-tion and execution, and currently works for RSA groupsonly. Yet the resulting binary can be easily deployedwhere .NET runtimes are not available.

The process of compiling a query remains fast even onsmall devices. Thus, a service could simply send ZQLqueries to the user, to be reviewed, compiled, then ex-ecuted locally. To this end, our compiler also has anAPI that takes source ZQL ASTs, compiles them to F#,then also compiles and dynamically load the resulting F#code. This is likely to be faster, cheaper, safer and morereliable than providing custom binaries every time thequery is updated.

The prototype compiler is still subject to limitations.For instance, some optimizations, such as moving de-classifications up in the dataflow to minimize the size ofthe Σ-protocol, or batching some exponential computa-tions, could be systematically applied.

Performance Evaluation Table 1 illustrates the per-formance of ZQL code for the three applications pre-sented in Section 7. It provides the execution time for theF# provers and verifiers, as well as the size of the proof,for different security parameters of RSA (1024 bits, 2048bits) and the pairing based cryptography over a 254 bitsBarreto-Naehrig curve (BN254). The smart meter billreadings table is of size �read = 5 and the pay as you goquery road segments table is of size �seg = 25. This

means that for the 1024 bit RSA branch, the prover canprocess a meter reading every ∼ 120mS or a segmentof road every ∼ 360mS. The proof size for the pair-ing based branch is ∼ 755 bytes per reading and ∼ 1921bytes per segment. As expected, the pairing based proofsare more compact than their RSA counterparts for thesame or even higher levels of security: a 254 bits curveprovides about 128 bits of security which would corre-spond to a 3072 bits RSA modulus.1 This is further ag-gravated by the lack of tightness in RSA-based securityreductions [8]. Prover timings take into account the gen-eration of random numbers. We note that these numbers,while slow by the standards of non-privacy friendly com-putation, are perfectly adequate for computing bills andinsurance premiums in real time.

Besides the main F# backend we experimented witha C++ back-end that compiles to a native verifier. Al-though more performant in absolute terms, the nativeverifier is not significantly faster than its F# counterpart.The RSA 1024 bit computation of the pay as you go ver-ifier took 4,290mS as compared with the F# backend us-ing native big integer binding that took 5,111mS. Pro-filing the C++ execution indicates that more than 90%of the time is spent inside the modular multiplicationfunction performing exponentiations. Thus, improvingthe performance of ZQL comes down to either faster ex-ponentiations (through batching, multi-exponentiation orhardware) or reducing the number of operations requiredthrough more aggressive simplification of the protocols.

Finally, table 1 illustrates the output of the symbolicexecution engine on these three applications, in a config-uration that measures the number of exponentiations (E),pairings (e), and signature verification operations (sigv)in terms of the length of the input tables (�read and �seg),and ignore all other costs.

Where next? The current ZQL language is subject tosome intrinsic limitations, and we are actively exploringoptions to overcome them.

1http://www.cryptopp.com/wiki/Security_Level

13


Examples (branch) prover (mS) verifier (mS) proof size (Bytes)smart meter bill (1024) 586 599 6,106smart meter bill (2048) 3,498 3,148 10,585smart meter bill (BN254) 1,374 2,092 3,773

smart meter bill (symbolic)E+16 ·E · �read+

6 · �read · e6 ·E+14 ·E · �read+

8 · �read · e+ sigv

67+ |h|+ |sig|+2 · �Ga+�Ga · �read +22 · �read+2 · �read ·q+num+7 ·q

pay as you go (1024) 5,314 5,111 57,368pay as you go (2048) 32,442 30,859 100,099pay as you go (BN254) 8,305 12,261 28,819

pay as you go (symbolic)15 ·E+40 ·E · �seg+

12 · �seg · e+6 · e29 ·E+35 ·E · �seg+

16 · �seg · e+8 · e+ sigv

167+ |h|+ |sig|+6 · �Ga+4 · �Ga · �seg +56 · �seg+8 · �seg ·q+num+23 ·q

gps dist (1024) 501 529 5044gps dist (2048) 3,017 2,889 8629gps dist (BN254) 841 1,253 2751

gps dist (symbolic) 60 ·E+18 · e 71 ·E+24 · e+4 · sigv233+ |h|+4 · |sig|+

10 · �Ga +33 ·q

Table 1: Performance for our three applications: runtime, and communicated proof sizes. The smart meter bill readings table isof size �read = 5, the pay as you go query road segments table is of size �seg = 25, the gps distance is between two points.

Many of the limitations are cryptographic and couldbe overcome by applying more advanced protocols. Forexample, lookup and find are currently restricted to ex-ternally signed tables. Lookup tables based on accumu-lators [13] or vector commitments [27] would be moreflexible and may reduce cost. At a lower level, tableprocessing leads to many similar cryptographic opera-tions in a data-parallel style. Batch proof and verificationtechniques and homomorphic signature schemes couldspeed them up [10]. Well known, zero-knowledge proofsfor disjunctions, would allow ZQL branching statements.The shared translation could bundle multiple secrets percommitment. Alternatively one could also employ com-pletely different low-level proof engines, e.g., [53]. Wenote that choosing automatically the best encoding andtechnique, as well as compiling them in a compositionalmanner are challenging open problems. For some pre-liminary work in this direction see [41].

On the language design side, we illustrated in §7 howfunctions can be approximated though lookups. ZQLcould automate and optimize the process by compilingdata sources that calculate and sign function-tables ap-propriately. Finally, by design, our source languageshields programmers from cryptography, and this mayhinder power-users that wish to customize our compila-tion scheme, or experiment with its variants. Similarly,some users may wish to rely on external, unverified pro-cedures, and use ZQL only to validate their results. Ad-vanced APIs exposing the internals of the ZQL compilerwithout breaking its invariants would help them.

Acknowledgments The authors would like to thankIan Goldberg for early discussions of languages for zero-knowledge proofs and the advantages of compilation ver-sus interpretation, and Nikhil Swamy for his comments.

References

[1] J. A. Akinyele, M. D. Green, and A. D. Rubin. Charm: A frame-work for rapidly prototyping cryptosystems. Cryptology ePrintArchive, Report 2011/617, 2011.

[2] J. B. Almeida, M. Barbosa, E. Bangerter, G. Barthe, S. Krenn,and S. Z. Beguelin. Full proof cryptography: verifiable compi-lation of efficient zero-knowledge protocols. In ACM Confer-ence on Computer and Communications Security, pages 488–500, 2012.

[3] M. H. Au, W. Susilo, and Y. Mu. Constant-size dynamic k-TAA.In R. D. Prisco and M. Yung, editors, SCN 2006, volume 4116 ofLNCS, pages 111–125, Maiori, Italy, 2006. Springer.

[4] M. Backes, M. Maffei, and K. Pecina. Automated synthesis ofprivacy-preserving distributed applications. 19th Annual Network& Distributed System Security Symposium (NDSS12), 2012.

[5] J. Balasch, A. Rial, C. Troncoso, B. Preneel, I. Verbauwhede, andC. Geuens. PrETP: Privacy-preserving electronic toll pricing. InUSENIX Security Symposium, pages 63–78, 2010.

[6] E. Bangerter, J. Camenisch, and U. M. Maurer. Efficient proofsof knowledge of discrete logarithms and representations in groupswith hidden order. In Public Key Cryptography, pages 154–171,2005.

[7] E. Bangerter, T. Briner, W. Henecka, S. Krenn, A.-R. Sadeghi,and T. Schneider. Automatic generation of sigma-protocols. InEuroPKI, pages 67–82, 2009.

[8] E. Bangerter, S. Krenn, A.-R. Sadeghi, T. Schneider, and J.-K. Tsay. On the design and implementation of efficient zero-knowledge proofs of knowledge. ECRYPT workshop on Soft-ware Performance Enhancements for Encryption and Decryptionand Cryptographic Compilers (SPEED-CC ’09), 2009.

[9] E. Bangerter, S. Krenn, A.-R. Sadeghi, and T. Schneider. Yaczk:Yet another compiler for zero-knowledge. In USENIX SecuritySymposium, 2010.

[10] S. Bayer and J. Groth. Efficient zero-knowledge argument forcorrectness of a shuffle. In EUROCRYPT, pages 263–280, 2012.

[11] M. Bellare and O. Goldreich. On defining proofs of knowledge.In CRYPTO, pages 390–420, 1992.

[12] M. Bellare and P. Rogaway. Random oracles are practical: Aparadigm for designing efficient protocols. In ACM Conferenceon Computer and Communications Security, pages 62–73, 1993.

[13] J. C. Benaloh and M. de Mare. One-way accumulators: A de-centralized alternative to digital sinatures (extended abstract). In

14


EUROCRYPT, pages 274–285, 1993.[14] J. Bengtson, K. Bhargavan, C. Fournet, A. D. Gordon, and

S. Maffeis. Refinement types for secure implementations. In21st IEEE Computer Security Foundations Symposium (CSF’08),pages 17–32, 2008.

[15] T. S. Benjamin. Zero-knowledge protocols to prove distances.Personal communication, 2008.

[16] K. Bhargavan, C. Fournet, and A. D. Gordon. F7: refinementtypes for F#, 2008. Microsoft Research Technical Report.

[17] D. Boneh, X. Boyen, and H. Shacham. Short group signatures.In CRYPTO, pages 41–55, 2004.

[18] S. Brands. Rapid demonstration of linear relations connected byboolean operators. In EUROCRYPT, pages 318–333, 1997.

[19] T. Briner. Compiler for zero-knowledge proof-of-knowledge pro-tocols. Master thesis, ETH Zurich & IBM Research Lab Zurich,2004.

[20] J. Camenisch and A. Lysyanskaya. A signature scheme with effi-cient protocols. In SCN, pages 268–289, 2002.

[21] J. Camenisch and A. Lysyanskaya. Signature schemes and anony-mous credentials from bilinear maps. In CRYPTO, pages 56–72,2004.

[22] J. Camenisch and M. Stadler. Efficient group signature schemesfor large groups. In B. Kaliski, editor, Advances in Cryptology —CRYPTO ’97, volume 1296 of LNCS, pages 410–424. SpringerVerlag, 1997.

[23] J. Camenisch and E. Van Herreweghen. Design and implementa-tion of the idemix anonymous credential system. Technical Re-port Research Report RZ 3419, IBM, May 2002.

[24] J. Camenisch, A. Kiayias, and M. Yung. On the portability ofgeneralized schnorr proofs. In EUROCRYPT, pages 425–442,2009.

[25] J. Camenisch, M. Kohlweiss, and C. Soriente. Solving revocationwith efficient update of anonymous credentials. In SCN, pages454–471, 2010.

[26] J. L. Camenisch. Group Signature Schemes and Payment Sys-tems Based on the Discrete Logarithm Problem. PhD thesis, ETHZurich, 1998. Diss. ETH No. 12520, Hartung Gorre Verlag, Kon-stanz.

[27] D. Catalano and D. Fiore. Vector commitments and their appli-cations. Cryptology ePrint Archive, Report 2011/495, 2011.

[28] D. Chaum and T. P. Pedersen. Wallet databases with observers.In CRYPTO, pages 89–105, 1992.

[29] E. F. Codd. A relational model of data for large shared data banks.Commun. ACM, 13(6):377–387, 1970.

[30] R. Cramer. Modular Design of Secure yet Practical Crypto-graphic Protocols. PhD thesis, University of Amsterdam, 1997.

[31] R. Cramer and I. Damgard. Zero-knowledge proofs for finite fieldarithmetic; or: Can zero-knowledge be for free? In CRYPTO,pages 424–441, 1998.

[32] R. Cramer, I. Damgard, and B. Schoenmakers. Proofs of partialknowledge and simplified design of witness hiding protocols. InCRYPTO, pages 174–187, 1994.

[33] I. Damgard. On Σ-protocols, 2002. Available at http://www.daimi.au.dk/~ivan/Sigma.ps.

[34] I. Damgard and E. Fujisaki. An integer commitment schemebased on groups with hidden order. IACR Cryptology ePrintArchive, 2001:64, 2001.

[35] G. Danezis and B. Livshits. Towards ensuring client-side compu-tational integrity. In CCSW, pages 125–130, 2011.

[36] G. Danezis, M. Kohlweiss, and A. Rial. Differentially privatebilling with rebates. In Information Hiding, pages 148–162,2011.

[37] C. Dwork. Differential privacy: A survey of results. Theory andApplications of Models of Computation, pages 1–19, 2008.

[38] U. Feige and A. Shamir. Witness indistinguishable and witnesshiding protocols. In STOC, pages 416–426, 1990.

[39] U. Feige, A. Fiat, and A. Shamir. Zero knowledge proofs of iden-tity. In STOC, pages 210–217, 1987.

[40] A. Fiat and A. Shamir. How to prove yourself: Practical solutionsto identification and signature problems. In CRYPTO, pages 186–194, 1986.

[41] M. Fredrikson and B. Livshits. Z0: An optimizing distributingzero-knowledge compiler. 2013. MSR Technical report.

[42] T. Freeman and F. Pfenning. Refinement types for ML. InProgramming Language Design and Implementation (PLDI’91),pages 268–277. ACM, 1991.

[43] E. Fujisaki and T. Okamoto. Statistical zero knowledge protocolsto prove modular polynomial relations. In CRYPTO, pages 16–30, 1997.

[44] F. D. Garcia, E. R. Verheul, and B. Jacobs. Cell-based roadpric-ing. In EuroPKI, pages 106–122, 2011.

[45] I. Goldberg. Natural zero-knowledge embedding in c++. Personalcommunication, October 2011.

[46] O. Goldreich, S. Micali, and A. Wigderson. How to prove allnp-statements in zero-knowledge, and a methodology of crypto-graphic protocol design. In CRYPTO, pages 171–185, 1986.

[47] S. Goldwasser, S. Micali, and C. Rackoff. The knowledge com-plexity of interactive proof systems. SIAM J. Comput., 18(1):186–208, 1989.

[48] M. Jawurek, M. Johns, and F. Kerschbaum. Plug-in privacy forsmart metering billing. In PETS, pages 192–210, 2011.

[49] D. Malkhi, N. Nisan, B. Pinkas, and Y. Sella. Fairplay - a securetwo-party computation system. In USENIX Security, pages 287–302, 2004.

[50] U. M. Maurer. Unifying zero-knowledge proofs of knowledge.In B. Preneel, editor, AFRICACRYPT, volume 5580, pages 272–286. Springer, 2009.

[51] S. Meiklejohn, C. C. Erway, A. Kupcu, T. Hinkle, and A. Lysyan-skaya. ZKPDL: A language-based system for efficient zero-knowledge proofs and electronic cash. In USENIX Security Sym-posium, pages 193–206, 2010.

[52] T. Okamoto. Provably secure and practical identification schemesand corresponding signature schemes. In CRYPTO, volume 740,pages 31–53. Springer, 1992.

[53] B. Parno, C. Gentry, J. Howell, and M. Raykova. Pinocchio:Nearly practical verifiable computation. In IEEE Symposium onSecurity and Privacy, 2013.

[54] T. P. Pedersen. Non-interactive and information-theoretic secureverifiable secret sharing. In CRYPTO ’92, volume 576 of LNCS,pages 129–140, 1992.

[55] A. Rial and G. Danezis. Privacy-preserving smart metering. InWPES, pages 49–60, 2011.

[56] T. Ristenpart, G. Maganis, A. Krishnamurthy, and T. Kohno.Privacy-preserving location tracking of lost or stolen devices:Cryptographic techniques and replacing trusted third parties withdhts. In 17th USENIX Security Symposium, pages 275–290, 2008.

[57] C.-P. Schnorr. Efficient signature generation by smart cards. J.Cryptology, 4(3):161–174, 1991.

[58] N. Swamy, J. Chen, C. Fournet, P.-Y. Strub, K. Bhargavan, andJ. Yang. Secure distributed programming with value-dependenttypes. In ICFP, pages 266–278, 2011.

[59] M. Tompa and H. Woll. Random self-reducibility and zeroknowledge interactive proofs of possession of information. InFOCS, pages 472–482, 1987.

[60] C. Troncoso, G. Danezis, E. Kosta, and B. Preneel. PriPAYD:privacy friendly pay-as-you-drive insurance. In P. Ning and T. Yu,editors, WPES, pages 99–107. ACM, 2007.

[61] C. Troncoso, G. Danezis, E. Kosta, J. Balasch, and B. Preneel.Pripayd: Privacy-friendly pay-as-you-drive insurance. IEEETrans. Dependable Sec. Comput., 8(5):742–755, 2011.

[62] H. Wee. Zero knowledge in the random oracle model, revisited.In ASIACRYPT, pages 417–434, 2009.

15


First stage: [[x : τ,ρ]]1 = x : τ, [[ρ]]1 when x public (including all group elements)

[[x : τ,ρ]]1 = x : τ, tx : x witness, [[ρ]]1 when x private int or num

[[Γ � e]]1 = H,a,e when e public expression, that is, whose variables are all public in Γ.

[[Γ � e]]1 = let C = e in extend H C,(a,C),C when Γ � e : eltG and e is not public

[[Γ � a0 +∑ni=1 ai ∗ xi]]1 = H,a,a0 +∑n

i=1 ai ∗ xi,∑ni=1 ai ∗ txi

when the xi are private and the ai public:(Γ(ai) = pub num)i=0..n,(Γ(xi) = num)i=1..n

[[Γ � e]]1 = let a,ρ = e in (let txi = random() in )xiH,(a, [[ρ]]1), [[ρ]]1

when Γ � e : ρ non-linear private expression (including assoc, random, opening...)and xi ranges over the private variables bound in ρ

[[Γ � assert eC =G ex]]1 = extend H et ,a,ε when eC public and ex algebraic on private exponents

[[Γ �↓ x]]1 = let a = a,x in extend (extend H gx) gtx ,a,x

[[Γ � let ρ = e in e0]]1 = let H,a, [[ρ]]1 = [[Γ � e]]1 in [[Γ,ρ � e0]]1

Second stage: [[δ ,ρ]]2 = let a, [[ρ]]1 = a in [[δ ]]2, [let rx = tx − c∗ x in ]x [[ρ]]vwhere x ranges over the private variables bound in ρ

[[δ ,δ ′ table]]2 = let a,A = a in [[δ ]]2,map (δ ′ → [[δ ′]]2)A

[[ε]]2 = ε

[[θ → e]]PROVER = [[θ ]]D →let H = H0 in let a = () in// hash and prove commitments for all private inputs (omitted)let H : hash,a : δ ,r = [[θ � e]]1 inlet c = finalize H in[[θ ,r]]pub, [[δ ]]2,c

Figure 6: Prover Translation (see full paper for map and fold)

[[x : τ,ρ]]v = x : τ, [[ρ]]v when x public (including all group elements)

[[x : τ,ρ]]v = rx : (c,x) response, [[ρ]]v when x private

[[Γ � e]]v = H,a,e when e public expression, that is, whose variables are all public in Γ.

[[Γ � e]]v = let C,a = a in extend H C,a,C when Γ � e : eltG and e is not public

[[Γ � a0 +∑ni=1 ai ∗ xi]]v = H,a,−c∗a0 +∑n

i=1 ai ∗ rxiwhen the xi are private and the ai public:(Γ(ai) = pub num)i=0..n,(Γ(xi) = num)i=1..n

[[Γ � e]]v = let a, [[ρ]]v = a in H,a, [[ρ]]vwhen Γ � e : ρ non-linear private-exponent expression (including assoc, random, opening...)and ρ binds private exponents and public elements

[[Γ � assert eC =G ex]]v = extend H ((eC)c ∗G [[ex]]v),a,ε when ex algebraic on private exponents

[[Γ �↓ x]]v = let x,a = a inextend (extend H gx) gc∗x+rx ,a,x

[[Γ � let ρ = e in e0]]v = let H,a, [[ρ]]v = Γ � [[e]]1 in [[Γ,ρ � e0]]v

[[θ → e]]VERIFIER = [[θ ,r]]pub′ ,a,c →// check plain signatures, hash commitments into H,// and check commitment proofs for all private inputs (omitted)let H = H0 inlet H,a,r = [[Γ � e]]v incheck c = finalize H;r

Figure 7: Verifier Translation (see full paper for map and fold)

16

Date post:	19-Mar-2018
Category:	Documents
Upload:	vanthu
View:	215 times
Download:	2 times

ZQL: A Compiler for Privacy-Preserving Data · PDF filequeries for smart-meter billing, for...

Documents