14
Usable optimistic fair exchange Alptekin Küpçü a,,1 , Anna Lysyanskaya b a Department of Computer Engineering, Koç University, _ Istanbul, Turkey b Department of Computer Science, Brown University, Providence, RI, USA article info Article history: Received 4 April 2010 Received in revised form 3 June 2011 Accepted 5 August 2011 Available online 23 August 2011 Keywords: Barter BitTorrent Peer-to-peer file sharing Optimistic fair exchange Electronic cash Verifiable encryption abstract Fairly exchanging digital content is an everyday problem. It has been shown that fair exchange cannot be achieved without a trusted third party (called the Arbiter). Yet, even with a trusted party, it is still non-trivial to come up with an efficient solution, especially one that can be used in a p2p file sharing system with a high volume of data exchanged. We provide an efficient optimistic fair exchange mechanism for bartering digital files, where receiving a payment in return for a file (buying) is also considered fair. The exchange is optimistic, removing the need for the Arbiter’s involvement unless a dispute occurs. While the previous solutions employ costly cryptographic primitives for every file or block exchanged, our protocol employs them only once per peer, therefore achieving an O(n) effi- ciency improvement when n blocks are exchanged between two peers. Our protocol uses very efficient cryptography, making it perfectly suitable for a p-2-p file sharing system where tens of peers exchange thousands of blocks and they do not know beforehand which ones they will end up exchanging. Therefore, our system yields up to one-to-two orders of magnitude improvement in terms of both computation and communication (40 s vs. 42 min, 1.6 MB vs. 200 MB). Thus, for the first time, a provably secure (and privacy-respecting when payments are made using e-cash) fair exchange protocol can be used in real bartering applications (e.g., BitTorrent) [14] without sacrificing performance. Ó 2011 Elsevier B.V. All rights reserved. 1. Introduction Fairly exchanging digital content is an everyday prob- lem. A fair exchange scenario commonly involves Alice and Bob. Alice has something that Bob wants, and Bob has something that Alice wants. A fair exchange protocol guarantees that at the end either each of them obtains what (s)he wants, or neither of them does. (See [39] for more details and examples.) In this paper, we consider a general file exchange (bartering) scenario, inspired by the BitTorrent [22] peer -to-peer file sharing protocol. Alice has several files (BitTorrent blocks) of interest to Bob, and Bob has several files (blocks) of interest to Alice. They do not know ahead of time how many or which blocks they will end up exchanging. They want to perform a fair exchange: Alice should get Bob’s file (block) if and only if Bob gets Alice’s file (block). In a signature fair exchange [4,3,2], there is a verification mechanism (i.e., the public key) that enables the sender to verifiably encrypt the signature so that the receiver can check that the encrypted signature verifies. No such efficient verifiable encryption method is currently known for exchanging files. Therefore, a compensation is required after the fact if one of the parties cheats. In our scenario, we are assuming that Alice/Bob will be equally happy to get a payment in return for her/his file. Thus, exchanging a file with a payment (buying) is also consid- ered fair, as in some previous work [4,8,18,36,35]. One of the hardest points in creating a usable optimistic fair exchange protocol suitable for p-2-p file sharing appli- cations is that the peers to contact and the content to exchange are not pre-defined. BitTorrent clients keep connecting to different peers to obtain different blocks. 1389-1286/$ - see front matter Ó 2011 Elsevier B.V. All rights reserved. doi:10.1016/j.comnet.2011.08.005 Corresponding author. Tel.: +1 347 625 75 87. E-mail addresses: [email protected] (A. Küpçü), [email protected] (A. Lysyanskaya). 1 Work done at Brown University. Computer Networks 56 (2012) 50–63 Contents lists available at SciVerse ScienceDirect Computer Networks journal homepage: www.elsevier.com/locate/comnet

Usable optimistic fair exchange

Embed Size (px)

Citation preview

Page 1: Usable optimistic fair exchange

Computer Networks 56 (2012) 50–63

Contents lists available at SciVerse ScienceDirect

Computer Networks

journal homepage: www.elsevier .com/locate /comnet

Usable optimistic fair exchange

Alptekin Küpçü a,⇑,1, Anna Lysyanskaya b

a Department of Computer Engineering, Koç University, _Istanbul, Turkeyb Department of Computer Science, Brown University, Providence, RI, USA

a r t i c l e i n f o a b s t r a c t

Article history:Received 4 April 2010Received in revised form 3 June 2011Accepted 5 August 2011Available online 23 August 2011

Keywords:BarterBitTorrentPeer-to-peer file sharingOptimistic fair exchangeElectronic cashVerifiable encryption

1389-1286/$ - see front matter � 2011 Elsevier B.Vdoi:10.1016/j.comnet.2011.08.005

⇑ Corresponding author. Tel.: +1 347 625 75 87.E-mail addresses: [email protected] (A. Küpçü)

(A. Lysyanskaya).1 Work done at Brown University.

Fairly exchanging digital content is an everyday problem. It has been shown that fairexchange cannot be achieved without a trusted third party (called the Arbiter). Yet, evenwith a trusted party, it is still non-trivial to come up with an efficient solution, especiallyone that can be used in a p2p file sharing system with a high volume of data exchanged.

We provide an efficient optimistic fair exchange mechanism for bartering digital files,where receiving a payment in return for a file (buying) is also considered fair. The exchangeis optimistic, removing the need for the Arbiter’s involvement unless a dispute occurs. Whilethe previous solutions employ costly cryptographic primitives for every file or blockexchanged, our protocol employs them only once per peer, therefore achieving an O(n) effi-ciency improvement when n blocks are exchanged between two peers. Our protocol usesvery efficient cryptography, making it perfectly suitable for a p-2-p file sharing system wheretens of peers exchange thousands of blocks and they do not know beforehand which ones theywill end up exchanging. Therefore, our system yields up to one-to-two orders of magnitudeimprovement in terms of both computation and communication (40 s vs. 42 min, 1.6 MB vs.200 MB). Thus, for the first time, a provably secure (and privacy-respecting when paymentsare made using e-cash) fair exchange protocol can be used in real bartering applications (e.g.,BitTorrent) [14] without sacrificing performance.

� 2011 Elsevier B.V. All rights reserved.

1. Introduction

Fairly exchanging digital content is an everyday prob-lem. A fair exchange scenario commonly involves Aliceand Bob. Alice has something that Bob wants, and Bobhas something that Alice wants. A fair exchange protocolguarantees that at the end either each of them obtainswhat (s)he wants, or neither of them does. (See [39] formore details and examples.)

In this paper, we consider a general file exchange(bartering) scenario, inspired by the BitTorrent [22] peer-to-peer file sharing protocol. Alice has several files(BitTorrent blocks) of interest to Bob, and Bob has severalfiles (blocks) of interest to Alice. They do not know ahead

. All rights reserved.

, [email protected]

of time how many or which blocks they will end upexchanging. They want to perform a fair exchange: Aliceshould get Bob’s file (block) if and only if Bob gets Alice’sfile (block). In a signature fair exchange [4,3,2], there is averification mechanism (i.e., the public key) that enablesthe sender to verifiably encrypt the signature so that thereceiver can check that the encrypted signature verifies.No such efficient verifiable encryption method is currentlyknown for exchanging files. Therefore, a compensation isrequired after the fact if one of the parties cheats. In ourscenario, we are assuming that Alice/Bob will be equallyhappy to get a payment in return for her/his file. Thus,exchanging a file with a payment (buying) is also consid-ered fair, as in some previous work [4,8,18,36,35].

One of the hardest points in creating a usable optimisticfair exchange protocol suitable for p-2-p file sharing appli-cations is that the peers to contact and the content toexchange are not pre-defined. BitTorrent clients keepconnecting to different peers to obtain different blocks.

Page 2: Usable optimistic fair exchange

A. Küpçü, A. Lysyanskaya / Computer Networks 56 (2012) 50–63 51

Fault-tolerance issues, connectivity problems, and avail-ability of data blocks are all factors affecting from whomwhich block should be obtained. Our protocol uniquely ad-dresses these issues by removing the need to know whatcontent to exchange with whom beforehand.

In a nutshell, in our protocol, Alice sends a verifiableescrow of a payment (e.g., e-coin) to Bob first. Then, theyexchange encrypted files. Afterward, Alice sends Bob anescrow of her key with her signature on the escrow. Then,Bob sends Alice the key to his file. Finally, Alice sends Bobthe key to her file. Since Bob has a verifiable escrow of an e-coin and an escrow of a key before he sends his key toAlice, he is protected. In the worst case, if Alice does notprovide the correct key and the key escrow contains gar-bage, Bob can go to the Arbiter and obtain Alice’s payment.The escrow of the payment cannot contain garbage, be-cause it was formed using a verifiable escrow. After the ex-change of the verifiable escrow, the rest of our protocol canbe repeated as many times as necessary to exchange multi-ple files (even if the number and content of the files wasnot known in advance), unless there is a dispute.

We provide two versions of the protocol: in the first one(the one described briefly above) only one party provides averifiable escrow. This version requires the use of timeoutsfor dispute resolution purposes. We provide another ver-sion that needs both parties to provide verifiable escrowsbut requires no timeouts. Both versions are very efficientsince they use only one (resp. two) expensive primitives(verifiable escrow and payment) regardless of the numberof files exchanged. We stress the fact that our timeouts canbe very large (e.g., a day or a week) to allow for unexpectedsituations in which the participants act honestly (e.g., net-work failure), and thus require very loose synchronization(e.g., one hour difference), and users can freely participatein other exchanges without waiting for the timeout.

1.1. Previous work

It is well-known that a fair exchange protocol is impos-sible without a trusted third party (TTP) [42] (called theArbiter) that ensures that Alice cannot take advantage ofBob, and vice versa. Without loss of generality, Alice willhave to send the last message of the protocol, and we wantto protect Bob in case she chooses not to do so. Without anarbiter, gradual release type of protocols where partiessend pieces to each other in rounds can provide only weak-er forms of fairness, and are much less efficient [11,13].

Luckily, the impossibility result [42] does not require thatthe Arbiter be involved in each transaction, but simply thatthe Arbiter exists. If Alice and Bob are both well-behaved,there is no need for the Arbiter to do anything (or even knowan exchange took place). Micali [38], Asokan et al. [2,4,3]investigated this optimistic fair exchange scenario in whichthe Arbiter gets involved only in case of a dispute. Two suchprotocols [4,30] were analyzed in [45] (see also [7]).

