Automatic Generation of Two-Party Computations(Extended Abstract)

Philip MacKenzie� Alina Opreay Michael K. Reiterz

ABSTRACTWe present the design and implementation of a compiler thatautomatically generates protocols that perform two-party com-putations. The input to our protocol is the specification of acomputation with secret inputs (e.g., a signature algorithm) ex-pressed using operations in the field Zq of integers modulo aprime q and in the multiplicative subgroup of order q inZ�p forqjp� 1 with generator g. The output of our compiler is an im-plementation of each party in a two-party protocol to performthe same computation securely, i.e., so that both parties cantogether compute the function but neither can alone. The pro-tocols generated by our compiler are provably secure, in thattheir strength can be reduced to that of the original crypto-graphic computation via simulation arguments. Our compilercan be applied to various cryptographic primitives (e.g., sig-nature schemes, encryption schemes, oblivious transfer proto-cols) and other protocols that employ a trusted party (e.g., keyretrieval, key distribution).

Categories and Subject DescriptorsE.3 [Data Encryption]: public key cryptosystems

General TermsSecurity

KeywordsSecure two-party computation, automatic generation of proto-cols, threshold cryptography�Bell Labs, Lucent Technologies, Murray Hill, NJ, USA;philmac@research.bell-labs.comyComputer Science Department, Carnegie Mellon University,Pittsburgh, PA, USA; alina@cs.cmu.eduzElectrical & Computer Engineering and Computer ScienceDepartments, Carnegie Mellon University, Pittsburgh, PA,USA; reiter@cmu.edu

Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.CCS’03, October 27–31, 2003, Washington, DC, USA.Copyright 2003 ACM 1-58113-738-9/03/0010 ...$5.00.

1. INTRODUCTIONA central notion in cryptographic key management is that

of (k; n)-secret sharing[32], by which a secret key is dividedinto n shareswith the property that only sets of shares of sizek or larger can be used to reconstruct the key. During thepast fifteen years, (k; n)-secret sharing has been extended to(k; n)-function sharing(or threshold cryptography) (e.g., [9,13, 14, 17]), whereby k parties, each holding a share, collab-orate to perform a computation with the key without exposingtheir shares (or reconstructing the key). A special case of in-terest in this paper is two-party (i.e., (2; 2)) function sharing,in which the key is split between two parties whose collabo-ration is necessary and sufficient to compute the function withthe key.

In this paper we present the design and implementation ofa compiler for the automatic generation of two-party functionsharing protocols. Our work is primarily motivated by the cur-rent gap between generic secure two-party computation proto-cols and efficient hand-tuned two-party protocols for particularprimitives. We propose the first fully automated tool for gener-ating two-party protocols that are efficient enough to be usedin practical applications. The input to our compiler is a de-scription of a cryptographic function (e.g., a digital signaturealgorithm, or decryption algorithm) written in a high-level lan-guage of our own design. The output of our compiler is sourcecode implementing each side of a two party protocol for com-puting that function. At the time of this writing, the input func-tions for which our compiler can generate two-party protocolsare restricted to functions in which secrets and randomly gen-erated values (e.g., permanent and ephemeral keys) are ele-ments of the field Zq of integers modulo a public prime q, andthat are comprised of field operations in Zq and operations inthe multiplicative subgroup Gq of order q in Z�p with publicgenerator g and public prime p, qjp � 1. Computations onpublic values (e.g., hashing a message in the course of gener-ating a digital signature) are also supported. These operationssuffice for numerous useful cryptographic algorithms, includ-ing various public key cryptosystems (e.g., [10]) and signatureschemes (see [20] for a survey) based on the difficulty of com-puting discrete logarithms in Gq . An area of ongoing work isextending our protocol to broader sets of computations.

The protocols generated by our compiler are provably se-cure against arbitrary misbehavior by either party. More specif-ically, the security of a protocol generated by our compiler canbe reduced to the security of the cryptographic function that isthe input to the compiler, using a simulation argument. Se-

210

© ACM, 2003. This is the authors' version of the work. It is posted here by permission of ACM for your personal use.Not for redistribution. The definitive version is available at http://doi.acm.org/10.1145/948109.948139.

curity additionally relies on other assumptions, which in ourpresent implementation includes both random oracles [4] andcryptographic assumptions such as decision composite residu-osity [29]. Further, for any function with a secret input param-eter (typically a long-term private key), the two-party protocoloutput from our compiler requires that shares of this secret pa-rameter be predistributed to the two parties that are to run theprotocol. That is, our compiler generates two party protocolsthat assume a trusted third party for sharing long-term secrets;removing this assumption is an area of ongoing work.

Another motivation of our work is the prior research towardpreventing misuse of a cryptographic key by requiring the con-sent of a partially [21, 8] or fully [16] trusted server beforethe key can be used. A common approach to make the servernon-bypassable is to share the key between its intended userand the server, and for the user and server to jointly computecryptographic operations using (2; 2)-function sharing. A goalof this research is to provide a tool by which a new crypto-graphic function (e.g., any of the literally hundreds of signa-ture schemes in [20]) can be protected in this sense through theautomatic, and even dynamic, generation of a server-assistedprotocol for the function. More generally, we intend to explorecompilation as a means for making two-party (and, in the fu-ture, multiparty) computation a “commodity tool” for othercryptographic applications and scientific research.

A precursor to our compilation process is the assembly ofa repertoire of “building block” protocols for basic two-partycomputations, e.g., addition of shared secrets (yielding a sharedresult), multiplication of shared secrets, multiplicative inver-sion of a shared secret, and so forth. Additional building blocksare included to translate shares in one representation to an-other, i.e., from additive shares to multiplicative shares andback. These translations are required since, for example, themost efficient protocol for adding shared secrets employs ad-ditive shares, whereas the most efficient protocol for invertinga shared secret employs multiplicative shares. The compila-tion process itself begins with parsing the input function into atree with nodes being operations and edges representing dataflows between operations. In addition, each edge is annotatedwith an indication of whether the value on that edge is to bepublic or kept secret. Additional nodes are inserted to translateshared secrets in one representation to the other as necessary,and to reveal (i.e., make public) values that are allowed to berevealed. Finally, the tree is traversed to emit building blockprotocols that together perform a two-party computation of theinput function.

2. RELATED WORKTechniques for generic secure two-party computation (e.g.,

[35]) provide a recipe for designing secure two-party proto-cols for a much larger class of functions than our compiler canaccommodate. However, the protocols that result from thesegeneral techniques are too inefficient to be useful in practice,and we know of no efforts to implement these techniques (ormore specialized techniques) within a tool for generating pro-tocol implementations automatically. The goal of our compileris to generate practical protocols for a restricted but interest-ing class of functions, and to explore optimizations that makethem useful even in performance-sensitive applications.