Asokan, Shoup and Waidner (ASW) [4] gave the firstprovably secure and completely fair optimistic exchangeprotocol for exchanging digital signatures. Later on,Belenkiy et al. [8] gave a protocol for buying digital contentin exchange for e-cash, building on top of the ASW proto-col. They provided an optimization for the Arbiter so that,

unlike in the ASW protocol, the amount of work that theArbiter is required to do depends only logarithmically onthe size of the file. They also assume there is an additionalTTP (which we call the Tracker) that provides a means ofverification that the file actually contains the right content(e.g., using hashes). Such entities certifying hashes alreadyexist in current BitTorrent systems [22].

Belenkiy et al. [8] used e-cash (introduced by Chaum[20]), in particular, endorsed e-cash [18] in their construc-tions. The reason is that other forms of payments (signa-tures or electronic checks used in [4,36]) do not provideany privacy. In our protocols, any form of payment canbe employed, but we will also use endorsed e-cash in oursample instantiation since it is efficient and anonymous.See Section 7 for more discussion on employing differentpayment systems.

1.2. Contributions

We present the most efficient fair exchange known tous, where the efficiency is comparable to a simple unfair ex-change if performed multiple times between the same pairof users, even when peers do not know beforehand whichblocks they will end up exchanging. Using the best previouswork (Belenkiy et al. barter protocol [8]), n pairs of blockscan be exchanged using n transactions, each of which re-quires a costly step involving expensive cryptographicprimitives (a verifiable escrow and an e-coin). Our contri-bution is a very efficient fair exchange protocol usingwhich this can be done with only one (or two if we donot want to employ timeouts) step in total that involvesthe same expensive primitives (verifiable escrow and pay-ment). This is a property that is unique to our protocol: in-stead of employing the costly primitives for every file orblock that is exchanged, we employ them once per peer,even when peers do not know beforehand which blocksthey will end up exchanging. Then, exchanging multiplefiles/blocks between peers involves only very efficientcryptography (i.e., symmetric- and public-key encryption,and digital signatures). In a real setting where BitTorrentpeers exchange thousands of blocks with only tens ofpeers, there is one or two orders of magnitude improvementin terms of both computation and communication (40 s vs.42 min computational overhead and 1.6 MB vs. 200 MBcommunication overhead for a 2.8 GB file—for detailednumbers, see Section 8). This means that, with no (i.e., neg-lectable) efficiency loss, our fair exchange protocol can beused to exchange files instead of the unfair protocol cur-rently used by BitTorrent or similar file sharing protocols.

We stress the fact that the timeouts used for disputeresolution purposes in one of our protocols can be verylarge (e.g., one day or week) to allow for unexpected situ-ations in which the participants act honestly (e.g., networkfailure), and thus require very loose synchronization (e.g.,one hour difference), and users can freely participate in otherexchanges without waiting for the timeout.

We take the idea of using verifiable escrow from ASW [4],and the subprotocols of Belenkiy et al. [8] that increase theefficiency of the Arbiter (see Section 4.3). The Arbiter doesabsolutely no work in our protocols, as long as no dispute oc-curs. Our protocols can make use of any type of payments, but

Page 3: Usable optimistic fair exchange

52 A. Küpçü, A. Lysyanskaya / Computer Networks 56 (2012) 50–63

we will show an instantiation using e-cash since it also pro-vides privacy. Our performance evaluation numbers will useendorsed e-cash [18] as the payment mechanism. Note thatother (non-anonymous) forms of payments (e.g., electronicchecks [21]) will be more efficient.

Our additional contribution is definitional. We give ageneral definition of fair exchange of digital content (notjust digital signatures) provided that it can be verifiedusing some verification algorithm (defined in Section 3).Furthermore, our fairness definition covers polynomiallymany exchanges between an honest party and an adver-sary controlling polynomially-many other participants(see [27] for an example fair exchange protocol that is fairfor a single exchange but stops being fair in a multi-usersetting). We then prove our protocol’s security based onthis definition. We sum up the most important propertiesof our protocols below.

Security of our protocol: Our protocols provably sat-isfy the following condition (waiting for at most one time-out period if timeouts are used, or without waiting at all ifno timeouts are used), as long as at least one of the tradingparties (Alice and Bob) is honest:

� either Alice and Bob both get their correspondingfiles,

� or Alice gets Bob’s file and Bob gets Alice’s payment(turns into a buy protocol in effect),

� or neither of them gets anything.

Efficiency of our protocol: We have the followingproperties regarding efficiency:

� An honest user can reuse her e-coin for otherexchanges without waiting for the completion ofthe protocol.

� The overhead of our costly step—verifiable escrowand e-cash—is constant O(1), instead of linearO(n) as in previous best results, when n files orblocks are exchanged.

Already, the Brownie Project [14] is using our protocolsin their BitTorrent deployment. We discuss the efficiencyof our protocols and our initial implementation results inSection 8. Discussion of limitations and future work canbe found in Section 9.

2. Notation

Barter is an exchange of two items, which are digitalfiles in our case. We assume that the reader is familiar withencryption and signature schemes, and hash functions.Further required definitions and notation are given below,although partially, omitting the details not necessary forunderstanding the following fair exchange protocols.

An escrow is a ciphertext under the public key of sometrusted third party (TTP). A verifiable escrow [4,19,15] meansthat the recipient can verify that the contents of the cipher-text satisfy some relation (therefore stating that the cipher-text contains the expected content). A contract (a.k.a. label,

condition, or tag) attached to such a ciphertext defines theconditions under which the TTP should decrypt and giveaway the encrypted secret [46]. The label is public and it isintegrated with the ciphertext in a such way that it cannotbe modified. We will use EArb(a;b) to denote an escrow ofthe secret a under the Arbiter’s public key, with the contractb. Similarly, VEArb(a;b) will denote a verifiable escrow.

Any payment protocol that can efficiently be verifiablyescrowed and is secure can be used in our protocols. Fur-thermore, if privacy is desired, the payments should beanonymous as in e-cash [20]. We provide an instantiationusing endorsed e-cash [18] (which is an extension of com-pact e-cash [17]), since it satisfies all these requirements.Endorsed e-cash splits a coin into an unendorsed coin (de-noted coin0) and endorsement (denoted end). One can thinkof coin0 as an encrypted coin and end as the key. One cancheck if the endorsement end in a given verifiable escrow[19] matches the given unendorsed coin coin0 (withoutlearning the endorsement end). Furthermore, given onlythe unendorsed part coin0, no other party (except the owner)can come up with a valid endorsement end. Endorsed e-cashmoreover has the ability to catch double-spenders. Hence, ifone uses two different coin0, end pairs trying to spend thesame coin twice, (s)he will be caught (and, since her identityis revealed, can be punished). Note that if a party tries to de-posit the same coin twice (using the same coin0, end pair), theoperation can easily be denied by checking against a list ofpast transactions. Lastly, only matching coin0,end pairs canbe linked, unendorsed coins and endorsements preparedfor different exchanges remain unlinkable.

Wherever used, KP will denote a symmetric key of aparty P, generated through an encryption scheme’s keygeneration algorithm. We let c = EncK(f) denote that theciphertext c is an encryption of the plaintext f under thesymmetric key K. Similarly, f = DecK(c) will denote thatthe plaintext f is the decryption of the ciphertext c underthe symmetric key K. Our protocol can make use of any se-cure symmetric encryption scheme (see the book by Katzand Lindell [33] for definitions and constructions).

Let pkP and skP denote public and secret keys for a partyP. Then signsk(x) will denote a signature on x under the se-cret key sk which can be verified using the correspondingpublic key pk. Our protocol can make use of any securepublic-key encryption scheme [24,28] and any secure sig-nature scheme [31].

Furthermore, let Hk be a family of (universal one-way)hash functions [40], where k is the security parameter,and let hash be a hash function uniformly chosen from thefamily Hk of hash functions. Then, hx = hash(x) will denotethat hx is the hash of x under the hash function hash. Wenow introduce a definition we frequently use in the paper.

Definition 1. We say that a key K decrypts correctly, or isthe correct key with respect to a plaintext hash hf and aciphertext c, if the plaintext f0 = DecK(c) has the propertyhash(f0) = hf.

Finally, a negligible probability denotes a probabilitythat is a negligible function of the security parameter(e.g., the key-length of an encryption scheme). A negligiblefunction of n is a function which is smaller than any

Page 4: Usable optimistic fair exchange

A. Küpçü, A. Lysyanskaya / Computer Networks 56 (2012) 50–63 53

inverse polynomial over n with n > N for sufficiently largeN (e.g., neg(n) = 2�n). A non-negligible probability is a prob-ability that is not negligible.

3. (Optimistic) fair exchange

In this section we will give a general definition of fairexchange. Unlike in ASW, our definitions will not be spe-cific to signature exchange, and we will consider polyno-mially-many exchanges between an honest user and anadversary controlling polynomially-many other users. Fur-thermore, we separate and clearly define the roles of alltrusted parties. While providing models and definitionsfor a general framework of (optimistic) fair exchange appli-cable to a broad range of protocols, we will also show itsextensions to our case.

MODEL: The model is adapted from the ASW definition [4],with clarifications and generalizations. There are threeplayers; Alice and Bob exchanging two digital items, andthe Arbiter2 for conflict resolution. All players are assumedto be polynomial time interactive Turing machines. We makeno assumption about the underlying network capability.3

Any message that does not confirm with the protocol speci-fication will be discarded by the honest parties. Any inputwhich does not verify according to the protocol will be re-solved as stated by the protocol or the protocol will beaborted if no resolution is applicable. It is important thatthe Arbiter resolves conflicts on the same exchange atomi-cally.4 Thus, it will only interact with either Alice or Bob atany given time instance, until that interaction ends asspecified by the protocol.5 Sensitive communication (e.g., ex-change of decryption keys for files or endorsement of an e-coin) will be carried out over a secure (and possibly authen-ticated) channel (e.g., SSL can be used to connect to the Arbi-ter, a secure key exchange with no public key infrastructurecan be used for the communication between Alice and Bob).

For protocols using a timeout,6 we assume that the adver-sary cannot prevent the honest party from reaching the Arbi-ter before the timeout. If no timeouts are defined, we assumethe adversary cannot prevent the honest party from reachingthe Arbiter eventually. Hence, the honest party is assumed tobe able to reach the Arbiter as defined by the protocol. Evenwith timeouts, this is not an unrealistic assumption since ourtimeouts can be large (e.g., one day or week).

In our model, we have two additional players, namely theTracker (also in [4,8,22])7 providing verification algorithms,and the Bank dealing with monetary parts of the system.

2 One of the TTPs in ASW.3 Clients will have a local message timeout mechanism like the TCP

timeout, which is small (e.g., one minute). The receiver deals with a messagetimeout exactly as it would deal with a non-verifying input.

4 We present a trade-off between non-atomicity and performance of theArbiter later on.

5 For ease of the Arbiter to find the correct exchange, a random exchangeID can be incorporated into the messages. Since this is only a minorimplementation efficiency issue, we do not want to complicate ourdefinitions with that.6 This is not the message timeout, it is the timeout specified by the protocol,which is generally much longer (e.g., one day or week).

7 ASW has the corresponding TTP in their file exchange scheme. In theirsignature exchange protocol, the public key infrastructure providing thepublic keys can be seen as the Tracker.

SETUP PHASE: Before the fair exchange protocol is run, weassume there is a setup phase. In this one-time pre-ex-change phase, the Arbiter generates his public–privatekey pair (for the (verifiable) escrow schemes) and pub-lishes his public key(s) so that both Alice and Bob obtainit. Optionally, the Arbiter may learn public keys of Aliceand Bob in the setup phase, but our focus is on the casewhere the Arbiter does not need to know anything (andlearns almost nothing, see Section 5.2) about Alice orBob. The adversary cannot interfere with the setup phase.8

In the setup phase, the Bank and the Tracker also generatetheir public–private key pairs and publish their publickeys.

Definition 2. Let SP denote the security parameters of thesystem (e.g., key lengths of the primitives used). Let PP

denote all the public values in the system, including SP,public keys of the trusted parties, and possibly some publicparameters. Let PPGen(SP) be the randomized procedurewhich generates the public values given the securityparameters. Then, define our PP = (pkarbiter,pkbank,pktracker,timeout,SP, and additional parameters for primitivesused).

From now on, we need to talk about multiple exchangestaking place. Alice has files f ð1ÞA ; . . . ; f ðnÞA to be exchangedwith Bob, and Bob has f ð1ÞB ; . . . ; f ðnÞB to be exchanged withAlice (n is a polynomial in SP).9 In general, we can considerthese files as some strings in {0,1}⁄, therefore consider fairexchange of anything that is verifiable. Without loss of gen-erality, the Tracker gives Alice a verification algorithm V

f ðiÞBfor

each file f ðiÞB , and Bob a verification algorithm Vf ðiÞA

for eachfile f ðiÞA before the exchange takes place.

Assume that the content to be exchanged and associ-ated verification algorithms are output by a generationalgorithm Gen(SP) that takes the security parameters asinput and outputs some content to be exchanged, withassociated verification algorithms, and possibly somepublic information about the content. This procedure in-volves a trusted party H and the Tracker. The partiestrust the Tracker in that any input accepted by that ver-ification algorithm will be the content they want. Inother words, they are going to be happy with any con-tent that verifies under that verification algorithm. Inparticular, the content generation process is trusted.The adversary cannot generate ‘‘junk’’ files and ask theTracker to create verification algorithms for them. BitTor-rent forum sites and ratings provide a level of defenseagainst this in practice.

Definition 3. Content and verification algorithms aresecure if " PPT adversaries A and " auxiliary inputsz 2 {0,1}poly(SP) we have (over the randomness of thegeneration algorithms, the adversary, and possibly theverification algorithms)

8 This is the standard trusted setup assumption that says Alice and Bobhave the correct public key of the Arbiter.

9 Note that Alice or Bob can represent multiple entities controlled by theadversary.

Page 5: Usable optimistic fair exchange

54 A. Küpçü, A. Lysyanskaya / Computer Networks 56 (2012) 50–63

Pr PP PPGenðSPÞ;½

f ð1ÞH ;Vf ð1ÞH;pubf ð1ÞH

; . . . ; f ðnÞH ;Vf ðnÞH;pubf ðnÞH

� � GenðSPÞ;

f ð1ÞA ; . . . ; f ðnÞA� �

AðVf ð1ÞH; pubf ð1Þ

H; . . . ;Vf ðnÞ

H;pubf ðnÞ

H;PP; zÞ :

9i 2 ½1; . . . ;n�j Vf ðiÞH

f ðiÞH

� ��– accept

_Vf ðiÞH

f ðiÞA� �

¼ accept�i¼ negðSPÞ

The definition above models the case in which the filesto be exchanged cannot be found by the adversary by someother means10 (and hence exchanging files makes sense forthe adversary), even with the help of associated verificationalgorithms and public information.11

To provide evidence on the generality and applicability ofour definition, we present several example verification algo-rithms for various tasks. For example, a file verification canbe performed using hashes. So, each verification algorithmV

f ðiÞA

for Alice’s file f ðiÞA contains the definition of hash functionused—hash—12 and the hash value hf ðiÞ

A¼ hashðf ðiÞA Þ. The ith

verification algorithm computes the hash of the given inputaccording to the description of the hash function, and acceptsit if and only if the computed hash matches h

f ðiÞA

(see Section5.1 for a security analysis). As another example, considerthe ASW signature exchange protocol, in which each verifica-tion algorithm contains the signature scheme’s description11,the signature public key of Alice pk11

A , and the message mi to besigned. When it receives a signature as input, the ith verifica-tion accepts the signature if and only if it is a valid signatureon message mi under the public key pkA using the signaturescheme. As yet another example, an e-coin verification algo-rithm can take a coin to verify, and use the Bank’s publickey while verifying the non-interactive proofs given. Suchan algorithm is a part of the specification of every e-cashscheme (e.g., see [18,17]). Verifiable encryption schemes(e.g., [19]) and, in general, proof systems also specify a verifi-cation algorithm in their definitions. Such algorithms can beused directly in a fair exchange protocol, satisfying our defini-tion as long as they are secure according to Definition 3.

To summarize, public values are generated usingPPGen(SP) in the setup phase. The files and the verificationalgorithms are generated jointly by the Tracker and sometrusted content generator (e.g., movie distributor) usingthe Gen(SP) procedure. In the context of BitTorrent, thismeans that we trust the content generator about the con-tent, and the Tracker about the verification algorithms. Inpractice, BitTorrent forum sites and ratings on files providethis trust. A ‘‘highly rated’’ BitTorrent user will be trustedabout the content, or alternatively, comments on the for-um sites will warn against bogus content. Besides, eventhe public information leaked from the generation proce-dure does not help the adversary. From now on, we assumethe content and the verification algorithms used are secureand trusted.

10 We assume that the adversary cannot just ‘‘guess’’ an honest partic-ipant’s file, in which case the exchange is trivially unfair.11 For example, if movies are being exchanged, a lot of information ispublicly available about such a movie file, such as actors, length, andrelease date. But these do not enable people to come up those movie files.12 Possibly different for each verification algorithm.

Definition 4. Fair exchange protocol: A fair exchangeprotocol is composed of three interactive algorithms: Alicerunning algorithm A, Bob running algorithm B, and theArbiter running the trusted algorithm T. The content andverification algorithms used need to be secure according toDefinition 3. The security of the exchange is then defined interms of completeness (when Alice and Bob are bothhonest) and fairness (when either Alice or Bob ismalicious).

COMPLETENESS for a (non-optimistic) fair exchange statesthat the interactive run of A, B and T by honest parties re-sults in A getting B’s files and B getting A’s files (assumingan ideal network):

Pr f ð1ÞB ; . . . ;f ðnÞB

� � A f ð1ÞA ; . . . ;f ðnÞA ;Vf ð1ÞB

; . . . ;Vf ðnÞB;PP

� �h

$TðskarbÞB f ð1ÞB ; . . . ;f ðnÞB ;Vf ð1ÞA; . . . ;Vf ðnÞ

A;PP

� �! f ð1ÞA ; . . . ;f ðnÞA

� �i¼1

where the notation describes that A, B and T can all com-municate (in a three-way interaction) following the proto-col, and at the end A outputs f ðiÞB and B outputs f ðiÞA for alli :1, . . . ,n.

OPTIMISTIC COMPLETENESS for an optimistic fair exchangestates that the interactive run of A and B by honest partiesresults in A getting f ðiÞB and B getting f ðiÞA for all i :1, . . . ,n(the Arbiter’s algorithm T is not involved, assuming anideal network). A protocol satisfying optimistic complete-ness also satisfies completeness. Our optimistic complete-ness definition is:

Pr f ð1ÞB ; . . . ;f ðnÞB

� � A f ð1ÞA ; . . . ;f ðnÞA ;Vf ð1ÞB

; . . . ;Vf ðnÞB;PP

� �h

$B f ð1ÞB ; . . . ;f ðnÞB ;Vf ð1ÞA; . . . ;Vf ðnÞ

A;PP

� �! f ð1ÞA ; . . . ;f ðnÞA

� �i¼1

Fairness states that at the end of the protocol, eitherAlice and Bob both get content that passes the verificationalgorithms given to them, or neither Alice nor Bob getsanything that passes the verification, in each of the n ex-changes, even when one of them is malicious.13 This defini-tion is easy to satisfy using a (non-optimistic) fair exchangeprotocol since Alice and Bob can both hand their files to theArbiter, and then the Arbiter can send Bob’s files to Alice andAlice’s files to Bob, if they pass respective verifications. Thus,below, we will define the more interesting case; fairness foran optimistic fair exchange.

It is important to note that the ASW definition of fair-ness applies only to a single exchange, whereas our defini-tion covers polynomially-many exchanges between anhonest party and other players all controlled by the adver-sary. Even though we define fairness in a symmetric way,during the security analysis one may need to considertwo cases independently since the protocol can be asym-metric: the case where Alice is honest but Bob is malicious,and the case where Bob is honest but Alice is malicious.

FAIRNESS: We have an honest player H, and an adversarialplayer A. The honest player runs algorithm A in exchangeswhere he plays the role of Alice, algorithm B in exchangeswhere he plays the role of Bob, and the Arbiter runs the

13 On the contrary, completeness definition only deals with honestparticipants.

Page 6: Usable optimistic fair exchange