As discussed in Section 1, we are primarily motivated by the

generation of two-party protocols for computing digital signa-tures or decrypting ciphertexts of a public key cryptosystem.As such, the protocols our compiler generates fall within thegeneral framework of threshold cryptography, which exploresspecialized protocols for implementing shared signing or de-cryption more efficiently than via general secure multipartycomputation (e.g., [9, 13, 14, 17]). Within this category ofwork, proposed two-party protocols include those for perform-ing two-party RSA computations [9] (see also [3]), two-partyDSA [22] and two-party Schnorr [25], for example. At thetime of this writing, our compiler can be used to automati-cally generate provably secure protocols for two-party DSAand Schnorr signing, albeit at some loss in performance overprior hand-tuned proposals, and for all other discrete-log basedsignature schemes of which we are aware (notably the hun-dreds of variations surveyed in [20]). In the future, we plan toextend our compiler to automatically generate two-party pro-tocols for RSA-based operations (e.g., [31, 11]).

Implementations of specific threshold cryptosystems and sig-nature schemes have been developed in the context of severalsystems (e.g., [30, 36], and specifically [21, 8, 25] for the two-party case) and have been built into general-purpose toolkitsfor broader use [34, 1]. We know of no such toolkit for two-party threshold cryptography, much less any prior work oncompilers for automatically generating two-party protocols.

More distantly related is work in the automatic generationof protocols for establishing a shared cryptographic key be-tween two parties, possibly with the assistance of a third party(e.g. [33]). We emphasize that this work involves key exchangeprotocols using cryptographic primitives (encryption, signa-tures) as abstract building blocks, without consideration ofthe specific construction of these primitives. In contrast, herewe show how to automatically generate two-party protocolsfor implementing specific digital signing or decryption algo-rithms, as well as other cryptographic algorithms of interest.

3. GOALSAs described in Section 1, the goal of our compiler is to au-

tomatically generate efficient, provably secure two-party pro-tocols for an interesting class of cryptographic functions. Inour current version of the compiler, the input functionis re-stricted to computations expressed using selection of randomelements from Zq for q a public prime; multiplication, mul-tiplicative inversion, addition, and additive inversion over Zq;and the generation and multiplication of elements of the mul-tiplicative subgroup Gq of order q in Z�p with public genera-tor g and public prime p, qjp � 1. In addition, the compu-tation is permitted to (and will generally) input one or more“secret” parameters that are elements of Zq, and public aux-iliary inputs (e.g., a message to be signed in a digital signa-ture computation). These computations include, for example,many “discrete-log based” signature schemes and encryptionschemes, i.e., schemes whose security is based on the diffi-culty of computing discrete logarithms to base g in Gq . Thecompiler assumes that all inputs to the computation (except forg, p and q) and all intermediate results are to be secret; onlythe values output from the computation (or that are derivablefrom that output) are permitted to be public.

We denote the two participating parties in our protocol byA and B. The output of the compiler is two algorithms (source

211

code), one for A and one for B. The input to each party con-sists of the public parameters of the system, its own publicand secret parameters, public parameters of the other party andcommitments of the secret parameters of the other party. Moreformally, the A algorithm expects the following inputs:

� common public inputs, including g, q, p, and the auxil-iary inputs;

� private input xA 2 Zq per “secret” parameter x to theinput function;

� private/public key pair (skA; pkA) of a semantically se-cure encryption scheme E (with additional properties;see Section 4.2);

� B’s public key pkB of E ;

� and B’s commitment �xB for each secret parameter x tothe input function, which in our case is an encryption ofxB under pkB, i.e., �xB EpkB(xB).

B expects an analogous set of inputs.The execution of the two party protocol is started by A. This

initiates an interactive protocol in which each of the partiessends messages that contain partial results of its computationto the other party. The protocol runs until either one of theparties aborts or A outputs the result of the input computa-tion. In the case of two-party signature generation, the out-put value is the signature generated jointly by A and B. If Aand B run to completion without aborting, the output producedby A is the same as the input function to the compiler wouldhave produced, provided that for each secret input x, eitherxA + xB �q x or xAxB �q x.

We emphasize that A and B require xA and xB as inputs,respectively, for each input parameter x marked as “secret”to the function input to the compiler. In addition, B is givenpkA, skB, and �xA, whereas A is given pkB, skA, and �xB. Thegeneration and distribution of these values is outside the scopeof our compiler, and must be achieved via some other means,presumably by a trusted third party. Eliminating reliance on athird party for initialization is a planned area of future work.

4. COMPILER DESIGNThis section describes the design of our compiler and some

implementation choices, using the DSA signature scheme asan example. Figure 1 presents a high-level overview of thecompiler structure. The output of the compiler (the two algo-rithms for A and B) is generated from a collection of compo-nent protocols, called building blocks, and from an input filespecified by the user. The component protocols correspond,intuitively, to arithmetic operations, and they are further de-composed into primitive protocolsthat are protocols with atmost one interaction between the two parties. The input filecontains the specification of a computation that will be trans-formed into a two-party protocol. Below, we take a bottom-upapproach in detailing the compilation process.

4.1 Compiler InputThe input to our compiler is the specification of a compu-

tation given in a high level language that was created for thispurpose. The language consists of keywords p, q, g, PARAMS,START, RETURN, SECRET, PUBLIC, RANDOM, MULT and ADD,

Outputsource code

Composition

Building blockprotocols

Primitiveprotocols Input file

Parsing trees

Parsing

Code Generation

Figure 1: Compiler structure

and operators + (addition in Zq), �, � (multiplicative inver-sion in Zq), ^ (exponentiation in Gq with public base), % (re-duction mod a public parameter) and = (assignment). Thebinary operator � is overloaded and can be used to multiplyelements in Zq or in Gq (it can be inferred from the context inwhich group the multiplication is done). Keywords MULT andADD specify the type of sharing of a secret (multiplicatively oradditively, respectively) and are optional. We require that key-words PARAMS, START and RETURN appear in the descriptionfile of each function in this exact order. For example, the in-put file for generating the two-party DSA signature scheme isgiven in Figure 2(a).

By convention, every variable is assumed to be secret, un-less it is declared PUBLIC or returned in RETURN. In the ex-ample in Figure 2(a), k is secret, whereas r and s are public asbeing output of the computation. In addition, every input pa-rameter is assumed to be an element ofZq, and RANDOM gen-erates a random element of Zq. The computation itself beginsafter START and ends at RETURN. It can consist of arbitrarilymany steps, with the restriction that each expression is gener-ated by the context-free grammar from Figure 2 (b) (id herereplaces any valid variable name using standard conventions).