A. Küpçü, A. Lysyanskaya / Computer Networks 56 (2012) 50–63 55

algorithm T, all as defined by the protocol. H has filesf ð1ÞH ; . . . ; f ðnÞH to be exchanged with the adversary, and Ahas f ð1ÞA ; . . . ; f ðnÞA to be exchanged with H. The adversary isassumed to control all other players, and hence all interac-tions of the honest player are with parties controlled by theadversary, which is the worst possible scenario coveringmultiple exchanges.

First there is the trusted setup phase as explainedabove, getting the security parameters as input, generatingsecure content and verification algorithms, along withsome associated public information, and giving the appro-priate values to each party. Since the setup phase istrusted, 8i : 1; . . . ;nVf ðiÞH

;Vf ðiÞA;PP are trusted. Then parties

proceed with the fairness game explained below, the hon-est party outputting X and the adversary outputting Y. Atthe end of the game, we require the fairness conditionholds on X, Y, the verification algorithms Vf ð1ÞH

;Vf ð1ÞA; . . . ;

Vf ðnÞH;Vf ðnÞA

, and the public values PP with high probabilityagainst all PPT adversaries A, and all polynomially-longauxiliary inputs

Pr½Setup; FairnessGame : FairnessCondition�¼ 1� negðSPÞ

FAIRNESS GAME: There are three types of interaction in ourfairness game. Type 1 interactions are between H and A.Type 2 interactions are between H and T. Type 3 interac-tions are between A and T.14 The adversary can arbitrarilyinterleave type 1, 2, 3 interactions, but cannot prevent type2 interactions from happening until the timeout if timeoutsare used, or eventually otherwise. The game ends when thehonest party H produces its final output (including abortsand resolutions) in all the started protocols. Without lossof generality, in the fairness game we assume both partieswant to exchange different content in different exchanges(8i – j; f ðiÞH – f ðjÞH and f ðiÞA – f ðjÞA and 8i; j; f ðiÞH – f ðjÞA ).15

FAIRNESS CONDITION: Recall that the honest party’s outputwas X and the adversary’s output was Y at the end of thefairness game. A general fairness condition would be8i : 1; . . . ;n; 9x 2 X : V

f ðiÞAðxÞ ¼ accept() 9y 2 Y : V

f ðiÞHðyÞ ¼

h

accept� meaning that either H and A both get what theywant or both don’t, in each exchange.

Our protocol with payments has a very straightforwardgeneralization of the fairness property. Our fairness condi-tion states that either they both parties get each other’sfile, or one of them gets the other’s file whereas the othergets his payment, or they both get nothing at each ex-change. We believe that a broad range of optimistic fair ex-change protocols can adapt the definition above usingstraightforward extensions whenever necessary.

14 In the implementation, T may need to have a way to differentiate whichone of Alice and Bob he is talking to, which can easily be done in ourprotocols without learning who Alice and Bob are. When necessary, usingone-way function values whose pre-image is known by only one of theparties will suffice.15 If the honest party already has the adversary’s file, the exchange will betrivially fair due to the completeness property. If the adversary already hasthe honest party’s file, then there is no hope for fairness since the adversarycan just abort the protocol but he already has the file. Similar argumentshold for exchanging the same file multiple times.

TIMELY RESOLUTION: Lastly, as pointed out by ASW [4], anoptimistic fair exchange protocol must provide timely res-olution: Alice and Bob must be able to have disputes re-solved within a finite and limited time. In our protocolwithout timeouts, resolution is immediate. In our protocolwith timeouts, we guarantee resolution at the timeout(which is finite and fixed). We furthermore show thattimeouts do not render our system less usable (Alice andBob can freely participate in other exchanges withoutwaiting for the timeout), and so in general we can useour more efficient protocol with timeouts.

We now present two different barter protocols, one thatemploys timeouts (Section 4), and one that does not (Sec-tion 6). Both of our protocols are O(n) times more efficientthan previous protocols [4,3,2,5,39,8,18], when n files orblocks are exchanged, and almost as efficient as an unfairexchange, while still being provably fair.

4. Barter with timeouts

We will show a particular instantiation of our protocol,using endorsed e-cash [18] as the payment and hashes asthe file verification algorithms, and then point out howto generalize it easily, in Section 7. Before the protocol be-gins, we assume Alice has withdrawn an e-coin from theBank. Every time Alice and Bob wants to exchange two files(every time before step 2 of the protocol below), Alice gen-erates her fresh key KA and Bob generates his fresh key KB

for a symmetric encryption scheme. Alice and Bob bothhave their files (fA, fB), have the encrypted versions of theirfiles ðcA ¼ EncKA ðfAÞ; cB ¼ EncKB ðfBÞÞ, have the hashes of theirfiles and encryptions (Alice has hfA

¼ hashðfAÞ;hcA ¼hashðcAÞ, and Bob has hfB ¼ hashðfBÞ;hcB ¼ hashðcBÞ). Be-sides, the Tracker provides them with the respective verifi-cation algorithms: Alice gets hfB , Bob gets hfA .16 Everyoneuses the same time zone (e.g., GMT), and the timeout is aglobally known parameter.17 If anything goes wrong priorto step 5 (no resolution protocol is applicable), the protocolwill be aborted. The protocol proceeds as follows (summa-rized in Fig. 1):

1. Alice creates a fresh public-secret key pair pkA, skA

for a signature scheme. Alice sends a fresh unen-dorsed e-coin coin0 to Bob, along with a verifiableescrow v = VEArb(end;pkA) of the endorsement end,labeled with the signature scheme’s public key.

2. Alice sends Bob ciphertext cA of her file. Bob calcu-lates hcA ¼ hashðcAÞ.18

3. Bob sends Alice ciphertext cB of his file. Alice calcu-lates hcB ¼ hashðcBÞ.

16 We are abusing the notation by using hash values as verificationalgorithms provided by the Tracker hoping that the actual verificationprocedure of hashing the files and comparing the result with values givenby the Tracker is obvious.17 It can easily be a per-exchange parameter known to (or agreed by) bothparties.

18 Alice and Bob can use their choice of (symmetric) encryption schemes(not necessarily the same). This only requires us to add the definition of theencryption scheme used to the messages exchanged. Furthermore, thehashes used will be Merkle hashes [37] for efficiency reasons, as discussedin Section 4.3.

Page 7: Usable optimistic fair exchange

Fig. 1. Our barter protocol with timeouts.

21 The Arbiter can abort this trade forgetting the KB in such a case. This isnot necessary according to our definition (and can even be consideredunfair), but it can be used as a way to punish cheating Alice even more. Inthe worst case, if non-atomicity of the Arbiter is allowed for efficiencyreasons, Alice can obtain KB before Bob proves KA to be incorrect, effectivelyturning our protocol into a buy protocol.

22

56 A. Küpçü, A. Lysyanskaya / Computer Networks 56 (2012) 50–63

4. Alice sends Bob an escrow e ¼ EArbðKA; hfA;hfB ;hcA ;

hcB ; timeÞ and her signature s ¼ signskAðeÞ on that

escrow. The escrow e should encrypt a key andshould be labeled with four hash values hfA

;hfB ;hcA ;

hcB , and a time value. If any of the hash values donot match Bob’s knowledge of those values, or ifthe time value is deviated too much from Bob’sknowledge of the time (e.g., almost one timeout dif-ference), then Bob aborts.19 Moreover, if the signa-ture s on the escrow e does not verify with thepublic key pkA sent in step 1 as part of the verifiableescrow v, Bob aborts the protocol.

5. Bob sends Alice his key KB. Alice checks if the key KB

decrypts the ciphertext cB correctly. If not, Alicedoes not proceed with the next step, and runs Ali-ceResolve, although she might have to run it againjust after the timeout to be able to resolve.

6. Alice sends Bob her key KA. Bob checks if the key KA

decrypts the ciphertext cA correctly. If not, he runsBobResolve; he must do so before the timeout.20

Once step 1 is completed, cheap steps 2–6 can be re-peated to exchange more files, as long as no dispute occurs.Alice and Bob need not know beforehand how many orwhich files/blocks to exchange. Whenever they decide toexchange blocks (before every step 2), it is enough forthem to just obtain their hashes from the Tracker. Actually,in BitTorrent, once you ask for hash of a file, the Trackerprovides you with the hashes of all the blocks in that filealready. Thus, connecting the Tracker for each block isnot necessary in real life.

Below we present the resolution protocols in case of adispute between Alice and Bob. The Arbiter never gets in-volved in a transaction unless there is a dispute.

4.1. BobResolve

Bob needs to contact the Arbiter before the timeout forresolution (current time < time in escrow e + timeout), since

19 We do not require tight synchronization. So, for example, the time valuecan just contain hours, and not minutes and seconds.

20 Bob can run BobResolve immediately after a message timeout. He neednot wait for a long time for Alice.

otherwise the Arbiter is not going to honor his request.Assuming Bob resolves before the timeout, he providesthe Arbiter with the escrow e and signature s that he re-ceived in step 4, and also the verifiable escrow v he re-ceived in step 1 from Alice. The escrow e should belabeled with four hash values hfA

;hfB ;hcA ;hcB , and a time va-lue. The verifiable escrow v should be labeled with a publickey pkA for a signature scheme. If the labels of the escrowsare ill-formed, the Arbiter will not honor the request. TheArbiter checks the signature s using the public key in theverifiable escrow v, and if it verifies, he asks Bob to presenthis correct key KB that verifies using the VerifyKey protocolin Section 4.3 (i.e., it decrypts a ciphertext with hash hcB toa plaintext with hash hfB ). If Bob succeeds in giving the cor-rect key, the Arbiter stores the key KB, decrypts the escrowe and hands in the key KA from the escrow to Bob. Bobchecks if KA decrypts Alice’s file fA correctly. If not, heproves this to the Arbiter using the technique in Section4.3 and gets the endorsement end in the verifiable escrowv from the Arbiter.21 Notice that only Bob may succeed inthe BobResolve protocol with the Arbiter because any otherparty will fail to provide the correct key matching hashes ofBob’s files (see Section 5.1).

4.2. AliceResolve

When Alice contacts the Arbiter for resolution, she asksfor Bob’s key KB. If such a key exists, then the Arbiter sendsKB to her.22 KB has already been verified, so Alice does notneed to perform any further action. If such a key does notexist yet, Alice should come back after the timeout. If, evenafter the timeout KB does not exist, then Alice is assured that

If the Arbiter is allowed to be non-atomical for efficiency reasons, thenhe needs to ask Alice for her key KA, verifying it using the VerifyKeyprotocol in Section 4.3 before giving her KB. This represents a tradeoffbetween the atomicity and efficiency of the Arbiter, which can be resolvedarbitrarily, although it can also be used as a tougher punishment forcheaters.

Page 8: Usable optimistic fair exchange

A. Küpçü, A. Lysyanskaya / Computer Networks 56 (2012) 50–63 57

it will never exist, and can consider that particular trade asaborted.

4.3. Subprotocols

We use two subprotocols from Belenkiy et al. [8] thatmake the interaction with the Arbiter efficient. One proto-col is used to prove that a key is not correct, while theother is used to prove that the key is in fact correct. Forefficiency, Merkle hashes [37] are used in these subproto-cols (see Belenkiy et al. [8] for more information on theprotocols and the use of Merkle hashes).

Proving a key is not correct: Showing that a key K doesnot decrypt a ciphertext c with hash hc to a plaintext f withhash hf can be done efficiently, as Belenkiy et al. suggests.Carol, to prove the key is not correct, gives the Arbiter apart ci of data which does not decrypt correctly. The Arbitercan check if the given part ci matches the Merkle tree hashof the ciphertext, and DecK(ci) does not match the hash ofthe plaintext, using the proof provided by Carol.

Proving a key is correct: Using a challenge-responseprotocol (Belenkiy et al. VerifyKey protocol), one can provethat a key is correct. The Arbiter asks for proofs of the keydecrypting correctly on random chunks. If Bob can replycorrectly to all chunks providing valid proofs for Merklehashes, the the Arbiter accepts Bob’s key. If Bob corrupts1/m fraction of the file, and the Arbiter verifies k randomparts, then the Arbiter will catch Bob with a probabilityof at least 1� 1� 1

m

� �k [8].

Algorithm 4.1. VerifyKey from Belenkiy et al.

Arbiter’s Input: Two Merkle hashes hf and hc, key KBob’s Input: Ciphertext c = c0, . . . ,cn, key KStep 1: Arbiter’s challenge

The arbiter sends Bob a set of random indices I.Step 2: Bob’s response

Bob replies with ci, cproofi, fproofi for every i 2 I,where cproofi

proves that ci is in the Merkle tree corresponding tohc, and fproofi

proves that fi = DecK(ci) is in the Merkle treecorresponding to hf.

Step 3: Verification

The arbiter accepts the key if Bob responds withvalidci, cproofi, fproofi for every i 2 I, and rejects otherwise.

The security of both algorithms relies on the security ofthe universal one-way hash functions as described in Sec-tion 5.1.

5. Security analysis

In this section, we assume that we are given a one-wayfunction, a universal one-way hash function, a chosenplaintext secure encryption scheme, a chosen plaintext se-cure verifiable escrow scheme, a chosen ciphertext secureescrow scheme, an unforgeable signature scheme, and ane-cash scheme which is unforgeable, anonymous and

unlinkable. For precise definitions of security of theseprimitives, please see [29,31,41,40,37,33,25,19,18,8]. Inparticular, we can use the instantiation in Section 8.

Theorem 1. Our efficient barter protocol with timeouts asgiven in Section 4 is a secure optimistic fair exchange protocolaccording to Definition 4 in Section 3.

Proof. It is obvious that our protocol satisfies the optimis-tic completeness (and therefore the completeness) prop-erty. We prove the fairness of our protocol over thefairness game defined in Section 3. Remember that ourfairness condition states that either both parties obtainthe other party’s file, or one party obtains the other party’sfile while the other party obtains the e-coin (effectivelyturning into a buy protocol), or no party obtains anything.

An honest party will always use independent keys foreach ciphertext (s)he sends. Furthermore, endorsed e-cash[18] forces the users to use independent (coin0,end) pairs indifferent exchanges by using randomness contributed byboth parties involved in the exchange. Our goal is that evenif the adversary corrupts all other parties in the system(except the TTPs), he cannot obtain more than the union ofwhat each of these individual corrupted parties wassupposed to obtain from an honest trade with the honestuser.

Security of the Resolution Protocols:We first prove the security of our resolution protocols,

as long as one of the participants is honest. Afterward, forthe rest of the proofs, we will assume those are secure anddo not worry about them.

Claim 1.If BobResolve and AliceResolve protocols are executed in

the ith exchange, ith exchange will be fair on its own.

Proof. BobResolve: When an honest Bob contacts the Arbi-ter, he provides the correct key KB and obtain the decryp-tion of the escrow e from the Arbiter. If this escrowcontained the correct key KA, then we are done. Otherwise,Bob can prove so (as in Section 4.3) and then the Arbiterhands out the endorsement end to Bob. This endorsementis valid due to the security of the verifiable escrow scheme(it can be shown by a reduction). Therefore, an honest Bobwill obtain either the correct key or the endorsement ofAlice.

If a dishonest Bob contacts the Arbiter, he cannotprovide an incorrect key to the Arbiter and make himaccept. This can easily be shown by reduction to thesecurity of universal one-way hash functions [40] (seeSection 5.1) or the VerifyKey protocol of Belenkiy et al. [8](Section 4.3). If dishonest Bob provided the Arbiter hiscorrect key KB and obtained honest Alice’s correct key KA,the only way he can be unfair against an honest Alice is toobtain her coin end in addition. But, Bob cannot obtain endbecause he either has to forge Alice’s signature on anotherescrow e0 of some junk key K 0A which does not decryptcorrectly, or he could break our assumption on the hashfunctions by providing some ciphertext with descriptionhcA which does not give a plaintext with description hfA

Page 9: Usable optimistic fair exchange

58 A. Küpçü, A. Lysyanskaya / Computer Networks 56 (2012) 50–63

when decrypted using Alice’s key KA in the escrow e. So, adishonest Bob cannot obtain the endorsement of an honestAlice. Furthermore, he can obtain Alice’s correct key KA

only if he deposits his correct key KB.

AliceResolve: In this protocol, Alice contacts the Arbiterand asks for Bob’s key. If Bob deposited his key KB to theArbiter, then Alice obtains it. From BobResolve, we knowthat if a key KB exists, it is correct. In case Alice wasdishonest and obtained this key KB from the Arbiter, weknow that honest Bob has already received either thecorrect key or e-coin of Alice using BobResolve. In casewhere Alice was honest but Bob was dishonest, we knowhe could not obtain both the correct key and endorsementof Alice. h

Hence, we can conclude that the resolution protocols donot help the adversary to win the game, and so if theadversary wants to be unfair in the ith exchange, he willnot execute a resolution protocol for that exchange. Nextwe split the analysis of our main protocol into two cases:the case where the honest party plays the role of Alice,and the case where he plays the role of Bob.

Case 1: Honest Alice vs dishonest Bob:

Claim 2. Suppose Bob succeeds in obtaining honest Alice’se-coin with non-negligible probability. Then we can con-struct an adversary AC breaking the e-cash scheme withnon-negligible probability by playing the fairness gamewith Bob.

Proof. AC is given a challenge coin0 and her goal is to out-put an endorsement end. 23 She guesses an index i thatBob will succeed in being unfair, and replaces the coin

0(i)

by the given coin0. Since AC does not know the end(i), she putsgarbage into the verifiable escrow v(i), and sends it to Bob.She fakes the verifiability by using the simulator for the ver-ifiable escrow [4,19].24 For all the other interactions, AC actsexactly as an honest Alice would. Since AC is honest, the ver-ifiable escrow v(i) will never be decrypted by the Arbiter(shown in Claim 1), and by the security of verifiable escrow,the adversary cannot obtain the endorsement by decryptingit, nor can the adversary distinguish it from a verifiableescrow of a valid endorsement (can be shown by a straight-forward reduction to CPA-security of the verifiable escrowscheme, since the verifiable escrow v will never bedecrypted because Alice is honest). At some point, Bob out-puts an endorsement end(j) with non-negligible probability.The probability that i = j is non-negligible by definition(the total number of barters n is a polynomial in SP asdefined in Section 3). If the indices match (i = j), AC outputsthe end(i). Therefore, AC breaks the endorsed e-cash [18] with

23 A detailed proof will give AC two oracles, one for coin0 creation, and onefor end creation. Then, AC will play a CCA-security like game with the e-cashscheme. The challenge coin0 will be the one used in the ith exchange, onwhich AC cannot query the endorsement oracle.

24 The verifiable escrow simulator can require simulating the publicparameters too, but this is allowed and is indistinguishable from real publicparameters due to the security of the verifiable escrow scheme.

non-negligible probability, by endorsing an unendorsed coincoin0 without the endorsement end. h

Claim 3. Suppose Bob, without calling BobResolve, succeeds inobtaining one of honest Alice’s files f ðjÞA with non-negligibleprobability before step 6 of jth exchange for some j (Alice willperform step 6 only if she obtained the correct key KðjÞB fromBob). Then we can construct an adversary AE which breaks theencryption scheme Alice uses with non-negligible probability.

Proof. AE generates her files using the setup phase. Thenshe guesses an index i that Bob will succeed in being unfair,and sends two files to the challenger of the encryptionscheme. AE is given back a challenge ciphertext cA andher goal is to decide which file she sent was encrypted.She replaces the cðiÞA by cA. For the rest of the interaction,AE behaves as an honest Alice. AE does not know the keyKðiÞA , but she can fake the escrow e(i) by encrypting junk init. Due to the security of the escrow scheme, Bob cannotdistinguish it from an honest escrow (can be shown by astraightforward reduction to CCA-security of the escrowscheme). At the end, Bob returns a plaintext f ðjÞA . If theguessed i was correct (i = j), then AE returns f ðiÞA and winswith the same probability as Bob does. Since AE interactswith Bob only polynomially many times, the event i = jhas non-negligible probability, and since Bob has non-neg-ligible probability of obtaining Alice’s file, then AE has non-negligible probability of breaking the encryption schemeused. h

Case 2: Honest Bob vs dishonest Alice:The argument is symmetric to Claim 3. The symmetric

version of AE can easily be reconstructed as BE in this sce-nario, indistinguishable from an honest Bob. Hence, if Aliceobtains Bob’s file before step 5, BE breaks Bob’s encryptionscheme. After step 5, Alice already has Bob’s file, and canchoose not to send her key in step 6. But, the security ofBobResolve guarantees that Bob can obtain Alice’s key ore-coin in exchange to his file from the Arbiter (shown inClaim 1).