PARAMS

SECRET x ADD

PUBLIC mSTART

k = RANDOM

r = g ^ k% qs = � k � (m+ x � r)

RETURN (r; s)

(a)

S ! id = EE ! T+E j T j RANDOM

T ! F*T j F % T j FF ! �F j B ^ F j BB ! id j E

(b)

Figure 2: (a) Input file for DSA signature, (b) Grammarfor generating expressions

4.2 Primitive protocolsThe output of our compiler, i.e., the two-party protocol im-

plemented by two algorithms for A and B, is constructed usinga collection of primitive protocols. Intuitively, these primitiveprotocols define the “instructions” that are composed to gener-ate the compiler’s output. Each primitive protocol consists ofat most one message, and has an initiator. The initiator’s inputto a primitive protocol includes one or more of its secret val-ues, its commitments to those secret values, the other party’s

212

commitments to its secret values, and possibly public values.The other party can employ corresponding values of its own,as well, though in most primitive protocols, this party worksonly with commitments from the initiator and public values;in all but two protocols, its own secrets are not employed.

A table specifying each of the primitive protocols is shownin Figure 3. The terminology we used for protocol names is asfollows: Add, Mult, Inv, Exp, ModQ refer to the arithmetic op-erations performed; Add2Mult and Mult2Add refer to the con-version from additive to multiplicative sharing of a secret andthe reverse; Rev means that the protocol has a public output;S/P stands for one of the input parameters being secret/publicand we can have combinations of the form SS, SP if the pro-tocol has two parameters; Dup means that the protocol has nofunctionality (its output is equal to its input).

This table specifies the primitive protocols in which A is theinitiator. Those when B is the initiator are symmetric. Foreach protocol, the number of messages, either zero or one, isshown; when a message is sent it is always sent by the ini-tiator. The next columns specify each party’s inputs to theprotocol, and the preconditions that it must know to be truein order to execute the protocol. Note that in some cases,the preconditions cannot be directly verified by the party whomust be convinced of them. For example, B may be requiredto know that DskA (�xA) (i.e., the decryption of �xA under pri-vate key skA) is less than some value, even though B doesnot know skA. This simply means that this fact will need tobe proven to B (via a zero-knowledge proof) within anotherprotocol (e.g., ModQ) if B cannot otherwise infer it, beforeB will execute the protocol for which this is a precondition.Each primitive protocol gives each party additional outputs,also shown, and enables that party to conclude the specifiedpostconditions for those outputs. As a simple example, con-sider the second protocol listed in the table, called AddSS(xA,yA) (adds two secrets). In this protocol, A begins with valuesxA and yA with commitments (ciphertexts) �xA and �yA; B alsoknows these commitments. Moreover, both A and B know thatDskA (�xA) + DskA(�yA) � R for some value R (more on thisbelow). After this protocol (involving no messages), A willpossess a new value zA = xA + yA and commitment �zA for it,and B will also possess �zA. Moreover, each of them will knowthat DskA (�zA) � R.

The commitments of shares are generated using a semanti-cally secure public key encryption scheme E with encryptionalgorithm E and decryption algorithm D that in addition havea homomorphic property. For a given public key pk, we de-note by Mpk the plaintext space, which we assume is a rangeof integers f0; 1; : : : ; tg with t > ql. (Typically l = 6, e.g.,for q of 160 bits and the public key of 1024 bits.) We use Cpk

to denote the ciphertext space. We require that there exists anefficient additive operation +pk : Cpk � Cpk ! Cpk and amultiplicative operation �pk : Cpk �Mpk ! Cpk such that:

� 8m1;m2 2Mpk: m1 +m2 2Mpk )Dsk(Epk(m1) +pk Epk(m2)) = m1 +m2

� 8m1;m2 2Mpk: m1m2 2Mpk )Dsk(Epk(m1) �pk m2) = m1m2

We observe that the existence of +pk implies the existenceof �pk. Several examples of cryptosystems supporting theseadditional operations exist [5, 24, 28, 29]. In our implemen-tation, we use the Paillier cryptosystem [29] whose security

is based on the composite residuosity problem, but any of theabove-mentioned cryptosystems could be used instead.

In Figure 3, R denotes the largest number in MpkA \MpkB

and is used to ensure that some values are in the plaintext rangeof both the encryption schemes used.

A B

zA x�1A

mod q�zA Epk

A(zA)

�A zkp

26649�; � : � 2 Zq^ Dsk

A(�xA) = �

^ DskA(�zA) = �

^ �� �q 1

3775

<�zA;�

A>

-

abort if (Veri�er(�A) = 0)

Figure 4: InvS protocol

For illustration, we present an example of a primitive proto-col: InvS(xA) (inverts a secret) in Figure 4. In the protocol, A’sinput is a value xA and commitment �xA = EpkA(xA), whereasB’s input is only �xA. After executing the protocol, A will havea share zA = x�1

A2 Zq and its commitment �zA = EpkA(zA).

B’s output will consist only of the commitment �zA. A gener-ates a zero knowledge proof �A, in which it proves to B thatDskA(�zA) = (DskA(�xA))

�1 mod q. B verifies the proof us-ing the polynomial time algorithm Verifier. The proof �A isomitted due to space limitations, but will be included in thefull version of this paper.

4.3 Building Block ProtocolsThe fine granularity of the primitive protocols described in

Section 4.2 offers many opportunities for experimenting withhow to construct the most efficient two-party protocols for agiven input computation. As an initial exploration into thisspace, however, our work so far has focused on only one sim-ple way of combining them to reach the given input compu-tation. The technique we have explored thus far is to com-pose primitive protocols into larger two-party building blockprotocols that implement certain operations on shared secrets.Then, our compiler emits its output using building blocks,rather than emitting instances of primitive protocols directly.

Working with building blocks is more intuitive—and easierto prove things about—than working with primitive protocolsdirectly, since each building block corresponds to a basic oper-ation on shared secrets such as addition, multiplication, inver-sion, modular reduction, exponentiation or generation of ran-dom secrets in the input computation. Two additional buildingblocks perform conversion from additive shares to multiplica-tive shares of a secret and the other way around. These arenecessary as each building block requires the input secret(s)to be shared in the proper way (either additively or multiplica-tively). Building blocks are constructed via composition ofprimitive protocols:

DEFINITION 4.1. Let P1 and P2 be two-party protocols.ThenP = P1 k P2 is a two-party protocol in which protocolsP1 andP2 are executed sequentially, starting withP1 . Wecall P the sequential composition ofP1 andP2.

213

Protocol Msgs Party Input Preconditions Output PostconditionsGenerate() 1 A - zA; �zA Dsk

A(�zA) = zA

zA 2 ZqB - �zA

AddSS(xA , yA) 0 A xA, �xA DskA(�xA) = xA zA , �zA zA = xA + yA

yA, �yA DskA(�yA) = yA Dsk

A(�zA) = zA

xA + yA � RB �xA Dsk

A(�xA) +Dsk

A(�yA) � R �zA Dsk

A(�zA) = Dsk

A(�xA) +Dsk

A(�yA)

�yAAddSP(xA , y) 0 A xA, �xA Dsk

A(�xA) = xA zA , �zA zA = xA + y

y xA + y � R DskA(�zA) = zA

B �xA DskA(�xA) + y � R �zA Dsk

A(�zA) = Dsk

A(�xA) + y

yMultSS(xA , yA) 1 A xA, �xA Dsk

A(�xA) = xA zA , �zA zA = xAyA mod q

yA, �yA DskA(�yA) = yA Dsk

A(�zA) = zA

xAyA � RB �xA Dsk

A(�xA)Dsk

A(�yA) � R �zA Dsk

A(�zA) �q Dsk

A(�xA)Dsk

A(�yA)

�yAMultSP(xA , y) 0 A xA, �xA Dsk

A(�xA) = xA zA , �zA zA = xAy

y xAy � R DskA(�zA) = zA

B �xA DskA(�xA)y � R �zA Dsk

A(�zA) = Dsk

A(�xA)y

y

InvS(xA) 1 A xA, �xA DskA(�xA) = xA zA , �zA zA = (xA)

�1 mod qDsk

A(�zA) = zA

B �xA DskA(�xA) < R=2q3 �zA Dsk

A(�zA) = (Dsk

A(�xA))

�1 mod q

RevExp(xA, y) 1 A xA, �xA DskA(�xA) = xA zA zA = yxA mod p

y

B �xA zA zA = yDsk

A(�xA)mod p

yAdd2Mult(xA, xB) 1 A xA, �xA Dsk

A(�xA) = xA zA , �zA zA 2 Zq

�xB DskB(�xB) + xA < R=q3 �zB Dsk

A(�zA) = zA

zADskB(�zB) �q xA +Dsk

B(�xB)

B xB, �xB DskB(�xB) = xB zB , �zB Dsk

B(�zB) = zB

�xA �zA DskA(�zA)zB �q Dsk

A(�xA) + xB

Mult2Add(xA, xB) 1 A xA, �xA DskA(�xA) = xA zA , �zA zA 2 Zq

�xB DskB(�xB)xA < R=q2 �zB Dsk

A(�zA) = zA

zA +DskB(�zB) �q xADsk

B(�xB)

B xB, �xB DskB(�xB) = xB zB , �zB Dsk

B(�zB) = zB

�xA �zA DskA(�zA) + zB �q Dsk

A(�xA)xB

ModQ(xA) 1 A xA, �xA DskA(�xA) = xA zA , �zA zA = xA mod q

DskA(�zA) = zA

B �xA �zA DskA(�zA) = Dsk

A(�xA) mod q

Rev(xA) 1 A xA, �xA DskA(�xA) = xA

B �xA xA DskA(�xA) = xA

Dup(xA) 0 A xA, �xA zA , �zA zA = xA�zA = �xA

B �xA �zA �zA = �xA

Figure 3: Primitive protocol specifications

In addition to the primitive protocols discussed in Section 4.2,we need some local computation protocols that perform oper-ations only on public values, so we employ one such proto-col for each arithmetic operation: Add2Pub (adds two pub-lic values), Mult2Pub (multiplies two public values), InvPub(computes the multiplicative inverse of a public value in Zq),ModQPub (computes the reduction mod q of a public value)and so forth. Our building blocks, enumerated in Figure 5,are compositions of primitive protocols and local computationprotocols. The preconditions and postconditions of each build-ing block protocol are accumulated from the preconditions andpostconditions of the primitive protocols that comprise it.

4.4 Emitting the Two-Party ProtocolThe emitted two-party protocol is a sequential composition

of building blocks described in Section 4.3. In this section, wedescribe how the sequence of building blocks is determined bythe compiler, given the specification of the input function.

The compilation process has three important phases: pars-ing, construction of the sequence of interactive building blocksand generation of the output source code for each party. Belowwe will detail each of the three steps.

4.4.1 ParsingDuring the parsing process, the compiler checks that the in-

put file has the required format, signaling for existing errors.In addition, for each step in the computation (these are givenby expressions between keywords START and RETURN), it willgenerate an associated parsing tree as in Figure 6. The nodesin the parsing trees represent operations: GENq (generationof random secrets in Zq), +q (addition of elements in Zq),�q (multiplication of elements in Zq), �1q (inversion of a Zq

element), ^p (exponentiation of an element in Gq to an expo-nent in Zq), %q (reduction mod q), Conv (conversion frommultiplicative shares of a secret to additive shares of the samesecret or the reverse), Rev (reveal a secret). Terminal nodes

214

Building block Description CompositionGenerate Generates a random

shared secretzA Generate()zB Generate()

Add2Secrets Adds two secrets(x; y), additivelyshared

zA AddSS(xA ,yA)zB AddSS(xB ,yB)

AddSecretPub Adds a public value (y)and a secret additivelyshared (x)

zA AddSP(xA , y)zB Dup(xB)

Mult2Secrets Multiplies two secrets(x; y) multiplicativelyshared

zA MultSS(xA ,yA)zB MultSS(xB ,yB)

MultSecretPub Multiplies a publicvalue (y) and a secret(x) multiplicativelyshared

zA MultSP(xA ,y)zB Dup(xB)

InvSecret Inverts a secret (x),multiplicatively shared

zA InvS(xA)zB InvS(xB)

RevealExp Generates yx mod pwhere y is public andxis an additively sharedsecret

zA RevExp(xA, y)zB RevExp(xB, y)z Mult2Pub(zA , zB)

Add2Mult Generates a multiplica-tive sharing of an addi-tively shared secret (x)

hzA; z0

Bi

Add2Mult(xA , xB)zB ModQ(z0

B)

Mult2Add Generates an additivesharing of a multiplica-tively shared secret (x)

hzA; z0

Bi

Mult2Add(xA , xB)zB ModQ(z0

B)

ModQ Reduces a secret mod q zA ModQ(xA)zB ModQ(xB)

RevealAdd Reveals a secret (x) ad-ditively shared

xA Rev(xA)xB Rev(xB)x Add2Pub(xA , xB)