Combining these results, fairness for the honest party isguaranteed in all the exchanges, regardless of him playingthe role of Alice or Bob. h

5.1. Universal One-Way Hash Functions

Let Hk be a family of hash functions, where k is the secu-rity parameter. We assume that the following experimenthas negligible probability of success for any polynomial-time adversary A, for sufficiently large k: we have a file fand a hash function hash Hk uniformly chosen from thefamily. Given that file f and the hash function’s descriptionhash (which effectively also means giving hash(f)) as input,A returns a c, K pair, where hash(DecK(c)) = hash(f) butDecK(c) – f. Remember that A cannot control the file’s hash,due to the trusted content and verification algorithm gen-eration process, hence he needs to find a targeted collision.

This requirement is equivalent to the security of Univer-sal One Way Hash Functions (UOWHF) [40]. We first

Page 10: Usable optimistic fair exchange

A. Küpçü, A. Lysyanskaya / Computer Networks 56 (2012) 50–63 59

reduce our assumption to the UOWHF assumption. Specif-ically, let A be a polynomial-time adversary succeeding inthe above attack with non-negligible probability. We canconstruct an adversary B which finds a collision in ourUOWHF as follows: when B is given (f,hash), he runs A on(f,hash) to obtain (c,K). B then checks if DecK(c) = f, in whichcase it fails. Otherwise, if DecK(c) – f but hash(DecK(-c)) = hash(f), then B outputs DecK(c) as the collision. As eas-ily seen, B has the same success probability as A, and haspolynomial runtime complexity.

The reverse reduction is also possible. Let B succeed inattacking UOWHF with non-negligible probability. A, whengiven (f,hash) as the challenge, runs B on (f,hash) to get c0

with hash(c0) = hash(f) and c0 – f. A then picks a randomkey K, and returns (c = EncK(c0),K) as the answer. Obviously,hash(c0 = DecK(c)) = hash(f) but c0 = DecK(c) – f. Hence, ourassumption is equivalent to the UOWHF target collision-resistance assumption.

Our discussion above applies in our trusted content set-ting, where the content and verification algorithm genera-tion process is trusted. If we allow the adversary togenerate his own content (thus content generation is nottrusted), he can as well generate bogus content. Yet, ifwe are in a semi-trusted setting where the adversary is al-lowed to generate his own content as long as it is not bogus(e.g., he can generate a movie file that really is showing themovie), then we need to use collision-resistant hash func-tions for security. The reasoning is that the content may begenerated after the hash function is chosen by the Tracker.This will not affect the practice, since all widely-used hashfunctions are assumed to be collision-resistant.

5.2. Privacy analysis

None of the exchanged material contains information toidentify Alice or Bob (not even Alice’s signature, since it is atemporary -just for the exchange-, not permanent). More-over, even an adversary performing multiple exchangeswith the same honest party cannot link those exchangestogether using the protocol messages since the honestparty uses fresh keys every time and endorsed e-cash isunlinkable (IP address linking or similar means might bepossible, but our protocol does not create any additionalmeans of identification and linking). Furthermore, theArbiter does not necessarily know who he is talking to,apart from the fact that the resolution is on a particular ex-change (possibly identified by a random exchange ID). TheArbiter may be able to find out whether he is talking toAlice or Bob, but not who Alice or Bob is. Anonymous com-munication techniques such as onion routing [26] can beused when necessary. Lastly, e-cash [18] is anonymous,and thus even when Bob deposits the e-coin, no one canknow it was Alice’s e-coin (unless she double-spends).

25 This is showing how the Arbiter can distinguish Alice and Bob usingone-way functions, as discussed in previous footnotes. Other possiblemeasures having the same effect can also be taken.

6. Efficient barter without timeouts

We provide another protocol which does not make useof timeouts. In this case, both parties give e-coins to eachother as a warranty. A similar setup applies here, whereBob is also required to have withdrawn an e-coin. Further-

more, Bob also generates a public–private key pair for hissignature scheme. Details that were explained in our previ-ous protocol will be omitted here.

1. a. Alice sends her unendorsed coin coin0A, along with theverifiable escrow vA = VEArb(endA;pkA) of the endorse-ment to Bob.b. Bob sends his unendorsed coin coin0B, along with hisverifiable escrow vB = VEArb(endB;pkB) of his endorse-ment to Alice.

2. a. Alice sends cA to Bob. Bob computes hcA¼ hashðcAÞ.

b. Bob sends cB to Alice. Alice computes hcB ¼ hashðcBÞ.3. a. Alice picks a random value r from the domain of a

one-way function g, and computes g(r). Alice sendsher escrow eA ¼ EArbðKA; hfA ;hfB ;hcA ;hcB ; gðrÞÞ and her sig-nature sA ¼ signskA

ðeAÞ on her escrow to Bob. Bob abortsthe protocol if the signature sA does not verify under pkA

in vA or the hash values do not match Bob’s knowledgeof those values.b. Bob sends his escrow eB ¼ EArbðKB; hfA ;hfB ;hcA ;hcB ; gðrÞÞand his signature sB ¼ signskB

ðeBÞ on his escrow to Alice.Alice calls AliceAbort below if the signature sB does notverify under pkB in vB, or the hash values or g(r) do notmatch Alice’s knowledge of those values.

4. a. Alice sends her key KA to Bob.b. Bob sends his key KB to Alice.

Regarding efficiency, again, step 1 has to be completedonly once per peer, and then multiple files can be ex-changed by carrying out steps 2–4 as long as both partiesare honest, amortizing the cost of the coin and verifiableescrow exchange in step 1.

The escrows in step 3 are a bit different than the previ-ous protocol. First, there is no time value attached, since notimeouts are used. Furthermore, both escrows need to con-tain a value g(r) where g is a one-way function, and onlyAlice knows r. This is achieved by requiring Alice to picka random r in step 3.a, and then put g(r) in the label ofthe escrow. After receiving Alice’s escrow eA, Bob alsoincorporates g(r) into the label of his escrow eB.25

The new AliceResolve and BobResolve algorithms areboth very similar to the BobResolve in our barter protocolwith timeouts (of course, both parties use the escrows andsignatures received from the other party, AliceResolve getsKB by giving KA, and there are no timeouts), and theyshould be run if the key Alice or Bob receives at step 4 isnot correct, respectively.