RevealMult Reveals a secret (x)multiplicatively shared

xA Rev(xA)xB Rev(xB)x Mult2Pub(xA , xB)

Figure 5: Building block protocols

in the tree (leaves) are either input variables to the compileror output variables of previous trees. Each node has one ortwo entering edges corresponding to the input of the buildingblock the node represents and one leaving edge, correspondingto the output of the building block. The edges are labelled withthe type of the corresponding variable: P (public), SM (secretshared multiplicatively) or SA (secret shared additively).

During the parsing phase, the compiler constructs a list ofall secrets whose sharing type is unknown (it is not explicitlyspecified in the input file and it can not be determined fromthe execution of the protocol) and then for each possible as-signment of sharing types to secrets, compute the number ofconvert protocols required in the protocol. Our compiler thenchooses the assignment that minimizes the number of convertprotocols, as the convert protocols are the most computation-ally expensive building blocks. This algorithm is exponentialin the number of secrets considered, but this number is typi-cally fairly small.

4.4.2 Construction of building block sequenceIn the second phase, each arithmetic operation is replaced

with the corresponding building block, e.g., addition withAdd2Secrets, AddSecretPub or Add2Pub, dependingon the type of operands. Convert protocols are inserted when-ever secrets are not shared properly for subsequent buildingblocks. If the left hand side of an assignment is secret, butat the same time is part of the computation output, then a Re-veal protocol must be executed. In addition, a ModQ protocolis executed whenever a share might exceed the range specifiedby a precondition of a subsequent building block. An example

g

^p

Conv

k

r

P

s

P

SM

SA

SM

P

SM

k

Rev

�q

SM

�q

x r

Conv

Conv

SM

SA

P

SM

SM

k

T1 T2 T3

Genq

+q

m

SM

SAP

P

%q

�1q

Sequence of building blocks:

T2 : k0 = Mult2Add(k)

r = ModQPub(r)

RevealMult(s)s = Mult2Secrets(k00 ,a4)a4 = Add2Mult(a3)a3 = AddSecretPub(m,a2)a2 = Mult2Add(a1)

T1 : k = Generate()

T3 : k00 = InvSecret(k)

r = RevealExp(g,k0)

a1 = MultSecretPub(r,x)

Figure 6: Parsing trees for generating a DSA signature

for constructing the sequence of building blocks for the DSAsignature scheme is given in Figure 6.

4.4.3 Generation of Java codeIn this phase, Java source code for A and B is automati-

cally generated by our compiler, using the sequence of build-ing block protocols determined previously. During the inter-active execution of the protocol, the two parties can exchangemessages of four types: PARAMS (one party sends the outputof its computations to the other party), REQ-PROOF (a partyrequests a zero knowledge proof of correctness of a compu-tation from the other party), PROOF (one party sends a zero-knowledge proof to the other party as a response to the REQ-PROOF message) and DONE (one party informs the other thatit has finished the protocol). The model we adopt in the im-plementation is that of “pulling the proofs” (generating zeroknowledge proofs on request) as opposed to the theoreticalbuilding blocks where proofs are generated immediately aftereach computation. We believe that this model can lead to op-timizations in our protocol, by allowing aggregation of proofsand minimization of the number of interactions. We intend toexperiment with this in future work.

5. SECURITY FOR TWO-PARTY SIG-NATURE SCHEMES

The two-party protocols generated by our compiler preservethe security of the original input function to the compiler. Theproofs of security are built on the simulatability property ofthe underlying building blocks (Theorem A.2 from AppendixA). The security of the two-party protocols additionally relieson the security of the encryption scheme used for the commit-ments of secret shares and on the security of the zero knowl-

215

edge proofs involved. In this section, we give an example ofsuch a proof when the input function to the compiler is a sig-nature scheme.

Let SIG be a generic signature scheme and S-SIG = P1 k� � � k Pn be our two-party protocol S-SIG for generating asignature (a sequential composition of n building blocks). Inthe security analysis of S-SIG, we require that SIG is secureagainst chosen message attack [19] and the encryption schemeE is semantically secure [18]. We also require non-interactivezero-knowledge proofs, for which formal definitions can befound in [6, 12]. Informally, we remind the reader that a non-interactive zero-knowledge proof system for a language L ismeasured by its soundness error(the probability that a mali-cious prover convinces a verifier to accept a w 62 L) and itssimulation error(for any simulator holding w 2 L and an-swering random oracle queries, the probability with which averifier can distinguish the simulator from the real prover).

We consider two types of adversaries for S-SIG. An A-compromising adversary is a probabilistic polynomial-time ad-versary that is given the public key of SIG and access to the Boracle. The B oracle can be queried by invoking n oracles:BQ

1; : : : ;BQn, where a query to the ith oracle, BQi, corre-sponds to the execution of the Pi building block by B. Thequery to the BQ1 oracle must have as input the message mto be signed. An A-compromising adversary has access in ad-dition to all the secret computation of A. A B-compromisingadversary is defined analogously.

DEFINITION 5.1. A two-party signature scheme is secureagainst anA-compromising adversaryA if A has a negligibleprobability in outputting a pair(m;�) such that� is a validsignature form and the messagem was not sent to theB ora-cle in aBQ1 query.

Below we state the security theorem of the S-SIG proto-col against an A-compromising adversary. A similar defini-tion of security of a two-party signature scheme against a B-compromising adversary and a proof of security of S-SIG againstthis type of adversary could be given.

THEOREM 5.2. If an A-compromising adversary forges asignature in theS-SIG scheme with non-negligible probability,then:

1. There exists an attacker that forges a signature inSIG

with non-negligible probability; or

2. There exists an attacker that breaks the semantic secu-rity of E with non-negligible probability; or

3. One of the zero knowledge proofs used in theS-SIG pro-tocol has a non-negligible simulation error; or

4. One of the zero knowledge proofs used in theS-SIG pro-tocol has a non-negligible soundness error.

The proof of the theorem is given in Appendix A.

6. PERFORMANCE RESULTSWe implemented our compiler in Java. To optimize some

of the expensive operations performed in our implementation(such as exponentiations or generation of random numbers)we used the gmp C library. In our system, A is a client of

Scheme Signature A (sec) B (sec) sharing of xEG I.1 s �q k

�1(m+ xr) 1.019 1.151 additiveEG I.2 s �q x

�1(m+ kr) 0.828 0.882 multiplicativeEG I.3 s �q xr + km 0.129 0.141 additiveEG I.4 s �q xm+ kr 0.130 0.143 additiveEG I.5 s �q x

�1(r + xm) 0.837 0.896 multiplicativeEG I.6 s �q k

�1(r + xm) 1.022 1.144 additive

Figure 7: Performance results

server B. A initiates the communication and B responds to A’smessages until a signature is generated. The client and servercommunicate through sockets.

We ran our implementation on a two-processor machine,each a 2.4 GHz Intel Xeon, and tested it on the various sig-nature schemes proposed in [20]. Figure 7 shows the unop-timized computation time for both A and B for generating atwo-party signature. The signature schemes used are the sixbasic types of signatures from [20]. All these schemes havethe same key generation algorithm, they differ only in the sig-nature generation and verification. Signature generation is ofthe form: k R Zq; r = gk mod p; s = :::; output (r; s)with different relations for the computation of s. The tableshows the specific equation for s for each of the schemes andthe verification relation. Scheme EG I.1 is a variant of DSA inwhich r is not reduced mod q.

As already mentioned in [20], types 3 and 4 are the mostefficient schemes, as they do not require the computation of aninverse mod q. Our experiments confirm that this is also truefor the two party case, types 3 and 4 being nearly an order ofmagnitude more efficient than the other four types.

For each of the types, we have generated two party protocolsutilizing both additive and multiplicative sharing of the secretkey x. An interesting observation is that the most efficientprotocol for DSA is one in which x is shared additively, butthe hand-tuned two-party DSA [22] employs a multiplicativesharing of x.

We are planning to explore future optimizations in our com-piler, such as parallelizing computation or using pre-computedtables for exponentiations with the same base [23]. While weexpect that the protocols generated by our compiler will not beas efficient as hand-tuned approaches, the performance resultsare already promising.

7. APPLICATIONSThe initial focus of our compiler has been for transforming

discrete-log based signature schemes and encryption schemesinto secure two-party implementations. However, our com-piler can be applied to a much broader range of applicationsthat are also of interest. Here we list two such applications.

7.1 Password hardeningIn [15], a password hardeningprotocol is described to en-

able a user to obtain a strong secret from a password � by inter-acting with a server (which does not learn the secret obtained).The protocol uses public primes p; q such that p = 2q + 1and a public function f that maps passwords to elements inZq. The server initially selects a secret value d for the user,and the user interacts with the server using her password � toretrieve the stronger secret f(�)d mod p as follows: (i) The

216

user picks k R Zq, computes r f(�)k mod p and sendsit to the server; (ii) the server computes s rd mod p and

sends it to the user; and (iii) the user computes sk�1

mod p,which is the strong secret.

The full paradigm proposed by [15] involves a client per-forming this password hardening protocol with multiple serversindependently. An alternative that enables the service to bedistributed transparently to the client (i.e., the client still com-municates with only one server) would be to automatically im-plement a distributed server using our compiler, consisting oftwo servers that jointly compute s using shares of d. Clienttransparency is beneficial if the server must be distributed with-out changing legacy clients, for example.

7.2 Oblivious transferSome oblivious transfer (OT) protocols (e.g., [2, 27]) can be

transformed into distributed oblivious transfer protocols [26],using our compiler. The goal of a 1-out-of-N OT protocolis to allow a receiver R to retrieve one of N secrets from asender S so that S does not learn which of the N secrets Rretrieved and so that R receives only one of the N secrets (andlearns no information about the others). In a distributed OTprotocol, the sender is distributed into multiple senders andeach of them holds shares of the secrets. Our compiler enablesthe distribution of S into two senders automatically for theprotocols mentioned above.

8. CONCLUSIONSWe have described the construction of a compiler that au-

tomatically generates two-party computation protocols start-ing from the specification of a computation involving one ormore secret values. The two-party protocol is generated bycomposing building blocks for the fundamental arithmetic op-erations: addition, multiplication, exponentiation, inversion,modular reduction. Each building block protocol consists oftwo or more primitive protocols, that intuitively are “one-way”protocols (are initiated by one of the parties and the initiatorcan transmit at most one message to the receiver). As futurework, we would like to explore further methods of combiningdirectly the primitive protocols, parallelizing the computation.

The two-party protocols generated by our compiler are sim-ulatable. This property allows us to prove that the security ofthe input function to the compiler is preserved by our two-party protocol against arbitrary misbehavior of either party.The security of the two-party protocol additionally relies onthe security of the encryption scheme used for the commit-ments of secret shares and on the security of the zero knowl-edge proofs involved. For illustration, in Appendix A we showa proof of security in the case when the input function is asignature scheme. There are also other applications of ourcompiler in the context of protocols that require a trusted thirdparty or trusted server (e.g. key distribution, fair exchange, keyretrieval). The trusted party could be replaced by two parties,eliminating the single point of failure.

9. ACKNOWLEDGEMENTSWe would like to thank Ke Yang for his helpful comments

and discussions.

10. REFERENCES[1] B. Barak, A. Herzberg, D. Naor, and E. Shai. The

proactive security toolkit and applications. In Proc. 6thACM Conf. Computer and Communications Security,pp. 18–27, Nov. 1999.

[2] M. Bellare, S. Micali. Non-interactive oblivious transferand applications. In Proc. CRYPTO ’89, 1989.

[3] M. Bellare, R. Sandhu. The security of practicaltwo-party RSA signature schemes. 2001.

[4] M. Bellare and P. Rogaway. Random oracles arepractical: A paradigm for designing efficient protocols.In Proc.1st ACM Conf. Computer and CommunicationsSecurity, pp. 62–73, Nov. 1993.

[5] J. Benaloh. Dense probabilistic encryption. In Workshopon Selected Areas of Cryptography, pp. 120–128, 1994.

[6] M. Blum, A. DeSantis, S. Micali, and G. Persiano.Noninteractive zero-knowledge. SIAM Journal ofComputing20(6):1084–1118, 1991.

[7] M. Bellare, A. Desai, D. Pointcheval, and P. Rogaway.Relations among notions of security for public-keyencryption systems. In Proc. CRYPTO ’98(LNCS1462), 1998.

[8] D. Boneh, X. Ding, G. Tsudik, and M. Wong. A methodfor fast revocation of public key certificates and securitycapabilities. In Proc. 10th USENIX Security Symposium,Aug. 2001.

[9] C. Boyd. Digital multisignatures. In H. J. Beker andF. C. Piper, editors, Cryptography and Coding, pp.241–246. Clarendon Press, 1986.

[10] R. Cramer and V. Shoup. A practical public keycryptosystem provably secure against adaptive chosenciphertext attack. In CRYPTO ’98, 1998.

[11] R. Cramer and V. Shoup. Signature schemes based onthe strong RSA assumption. ACM Transactions onInformation and System Security3(3):161–185, 2000.