The logic behind getting rid of the timeouts is similar tothe idea in ASW [4]. If Alice wants to abort the protocol(because something was wrong with the message she re-ceived in step 3.b, or she did not receive any response,she can do so by contacting the Arbiter using the Alice-Abort protocol below. She no longer needs to wait untilafter the timeout. After receiving (or not receiving) Alice’smessage at step 3.a, Bob can simply abort locally if any-thing is wrong.

Page 11: Usable optimistic fair exchange

60 A. Küpçü, A. Lysyanskaya / Computer Networks 56 (2012) 50–63

6.1. AliceAbort

Alice contacts the Arbiter, handing him her escrow eA,her signature sA on that escrow, and her verifiable escrowvA that contains the public key pkA for the signature. TheArbiter checks the signature first. If it verifies, he requiresAlice to give a value r so that g(r) matches the one-wayfunction value in the label of the escrow eA (thereforeBob cannot succeed in this protocol). Then, the rest pro-ceeds similar to the AliceResolve in our previous protocol.Alice asks the Arbiter for Bob’s key KB. If such a key exists(because Bob resolved before Alice aborted), then the Arbi-ter sends KB to Alice. KB has already been verified, so Alicedoes not need to perform any further action. If such a keydoes not exist yet though, the Arbiter considers that partic-ular trade as aborted, and will perform no further resolu-tions regarding this particular barter.26 (Remember, Aliceneeded to come back after the timeout in our previousprotocol.).

6.2. Analysis of barter without timeouts

The advantage of this protocol is that there is no needfor timeouts. Alice can safely abort the protocol (usingAliceAbort) without waiting in case Bob tries to cheat instep 3.b. Bob can simply abort unilaterally if Alice tries tocheat in step 3.a. Since it is very similar to our protocolwith timeouts, we are not presenting a detailed analysisfor this protocol. Alice performs almost exactly the samemoves as in our previous protocol, and hence all the proofsthere can be applied here, extendable to both Alice andBob, with minor modifications due to minor differencesin the resolution protocols.

Theorem 2. Our efficient barter protocol without timeouts inSection 6 is a secure optimistic fair exchange protocol due tothe Definition 4 in Section 3.

Proof. Omitted due to extreme similarity with the proof ofour protocol with timeouts. The proof of AliceResolve isnow the symmetric version of BobResolve before. Theproof of AliceAbort is very similar. Furthermore, the corre-sponding adversaries AC, AE, BC, and BE are very straightfor-ward to construct. h

The privacy analysis of this protocol is the same as ourprotocol with timeouts. Besides, the generalization abovealso applies to this protocol.

Theorem 3. Our efficient barter protocol without timeoutspreserves the privacy of the honest participants even whenArbiter resolution is required.

26 Similar footnotes as before applies. If, for example, we do not want torely on the security of the Belenkiy et al. VerifyKey protocol here, Alice canprove that Bob’s key was incorrect—if that is the case–and get his e-coinfrom the Arbiter. If Bob already resolved, he must have taken Alice’s correctkey or e-coin. Hence, the exchange is fair, becoming e-coin to e-coinexchange in such a case.

Proof. Same as the proof for our protocol withtimeouts. h

7. Generalized version

We have shown an instance of our protocol which useshashes for verification, and endorsed e-cash for payment.In general, our protocols can employ any secureverification algorithm (see Definition 3) provided by theTracker, instead of the hashes. Similarly, our protocolscan easily make use of other payment methods (see [1]for a compilation) or signatures instead of e-cash, but thenprivacy of the participants will not be preserved. The mod-ification is straightforward, and involves just replacing theverifiable escrow of the e-coin with a verifiable escrow ofany other form of payment.

8. Efficiency analysis

The efficiency of Alice’s and Bob’s parts in the protocolcan be further improved, although this would require theArbiter to perform more work. To improve Alice’s andBob’s efficiency, Bob sends the file unencrypted in step 5,instead of separately sending the ciphertext in step 3 andthe key in step 5, thus eliminating step 3 completely (asimilar logic might also apply to steps 2 and 6). But, in thatcase, the Arbiter needs to keep the whole file for resolutionpurposes instead of only a very short key as in the currentcase. Since such trusted third parties can become the bot-tlenecks of the system, we prefer having the least amountof work to be done by the Arbiter, and let users performslightly more work instead. Moreover, if secrecy of the filesis desired, they will be encrypted anyways.

We consider a concrete instantiation of our protocolusing endorsed e-cash [18], Camenisch-Shoup verifiableescrow [19], AES encryption [25], DSS signatures [41],and RSA-OAEP public key encryption for (non-verifiable)escrow [10]. Our protocol has only neglectable overheadover just doing an unfair exchange. Sending the ciphertextsin steps 2 and 3 just corresponds to sending the files in any(even unfair) exchange.27 The keys sent in steps 5 and 6 areextremely short messages (16 bytes each for 128-bit AESkeys). For a fair exchange, step 4 is still very cheap sincethe only primitives used are an ordinary (non-verifiable)escrow (just a public key encryption), and a signature (ADSS signature created using a 1024-bit key is about 40 bytes,while an RSA-OAEP encryption with a 1024-bit key is about128 bytes).

Assuming IO and CPU can be overlapped, encryption offiles will not add any time. Furthermore, signatures andescrows take only a few milliseconds. The most time con-suming step is sending the blocks themselves, which hasto be done in any case (and encryption does not increasesize). The only real overhead is the first step, where thePaillier-based [43] verifiable escrow (and endorsed e-cash,if used) is costly (see below).

27 We can in general assume that the I/O and CPU can be pipelined so thatthe encryption will not add more time to uploading the files.

Page 12: Usable optimistic fair exchange

A. Küpçü, A. Lysyanskaya / Computer Networks 56 (2012) 50–63 61

Our protocol, in addition to guaranteeing fair barter effi-ciently, is optimized for multi-barter situations. One suchsituation is a file sharing scenario as in BitTorrent [22,8].The peers Alice and Bob are expected to have a long-termbarter relationship. Hence, step 1 needs to be carriedout only once per peer, and remaining cheap steps 2–6would be repeated for each block, whereas previousprotocols required a costly step like step 1 to be per-formed for each block. This greatly amortizes the costlystep 1 in our protocol, when multiple blocks (or files) areexchanged, even when the files/blocks to be exchangedare not pre-defined (they need to be defined only beforeeach execution of step 2).

To give some numbers, consider an average BitTorrentfile of size 2.8 GB made up of about 2500 blocks [32]. Usingprevious optimistic fair exchange protocols, this requires2,500 costly steps (one per block). Our C++ implementationusing endorsed e-cash [18] and Camenisch-Shoup verifi-able escrow [19] takes about 1 s of computation for step1 (most of which is the verifiable escrow) on an averagecomputer (2 GHz). This corresponds to 2500 � 2 s = 42 minof computation overhead. Considering a BitTorrent clientthat connects to about 40 peers, using our protocol, thisoverhead becomes just 40 s, which is neglectable whenexchanging such a big amount of data (this cost will bedominated by the file transfer times). Our network over-head is similarly neglectable (around 40 KB per peer, al-most all of which is the one-time cost of step 1, abouthalf of it being endorsed e-cash). This corresponds to about2500 � 2 � 40 KB = 200 MB total overhead using previousschemes, and only 40 � 40 KB = 1.6 MB total overheadusing our scheme (for a 2.8 GB file).

As for the Arbiter, he checks a signature, sometimes de-crypts a (verifiable) escrow, and performs the VerifyKeyprotocol of Belenkiy et al. [8] (see Section 4.3). The signa-ture check and ordinary escrow decryption takes only mil-liseconds, the verifiable escrow decryption, whennecessary, can take a few hundred milliseconds. The bot-tleneck is the data that the Arbiter needs to download forthe VerifyKey protocol, which is about 22chunks � 16 KB= 352 KB [8]. An important point to note is that the amountof data the Arbiter’s needs to download is independent of thesize of the file that is being exchanged.28

Without considering distributed denial of service(DDoS) attacks, let us provide some numbers for evaluation.To have an idea, consider a p2p system of 1,700,000 users,exchanging 2.8 GB files on the average [32]. Exchangingtwo such files means exchanging 5.6 GB of data. If 1% ofall users are malicious, this can correspond to 17,000 ex-changes requiring an arbiter at a given time (where oneuser is honest and the other is malicious. If both of themare malicious, this number reduces to half of it). We said,in case of a dispute, a peer should upload 352 KB of datato the Arbiter. Assume that the same upload speed is usedwhen trading files and contacting the Arbiter. If we assumethe worst case scenario where the Arbiter can handle onlyone user at a time and every user is active at all times, this

28 Merkle proofs are logarithmic in number of the blocks in the file, butare much smaller in size than the data blocks themselves in practice.

requires having 2 arbiters; with 10% malicious user ratio,we need 11 arbiters. Under the very realistic assumptionthat an arbiter can handle 25 users at a time (e.g., assuming25 times as fast download speed of the Arbiter as the up-load speed of the users [23]), we will need 1 arbiter in thissystem (even with 10% malicious user ratio).

We believe, in many situations, our more efficient pro-tocol with timeouts will be sufficiently useful. Yet, to pro-vide options, we chose to present another efficient barterprotocol that does not require the use of timeouts. Our pro-tocol without timeouts requires two costly operations (step1) instead of one in our protocol with timeouts. As in ourprotocol with timeouts, this cost is independent of thenumber of files exchanged, and becomes neglectable whenmultiple or large files are exchanged. The cost of step 1 willbe doubled for both parties, yet for the rest of the protocolthe cost will stay almost the same. The Arbiter’s cost willbe doubled though, due to the need to perform two costlyresolutions (AliceResolve is as costly as BobResolve now).Nevertheless, using similar numbers as above, if our arbitercan handle 25 users at a time, we still need only 1 arbitereven with 10% malicious user ratio. Some more efficiencyevaluation, limitations and possible solutions are discussedin the next section.

Finally, note that for both of our protocols, there is nogrowing history that needs to be kept. In terms of storage,both parties need to store at most one verifiable escrow,and the messages and blocks for that exchange. Any mes-sages related to previously exchanged blocks can be dis-carded. Thus, during an exchange, the storage overheadof our protocol is less than 1 KB.

9. Limitations and future work

One limitation of our work is the need for theexchanging parties to trust the Arbiter. Alice trusts theArbiter not to give away both her e-coin and the key toher file. Even though giving away the key only makesthe exchange unfair, giving away the coin may result ineven an honest Alice becoming a double-spender.29 Onepossible way to reduce this need for the trust would beusing several arbiters, who do not necessarily know eachother. Alice and Bob can mutually agree on a specific arbi-ter, the Arbiter, before the protocol begins. Since, there is noregistration with the Arbiter in our protocol, any arbitercan accomplish the job.

Fortunately, if a proof of dishonesty is requested, nei-ther the Arbiter, nor Bob, nor anyone else can frame anhonest Alice.30 The Arbiter may be asked to prove Alice’sguilt by presenting a verifiable escrow, a non-verifiableescrow and a signature on it, along with the proofs thatBob’s key decrypts correctly yet Alice’s key in the (non-ver-ifiable) escrow does not. Due to the security of these prim-itives, no one can frame an honest Alice. Of course, thisrequires the Arbiter to store all past resolutions, and Alice’sprivacy has already been invaded by the double-spending

29 This does not result in Alice losing money, but losing her anonymity.30 Of course, this requires yet another trusted entity, called the Judge.

Page 13: Usable optimistic fair exchange

62 A. Küpçü, A. Lysyanskaya / Computer Networks 56 (2012) 50–63

detection. In order to prevent a malicious Alice from fram-ing the Arbiter by intentionally double-spending, we canrequire either Alice’s or the Arbiter’s signature when a coinis being deposited. We leave the issue of efficientlyreducing the need to trust the Arbiter or verifying the Arbi-ter’s behavior without violating Alice’s privacy as a futurework.

As for the bottleneck that can be caused by the centralArbiter, Avoine and Vaudenay [6] show how to employ se-cret sharing techniques [44,12] to distribute the shares ofthe secrets among arbiters. This will decrease the amountof job each arbiter needs to perform, yet it will reducethe efficiency of our resolution protocols. It also allowsfor dilution of trust. As argued in [34], the same techniquescan be applied to our protocol with timeouts. In [9],authors show how to outsource computation, which canbe used as a means to distribute the work of our trustedparties. The Brownie Project [14] is analyzing this strategyto distribute the arbiter and the bank in their BitTorrentdeployment.

As in many deployments, it is possible to mount a dis-tributed denial of service (DDoS) attack on the arbitersby continuously performing fake barters and resolvingwith an arbiter. We leave the protection against such at-tacks (by means like blacklisting IP addresses) to systemand network security researchers. Alternative strategiesof reducing the arbiters’ load were already discussedabove.

Another limitation is that Bob does not need to do anywork to be able to send a response to Alice in our protocolwith timeouts, so he can just send junk. Hence, Bob canmount a distributed denial of service attack against Alice.Yet, he still needs to upload a large file (and can be re-quired to upload first), wasting considerable amount of re-sources (time and bandwidth). Moreover, Alice will not betrading with Bob once he cheats. We leave the issue of ana-lyzing the extent of such attacks, catching such an attacker,and proving such an attack occurred as an open problem.This attack is not possible when our protocol without time-outs is used, since both parties need to do equal amount ofwork.

In terms of the storage load associated with the trustedparties, the techniques from [16] can be applied. Usingthose techniques, the Bank can have a limited storage, asopposed to a groving storage. For example, if every e-coinis valid for a limited but long time (e.g., one month), thenthe bank needs to keep track of only the transactions thathappened in the past period, instead of all past transac-tions. Note that the Arbiter also only needs to have ashort-term memory of past resolutions.

Lastly, our fairness definition states that a file and apayment can be fairly traded, as in previous works[4,8,18,36,35]. The economics of this system, deciding onhow much a file is worth fairly, is outside the scope of thispaper. The participants can somehow agree on the pricebefore our protocol begins (variable pricing), or alterna-tively a system can set the price that will apply to all par-ticipants (fixed pricing). In Belenkiy et al. [8], the authorsassume each block in the BitTorrent system are worthone e-coin. We leave this pricing issue as an interestingapplication-dependent open problem.

10. Conclusion

There already are many scenarios where peers tradecontent [22,32]. These systems unfortunately rely on thehonesty of the peers for providing fairness, partly becauseof the high cost incurred by the previous fair exchange pro-tocols [2–5,8,18,39]. Our protocols uniquely limit the useof the costly primitives (verifiable escrow and e-cash) toonce (or twice) per peer, as opposed to per file/block. Wehave shown in Section 8 that there are one or two ordersof magnitude efficiency gains over previous protocols. Be-sides, most of the existing systems already rely on similartrusted parties [2–5,8,17,18,20,22,32,39,42]. Therefore, forthe first time, by using our protocols, such bartering sys-tems will experience almost no performance loss, whilethe benefit of providing fairness guarantees will be verynoticeable indeed (e.g., see [8] for how the use of fair ex-change can solve the free-riding problem of BitTorrent). Al-ready, the Brownie Project [14] is adopting our protocols intheir BitTorrent deployment.

As a guideline, we suggest that systems which expectlong-term barter relationships and are not willing to usetimeouts use our protocol without timeouts, but systemsthat will conduct mainly short-term barters and can toler-ate timeouts use our protocol with timeouts.

Acknowledgments

This research was supported by NSF cyber trust awardnumber 0627553. The authors would like to thank BrowniePoints project members for their help in the implementa-tion of Cashlib, which is available at http://github.com/brownie/cashlib.

Appendix A. ASW Fair Exchange

We present, for reference, the fair exchange protocol forexchanging signatures, due to Asokan, Shoup, and Waidner(ASW) [4]. Alice and Bob would like to exchange their sig-natures on some contract. The version we present belowdoes not employ timeouts. The protocol in its basic sense(without conflict resolution details) is:

1. Alice sends Bob a non-verifiable escrow of her signa-ture, with a label defining how Bob’s signature shouldlook like. Bob checks if the definition is the correctdefinition.

2. Bob sends Alice a verifiable escrow of his signature, withthe label defining how Alice’s signature should look likeand also attaching the escrow he obtained in step 1.Alice verifies the verifiable escrow. She furthermorechecks if the label is formed correctly. If anything goeswrong at this step or a message timeout occurs, sheaborts the protocols and runs AliceAbort with theArbiter.

3. Alice sends Bob her signature. Bob verifies this signa-ture, and stops and runs BobResolve if it does not verifyor a message timeout occurs.

4. Bob sends Alice his signature. If the signature does notverify, Alice runs AliceResolve.

Page 14: Usable optimistic fair exchange

A. Küpçü, A. Lysyanskaya / Computer Networks 56 (2012) 50–63 63

The AliceAbort, BobResolve and AliceResolve protocolshave a similar logic as ours. AliceAbort tells the Arbiter toconsider that trade as aborted and not to honor any furtherresolution request on that particular trade. BobResolvegets Alice’s signature by providing Bob’s signature, andsimilarly, AliceResolve gets Bob’s signature by providingAlice’s signature. ASW provide a more complicated proto-col for exchanging an electronic check for a digital file,building on top of their signature exchange protocol. Thedetails of both protocols can be found in [4].

References

[1] N. Asokan, P.A. Janson, M. Steiner, M. Waidner, The state of the art inelectronic payment systems, IEEE Computer 30 (1997) 28–35.

[2] N. Asokan, M. Schunter, M. Waidner, Optimistic protocols for fairexchange, in: CCS, 1997.

[3] N. Asokan, V. Shoup, M. Waidner, Asynchronous protocols foroptimistic fair exchange, in: IEEE Security and Privacy, 1998.

[4] N. Asokan, V. Shoup, M. Waidner, Optimistic fair exchange of digitalsignatures, IEEE Journal on Selected Areas in Communications 18 (4)(2000) 591–610.

[5] G. Ateniese, Efficient verifiable encryption (and fair exchange) ofdigital signatures, in: CCS, 1999.

[6] G. Avoine, S. Vaudenay, Optimistic fair exchange based on publiclyverifiable secret sharing, in: ACISP, 2004.

[7] M. Backes, A. Datta, A. Derek, JC. Mitchell, M. Turuani, Compositionalanalysis of contract-signing protocols, Theoretical Computer Science367 (1–2) (2006) 33–56.

[8] M. Belenkiy, M. Chase, C.C. Erway, J. Jannotti, A. Küpçü, A.Lysyanskaya, E. Rachlin, Making P2P accountable without losingprivacy, in: WPES, 2007.

[9] M. Belenkiy, M. Chase, C.C. Erway, J. Jannotti, A. Küpçü, A.Lysyanskaya, Incentivizing outsourced computation, in: NetEcon,2008.

[10] M. Bellare, P. Rogaway, Optimal asymmetric encryption, in:EUROCRYPT, 1994.

[11] M. Ben-Or, O. Goldreich, S. Micali, R.L. Rivest, A fair protocol forsigning contracts, IEEE Transactions on Information Theory 36 (1)(1990) 40–46.

[12] G.R. Blakley, Safeguarding cryptographic keys, in: NationalComputer Conference, 1979.

[13] D. Boneh, M. Naor, Timed commitments, in: CRYPTO, 2000.[14] Brownie Project. <http://cs.brown.edu/research/brownie>.[15] J. Camenisch, I. Damgård, Verifiable encryption, group encryption,

and their applications to group signatures and signature sharingschemes, in: Asiacrypt, 2000.

[16] J. Camenisch, S. Hohenberger, M. Kohlweiss, A. Lysyanskaya, M.Meyerovich, How to win the clonewars: efficient periodic N-timesanonymous authentication, in: CCS, 2006.

[17] J. Camenisch, S. Hohenberger, A. Lysyanskaya, Compact e-cash, in:Eurocrypt, 2005.

[18] J. Camenisch, A. Lysyanskaya, M. Meyerovich, Endorsed e-cash, IEEESecurity and Privacy, 2007.

[19] J. Camenisch, V. Shoup, Practical verifiable encryption anddecryption of discrete logarithms, in: CRYPTO, 2003.

[20] D. Chaum, Bling signatures for untraceable payments, in: CRYPTO,1982.

[21] D. Chaum, B. den Boer, E. van Heyst, S. Mjolsnes, A. Steenbeek,Efficient offline electronic checks, in: EUROCRYPT, 1990.

[22] B. Cohen, Incentives build robustness in bittorrent, in: IPTPS, 2003.[23] L. Cohen, Testimony of Larry Cohen, President of Communications

Workers of America, 2007.[24] R. Cramer, V. Shoup, A practical public key cryptosystem provably

secure against adaptive chosen ciphertext attack, in: CRYPTO, 1998.[25] J. Daemen, V. Rijmen, The Design of Rijndael: AES – The Advanced

Encryption Standard, Springer books (2002).[26] R. Dingledine, N. Mathewson, P. Syverson, Tor: the second-

generation onion router, in: USENIX Security, 2004.[27] Y. Dodis, P.J. Lee, D.H. Yum, Optimistic fair exchange in a multi-user

setting, in: PKC, 2007.

[28] D. Dolev, C. Dwork, M. Naor, Nonmalleable cryptography, SIAMJournal on Computing (2000).

[29] E. Fujisaki, T. Okamoto, D. Pointcheval, J. Stern, RSA-OAEP is secureunder the RSA assumption, Journal of Cryptology 17 (2) (2004) 81–104.

[30] J.A. Garay, M. Jakobsson, P. MacKenzie, Abuse-free optimisticcontract signing, in: CRYPTO, 1999.

[31] S. Goldwasser, S. Micali, R. Rivest, A digital signature scheme secureagainst adaptive chosen message attack, SIAM Journal on Computing(1988).

[32] A. Iosup, P. Garbacki, J. Pouwelse, D.H.J. Epema, Correlating topologyand path characteristics of overlay networks and the Internet, in:GP2PC, 2006.

[33] J. Katz, Y. Lindell, Introduction to Modern Cryptography, Chapmanand Hall/CRC Press, 2007.

[34] A. Küpçü, A. Lysyanskaya, Framework for analyzing optimistic fairexchange protocols with distributed arbiters, Cryptology ePrintArchive, Report 2009/069, 2009.

[35] Y. Lindell, Legally enforceable fairness in secure two-partycomputation, in: CT-RSA, 2008.

[36] O. Markowitch, S. Saeednia, Optimistic fair exchange withtransparent signature recovery, in: FC, 2001.

[37] R. Merkle, A digital signature based on a conventional encryptionfunction, in: CRYPTO, 1987.

[38] S. Micali, Simultaneous Electronic Transactions, US Patent, No.5,666,420, 1997.

[39] S. Micali, Simple and fast optimistic protocols for fair electronicexchange, in: PODC, 2003.

[40] M. Naor, M. Yung, Universal one-way hash functions and theircryptographic applications, in: STOC, 1989.

[41] NIST, Digital Signature Standard (DSS), FIPS, PUB 186-2, 2000.[42] H. Pagnia, F.C. Gärtner, On the impossibility of fair exchange without

a trusted third party, Technical Report, TUD-BS-1999-02, 1999.[43] P. Paillier, Public-key cryptosystems based on composite degree

residuosity classes, in: EUROCRYPT, 1999.[44] A. Shamir, How to Share a Secret, ACM Communications, 1979.[45] V. Shmatikov, JC. Mitchell, Finite-state analysis of two contract

signing protocols, Theoretical Computer Science 283 (2) (2002) 419–450.

[46] V. Shoup, R. Gennaro, Securing threshold cryptosystems againstchosen ciphertext attack, in: EUROCRYPT, 1998.

Alptekin Küpçü has received his Ph.D. fromBrown University Computer Science Depart-ment, and is currently an assistant professorat Koç University Computer EngineeringDepartment. His research mainly focuses onapplied cryptography, and its intersectionwith cloud security, privacy, peer-to-peernetworks, and mechanism design. He has alsoled the development of the Brownie Cashlibcryptographic library.

Anna Lysyanskaya has received her Ph.D.from Massachusetts Institute of TechnologyElectrical Engineering and Computer ScienceDepartment, and is currently an associateprofessor at Brown University Computer Sci-ence Department. She is interested in suchproblems as efficient and provably securecryptographic schemes and protocols, inminimal complexity assumptions for achiev-ing security for various applications, and insecure distributed computation. The mainthrust of her research is on practical crypto-

graphic tools for privacy-preserving transactions.