[12] A. De Santis, G. Di Crescenzo, R. Ostrovsky,G. Persiano, and A. Sahai. Robust non-interactive zeroknowledge. In Proc. CRYPTO 2001(LNCS 2139), pp.566–598, 2001.

[13] Y. Desmedt. Society and group oriented cryptography: anew concept. In Proc. CRYPTO ’87(LNCS 293), pp.120–127, 1987.

[14] Y. Desmedt and Y. Frankel. Threshold cryptosystems. InProc. CRYPTO ’89(LNCS 435), pp. 307–315, 1989.

[15] W. Ford, B. Kaliski. Server-assisted generation of astrong secret from a password. In Proc. 5thInternational Workshop on Enterprise Security, 2000.

[16] R. Ganesan. Yaksha: Augmenting Kerberos with publickey cryptography. In Proc. 1995 ISOC Network andDistributed System Security Symposium, Feb. 1995.

[17] R. Gennaro, S. Jarecki, H. Krawczyk, and T. Rabin.Robust threshold DSS signatures. In Proc.EUROCRYPT ’96(LNCS 1070), pp. 354–371, 1996.

[18] S. Goldwasser and S. Micali. Probabilistic encryption.Journal of Computer and System Sciences28:270–299,1984.

[19] S. Goldwasser, S. Micali and R. L. Rivest. A digitalsignature scheme secure against adaptivechosen-message attacks. SIAM Journal of Computing

217

17(2):281-308, Apr. 1988.[20] P. Horster, H. Petersen, and M. Michels. Meta-ElGamal

signature schemes. In Proc. 2nd ACM Conf. Computerand Communications Security, pp. 96–107, Nov. 1994.

[21] P. MacKenzie and M. K. Reiter. Networkedcryptographic devices resilient to capture. DIMACSTechnical Report 2001-19, May 2001. Extended abstractin 2001 IEEE Symposium on Security and Privacy, May2001.

[22] P. MacKenzie and M. K. Reiter. Two-party generation ofDSA Signatures. In Proc. CRYPTO 2001(LNCS 2139),Aug. 2001.

[23] A. Menezes, P. van Oorschot, S. Vanstone. Handbook ofApplied Cryptography. CRC Press, 1996.

[24] D. Naccache and J. Stern. A new public-keycryptosystem. In Proc. EUROCRYPT ’97(LNCS 1233),pp. 27–36, 1997.

[25] A. Nicolosi, M. Krohn, Y. Dodis, D. Mazieres. Proactivetwo-party signatures for user authentication. In Proc.10th ISOC Network and Distributed System SecuritySymposium, Feb. 2003.

[26] M. Naor, B. Pinkas. Distributed oblivious transfer. InProc. ASIACRYPT 2000, Dec. 2000.

[27] M. Naor, B. Pinkas. Efficient oblivious transferprotocols. In Proc. SODA 2001, Jan. 2001.

[28] T. Okamoto and S. Uchiyama. A new public-keycryptosystem, as secure as factoring. In Proc.EUROCRYPT ’98(LNCS 1403), pp. 308–318, 1998.

[29] P. Paillier. Public-key cryptosystems based oncomposite degree residuosity classes. In Proc.EUROCRYPT ’99(LNCS 1592), pp. 223–238, 1999.

[30] M. Reiter, M. Franklin, J. Lacy, R. Wright. The keymanagement service. Journal of Computer Security4(4):267–297, 1996.

[31] R. L. Rivest, A. Shamir, and L. Adleman. A method forobtaining digital signatures and public-keycryptosystems. Communications of the ACM21(2):120–126, Feb. 1978.

[32] A. Shamir. How to share a secret. Communications ofthe ACM22, 1979.

[33] D. Song, A. Perrig and D. Phan. AGVI — Automaticgeneration, verification, and implementation of securityprotocols. In Proc. 13th Conference on Computer AidedVerification, July 2001.

[34] T. Wu, M. Malkin, D. Boneh. Building intrusion tolerantapplications. In Proc. 8th USENIX Security Symposium,pp. 79-91, Aug. 1999.

[35] A. Yao. Protocols for secure computation. In Proc. 23IEEE Symposium on Foundations of Computer Science,pp. 160–164, 1982.

[36] L. Zhou, F. Schneider, R. van Renesse. COCA: A securedistributed on-line certification authority. In ACMTransactions on Computer Systems20(4), Nov. 2002.

APPENDIX

A. SIMULATABILITY OF THE BUILD-ING BLOCK PROTOCOLS

In defining simulatability of a two-party building block pro-tocol, we consider two cases, depending on the output param-eter of the protocol being secret or public.

DEFINITION A.1. (Simulatability for Building Block Pro-tocols with Secret Output) LetP = P1 k P2 k : : : Pi bea composition ofi building block protocols. The last build-ing block protocolPi with secret output is simulatable if givenan adversaryA=(A1; A2) that compromises one of the par-ties C, there exists a simulatorSIMU for the uncompromisedparty U such that:DistAi (U; SIMU) = Pr(EXPind�sr

A;1 = 1)�

Pr(EXPind�srA;0 = 1) is negligible, where:

EXPind�srA;b :

(Su; Sc; Ps) I(1�)

z AU(Su;Sc;Ps)1 (1�; Sc; Ps)

b0 ALR(Su;Sc;Ps;L;b)2 (z)

outputb0

Here Su denotes the secret parameters of the uncompro-mised partyU, Sc the secrets of the corrupted partyC, Psthe public parameters of the system,� the security parame-ter, I the initialization algorithm;U(Su; Sc; Ps) is an oraclethat givenSu; Sc; Ps executes the uncompromised party in theprotocolP up to building blockPi�1, z is the state of the ad-versary andL is a list of commitments produced by calls to theU oracle; the oracleLR is defined asLR(Su; Sc; Ps; L; b) =UPi(Su; Sc; Ps; L) if b = 0 (UPi is the execution of the uncom-promised party in building blockPi), andLR(Su; Sc; Ps;L; b) = SIMU;Pi

(Sc; Ps; L) if b = 1 (SIMU;Piis the simula-

tion of the uncompromised party in building blockPi).

The definition of simulatability for building block protocolswith public output is similar to this definition, with the onlydifference that the simulator SIMU is also given as input thepublic output of the protocol.

Notation. Consider a protocol P = P1 k P2 k : : : Pi.Throughout the rest of the paper we use the following nota-tion: SIMERR�iB is the simulation error of proof �iB used inthe B protocol from Pi; wiA denotes the set of A’s commit-ments of its secret shares from protocol Pi; SERR�iA(wiA) isthe soundness error of the proof �iA used in the A protocolfrom Pi; SIM�iB is the simulator for the proof �iB; AdvE(A)is the advantage of A for the encryption scheme E , as definedin [7, Property IND-CPA]. B0 denotes the protocol B, exceptthat in addition to checking all the zero knowledge proofs gen-erated by A, it decrypts A’s commitments (having access toA’s secret key) and checks explicitly the predicates of the zeroknowledge proofs.

The general simulatability theorem for an A-compromisingforger is given below (the theorem for a B-compromising forgeris similar to this).

THEOREM A.2. LetA be anA-compromising attacker forP = P1 k � � � k Pi . Then there is a simulationSIM-B of theB protocol inP and a distinguisher algorithmD such that:

218

1. If Pi is one ofGenerate, Mult2Secrets, InvSe-cret, ModQ, Add2Mult or Mult2Add then:

DistDi (B,SIM-B) � AdvE(A) + SIMERR�iB+Pij=1 SERR�jA(wjA)

DistDi (B0,SIM-B) � AdvE(A) + SIMERR�iB

2. If Pi is one ofAdd2Secrets, AddSecretPub orMultSecretPub then:

DistDi (B, SIM-B) � AdvE(A) +Pi

j=1 SERR�jA(wjA)

DistDi (B0,SIM-B) � AdvE(A)

3. IfPi is one ofRevealMult,RevealAdd or Reveal-Exp then:

DistDi (B, SIM-B) � SIMERR�iB+Pi

j=1 SERR�jA (wjA)

DistDi (B0, SIM-B) � SIMERR�iB

The proof of this theorem is omitted due to space limita-tions, but will appear in the full paper. We have now all thetools to complete the proof of Theorem 5.2:

Proof of Theorem 5.2.Assume an A-compromising forgerF forges a signature in the S-SIG scheme with probability �.Let (BQ1

1; : : : ;BQ1q1B

), : : :, (BQn1 ; : : : ;BQ

nqnB

) denote all thequeries made to the B oracle, and let qB denote the total num-ber of queries to the B oracle. Hence qB must be polynomialin the security parameter and

Pni=1 qiB = qB.

We construct a simulation SIM of S-SIG that takes as inputa SIG public key, a corresponding signature oracle, a publickey/secret key pair (pkA; skA) of the encryption scheme E anda public key pkB for E . SIM responds to query BQi to the Boracle as follows:

1. If Pi = P1, then the signature oracle is queried on mes-sage m and the output signature � = (�1; : : : ; �t) issaved. Each �j corresponds to the output of one publicoutput building block Pij , j = 1; : : : ; t. (We made theconvention that only values that are part of the computa-tion output are public.)

2. If Pi is a secret output building block, use the simulatorSIM-B for Pi with input all the input parameters for SIM

and the public output and commitments of all Pi0 , i0 < i,

and output whatever the simulator outputs.

3. If Pi = Pij is a public output building block, then usethe simulator SIM-B for Pij with input all the input pa-rameters for SIM, the public output and commitments ofall Pi0 , i

0 < i, and �j and output whatever the simulatoroutputs.

Now consider a forger F � that takes as input a SIG pub-lic key and corresponding signature oracle, generates a publickey/secret key pair (pkA; skA) and a public key pkB for E , runsSIM using these parameters as inputs, and outputs whatever Foutputs. If F produces a forgery with probability at least �

3

in SIM, F � produces a forgery in the underlying SIG signaturescheme with probability at least �

3.

Otherwise F produces a forgery with probability less than�3

in SIM. Then, an algorithm D that distinguishes betweenthe execution of S-SIG and SIM with probability greater than2�3

can be constructed.Let S-SIG be an intermediate protocol that differs from the

original S-SIG in that in addition to verifying the zero knowl-

edge proofs generated by A, it decrypts A’s commitments (hav-ing access to A’s secret key) and checks explicitly the predi-cates of the zero knowledge proofs. Then, S-SIG = B0. Ifwe denote by S � f1; : : : ; qBg the subset of building blocksin which party A generates a zero knowledge proof, then thedistinguishing probability between S-SIG and S-SIG dependsonly on the soundness error of the proofs from S. We define �to be DistDn (S-SIG; S-SIG) =

Pi2S SERR�iA(wiA).

We have thus 2�3� DistDn (S-SIG,SIM) � DistDn (S-SIG,

S-SIG)+DistDn (S-SIG,SIM))DistDn (S-SIG,SIM) � 2�3��.

This implies that there is at least one building block Pisuch that D distinguishes between B0 and the simulation ofP1 k � � � k Pi, SIM-B, with probability greater than 2�

3qB� �

qB.

To prove this, we use a hybrid argument: we construct a seriesof simulators SIMj ; j = 0; : : : ; qB such that in SIMj the firstj building blocks are executed as in the protocol S-SIG and allthe other building blocks are executed as in the simulation SIM.SIM0 corresponds to SIM and SIMqB corresponds to S-SIG. Wecan write two inequalities for the distinguishing probabilitybetween S-SIG and SIM: 2�

3� � < DistDn (S-SIG,SIM) �

DistDn (SIMqB ;SIMqB�1) + � � � + DistDn (SIM1;SIM0). Fromthis, it follows that there is at least one i; 1 � i � qB such thatDistDn (SIMi;SIMi�1) >

2�=3��qB

. ButDistDn (SIMi;SIMi�1) =

DistDi (B0;SIM-B) > 2�

3qB� �

qB.

We further distinguish three cases:

1. Pi is one of: Generate, Mult2Secrets, InvSe-cret, ModQ, Add2Mult or Mult2AddThen, from theorem A.2: 2�

3qB� �

qB� DistDi (B

0;SIM-B) � AdvE (A)+SIMERR�iB and it follows thatAdvE(A)� �

3qB� �

2qBor SIMERR�iB �

�3qB� �

2qB. A simple anal-

ysis shows that AdvE(A) � �6qB

or SIMERR�iB ��

6qBor � � �

3. If the last is true, then there exists at least one

j 2 S such that SERR�jA (wj) ��

3qB.

2. Pi is one of: Add2Secrets,AddSecretPub or Mult-SecretPub

Then, from theorem A.2: 2�3qB� �

qB� DistDi (B

0;SIM-B) � AdvE (A) and it follows that either AdvE(A) ��

3qBor � � �

3.

3. Pi is one of: RevealMult, RevealAdd or Reveal-Exp

Then, from theorem A.2: 2�3qB� �

qB� DistDi (B

0;SIM-B) � SIMERR�iB and it follows that either SIMERR�iB ��

3qBor � � �

3.

The conclusion of the theorem follows from the three cases.

219