Privacy-Preserving Multi-Party Bartering Secure Against Active Adversaries

28 Pages·2017·1.03 MB·English

Privacy-Preserving Multi-Party Bartering
Secure Against Active Adversaries
Stefan Wu¨ller1, Ulrike Meyer1, and Susanne Wetzel2
1 RWTH Aachen University, Aachen, Germany
wueller,meyer @itsec.rwth-aachen.de
{ }
2 Stevens Institute of Technology, Hoboken, NJ, USA
[email protected]
Abstract. Amajorityofelectronicbarteringtransactionsiscarriedout
via online platforms. Typically, these platforms require users to disclose
sensitive information about their trade capabilities which might restrict
their room for negotiation. It is in this context that we propose a novel
decentralizedandprivacy-preservingbarteringprotocolformultiplepar-
ties that offers the same privacy guarantees as provided by traditional
bartering and by cash payments. The proposed protocol is even secure
against an active attacker who controls a majority of colluding parties.
1 Introduction
Bartering—the cashless act of exchanging goods and services—has been prac-
ticedsincetheearlydaysofhumanity.Thetraditionalformofbarteringrequires
apartytofindanotherpartysuchthattheiroffersanddemandsalign.Consider
the following example from [13]: Alice demands a tool while Bob demands some
medicine. For the case that each of them offers what the other party demands,
both parties are lucky since they can barter. But for the case that Alice offers
foodinsteadofmedicine,theyhavetofindalargertradecyclewheremorethan
twopartiesexchangetheirofferedcommoditiesinacyclicfashion.So,Aliceand
Bobcouldtrytofindathirdparty,Carol,whoiswillingtoexchangemedicinefor
food. As this simple example already shows, the major drawback of traditional
bartering is the inevitable need for coordination, i.e., a group of parties whose
offers and demands align have to be in the same place at the same time [13]. In
modern economies, this coordination issue was resolved by the introduction of
currencieswhichserveasamediatorandthuseliminatetheneedfortheexplicit
search of trade cycles.
Nevertheless, in recent years bartering became popular again [11]. This is
also due to the emerging of online bartering platforms such as U-Exchange,
BarterQuest,orTradeYa [18,1,17]whichtypicallyprovideavarietyoffunction-
alities facilitating the bartering process (including the cumbersome search for
trade partners) between individuals as well as businesses. These functionalities
comprise supporting the specification of offers and demands; searching, brows-
ing, and filtering the offers of other users; searching for trade partners in some
2 Stefan Wu¨ller, Ulrike Meyer, and Susanne Wetzel
automated fashion; or supporting negotiating of the final exchange rates. How-
ever,aninherentrequirementoftheseplatformsisthatauserhastodiscloseher
offeredanddemandedcommodities(alongwiththecorrespondingquantities)to
at least the operator and oftentimes to all other users—even those who do not
qualify as trade partners.
The goal of this paper is to devise a bartering process that offers the same
privacy guarantees ideally provided by traditional bartering or traditional cash
currencies. More precisely, we require that a party only learns what it receives
and what it has to send (and what can be deduced from it). In particular, a
partydoesnotlearnanythingaboutthecapabilitiesandtheactivitiesofparties
it does not directly trade with. Our solution does not require a (trusted) third
party to observe or coordinate the bartering transactions.
One of the first steps in this direction was proposed in [21,22]. The authors
devise a privacy-preserving multi-party bartering protocol which is based on
secure multi-party computation (SMPC)techniques.However,thisprotocolonly
providessecurityinthesemi-honestmodel,i.e.,underthestrictassumptionthat
all parties follow the protocol specification but try to learn as much information
as possible from participating in the protocol. We extend on the protocol in [21,
22] and propose a privacy-preserving multi-party bartering protocol which pro-
vides security against malicious (i.e., active) adversaries. Analogously to [21,
22], our novel bartering protocol allows a party to specify a quote indicating
its offered and desired commodity as well as the corresponding quantity ranges
at which the party is willing to trade. Given a set of parties along with their
private quotes, our protocol automatically and securely determines the actual
trade comprising the trade partner constellation (i.e., who trades with whom)
aswellasthecommoditiesandquantitiestobetraded.Aparty’squoteremains
private throughout theentireprotocolexecution.Fromparticipatingin thebar-
tering protocol, a party merely learns its local view consisting of its direct trade
partnersandthequantitiesofthecommoditiestobesentandreceived.Ourpro-
tocolisable toincorporate anyselection strategyforselectingthe tradepartner
constellation as long as the strategy is a function of the considered trade part-
nerconstellations.Examplesforaselectionstrategyonemaychooseincludethe
maximization of the number of parties able to trade, the minimization of the
length of the trade cycles in the actual trade, as well as a combination of both.
Furthermore,ourprotocolincludesaprivacy-preservingmechanismtoreplacea
manual negotiation of the final exchange rates. This mechanism is implemented
by sampling the actual quantities out of private intervals where the boundaries
of such an interval are determined from the negotiation ranges specified by the
involved parties. Our privacy-preserving bartering protocol allows the sampling
of the quantities according to an arbitrary discrete distribution. Note that for
thecasethatthenegotiationofthequantitiesislefttotheparties,apartywhich,
e.g.,hastomakethefirstofferorwhichhastheleastbargainingexperiencemay
be discriminated. Our approach motivates the parties to honestly specify their
negotiation ranges.
Privacy-Preserving Multi-Party Bartering Secure Against Active Adversaries 3
Contributions:Buildingon[21,22],weproposethefirstprivacy-preservingmulti-
party bartering protocol which provides security against malicious adversaries.
Due to the special purpose design of the bartering protocol presented in [21,
22], a straight-forward transformation to the malicious model is not possible.
Instead, new design approaches, e.g., for restricting a party’s local view and for
theintegrationofanegotiationmechanism,arerequired.Atthecoreofourbar-
tering protocol are two novel building blocks which also provide security in the
malicious model. First, we introduce a privacy-preserving building block imple-
menting the conditional random selection (CRS) functionality which has been
introducedin[20].CRSallowstoobliviouslyselectonerandomdataentrywhich
satisfiesaspecifiedconditionoutofaprivatesetofdataentriesandcanbeused
in the context of bartering for determining an actual trade [21,22]. Second, we
introduce a building block for randomly sampling elements out of a private in-
terval (given by encrypted interval boundaries only) w.r.t. an arbitrary discrete
distribution. In the context of bartering, we use this protocol to have a flexible
means for determining trade rates. These novel building blocks are of general
interest beyond the context of bartering. While the complexity of the protocol
from [21,22] linearly depends on the cardinality of the commodity space, our
novel design approach results in a protocol with complexity independent of the
number of supported commodities.3
Outline: The remainder of this paper is organized as follows. After reviewing
related work in Section 2, we provide an overview on designing SMPC proto-
cols for the malicious model (Section 3). Subsequently, we devise an intuitive
terminology for multi-party bartering based on graphs and provide an intuition
for the functionalities of our novel protocol (Section 4). In Section 5, we review
existing building blocks used in the context of our work and present two novel
building blocks for conditional random selection and for random sampling from
a private interval according to an arbitrary discrete distribution. Building on
that, we introduce our novel privacy-preserving bartering protocol (Section 6).
The paper closes with some remarks on future work.
2 Related Work
Ourworkmodelsbarteringinthesamewayastheprivacy-preservingmulti-party
barteringprotocolwhichissecureagainstsemi-honestadversariesintroducedby
Wu¨ller et al. [21,22]. For a given set of parties and their quotes, the bartering
protocol allows to securely determine an actual trade comprising the trade con-
stellation of the parties as well as the commodities and quantities to be traded.
Ourworkpresentedinthispaperextendstheirsettinginthatweprovidesecurity
againstmaliciousadversaries.Thisrequiresthedesignofanewbarteringproto-
col composed of new building blocks which are of general interest. While in [21,
22]onlyabasicleveloffairnessw.r.t.theselectionofthequantitiestobetraded
3 Notethatthenoveldesignapproachcanalsobeappliedto[21,22]inordertoimprove
the efficiency.
4 Stefan Wu¨ller, Ulrike Meyer, and Susanne Wetzel
is considered, in this paper, we extend the notion of fairness by providing an
opportunity to reduce the probability of imbalanced determined quantities (for
details see Section 6). Note that the extended notation of fairness can directly
be applied to the two-party bartering protocol presented in [23].
To the best of our knowledge, to date there are no other privacy-preserving
bartering approaches for more than two parties which provide security against
malicious adversaries. For the two-party case, a privacy-preserving bartering
protocolhasbeenintroducedin[23].However,privacy-preservingbarteringpro-
tocols for the two-party case cannot be used for the much more complicated
bartering setting with more than two parties. This is due to the fact that these
protocols are not capable of determining trade cycles between more than two
parties [21].
Asdetailedin[12],barteringtransactionsofferaricherstructureofexchanges
compared to transaction in the context of e-commerce (and auctions). Conse-
quently, privacy-preserving protocols for e-commerce scenarios or auctions can
notbedirectlyappliedforimplementingaprivacy-preservingbarteringprotocol.
3 Preliminaries
In the following, we first recap general notation, the Paillier cryptosystem, as
well as the definition of security we use throughout the paper. Then, we provide
a brief overview of the SMPC framework from [3,4] which we utilize to design
protocols secure against malicious adversaries.
3.1 Notation and Definitions
To indicate that a is drawn uniformly at random from A, we write a $ A. Nu
←
refers to the set of natural numbers less than or equal to u N. L[i] refers to
∈
entry li of vector L = (l1,...,ln) with i Nn. For some predicate B, let [B]
∈
denote the Iverson bracket where [B] = 1 if B is true and otherwise [B] = 0.
Given an integer interval [λ,µ] with λ,µ N, the width of an interval, written
∈
[λ,µ] isdefinedasµ λ.WedenotetheindexsetofallpartiesP1,...,Pι(ι N)
| | − ∈
participating in a multi-party protocol as P := 1,...,ι .
{ }
3.2 Paillier Threshold Cryptosystem
The Paillier cryptosystem [14] is an additively homomorphic encryption scheme
which provides for semantic security. In order to design privacy-preserving pro-
tocols, we use the (τ,ι) threshold variant of Paillier introduced in [7] where the
privatedecryptionkeyisdistributedamongstιpartiessuchthatτ parties(τ ι)
≤
have to cooperate in order to decrypt a ciphertext. In the following, we outline
the key generation and the encryption function of this threshold variant of the
Paillier cryptosystem.
Privacy-Preserving Multi-Party Bartering Secure Against Active Adversaries 5
Key Generation: For a given security parameter s, choose two primes p and q of
bit length s/2 such that there exist two primes p and q with p = 2p +1 and
(cid:48) (cid:48) (cid:48)
q =2q(cid:48)+1andcomputeN :=p·q.SetN(cid:48) :=p(cid:48)q(cid:48),β ←$ Z∗N,(a,b)←$ Z∗N×Z∗N,
and g :=(1+N)a bN mod N2. The private key βN is shared among ι parties
(cid:48)
·
using Shamir’s (τ,ι) secret sharing scheme [16]. The public key is the same for
all ι parties and consists of g, N, and Θ := L(gN(cid:48)β) = aN β mod N, where
(cid:48)
L(x):=(x 1)/N.
−
Encryption: A message m in plaintext space P := ZN is computed by select-
ing r ←$ Z∗N and computing c = E(m) := gmrN mod N2 where the resulting
ciphertext c is an element of the ciphertext space C:=Z∗N2.
For matters of convenience, we omit the public and private key from our
notation.Pformsanadditivegroup(ZN,+)andCformsamultiplicativegroup
(Z∗N2,·). Let m,m1,m2 ∈P and a∈Z\{0}. Then, the ((τ,ι) threshold) Paillier
cryptosystem provides for homomorphic addition
E(m )+ E(m ):=E(m ) E(m )
1 h 2 1 2
·
such that D(E(m ) E(m ))=D(E(m +m )) and homomorphic scalar multi-
1 2 1 2
·
plication
E(m) a:=(E(m))a
h
×
such that D((E(m))a) = D(E(a m)). We define E(m) 0 := E(0) and
h
· ×
E(m ) E(m ):=E(m )+ (E(m )) 1 suchthatD(E(m )+ (E(m )) 1)=
1 h 2 1 h 2 − 1 h 2 −
−
D(E(m m )). A ciphertext c can be randomized by computing Rnd(c) :=
1 2
−
c+ E(0) where E(0) is a fresh encryption of 0. Given two ciphertexts E(m ),
h 1
E(m2) and knowing the upper bound for the number d N of decimal places of
∈
m with (m 10d+m )<N, we define the homomorphic concatenation of two
2 1 2
·
ciphertexts as
E(m ) E(m ):=E(m ) 10d+ E(m ).
1 h 2 1 h h 2
|| ×
In the following, we write m :=E(m) in order to refer to an encryption of
a plaintext m.
(cid:74) (cid:75)
3.3 Secure Multi-Party Computation
Secure multi-party computation allows a set of ι parties to compute an ι-input
functionality such that each participating party learns nothing beyond its
F
prescribed output and what can be deduced from it in combination with its
private input. The security (i.e., privacy and correctness) of the computation is
guaranteedeveninthepresenceofanadversarycontrollingafixedsetofparties.
Let x := (x ,...,x ) and let : ( 0,1 )ι ( 0,1 )ι,x ( (x),...,
1 ι ∗ ∗ 1
F { } → { } (cid:55)→ F
(x)) be an ι-input functionality where P (v P) provides its private input
ι v
F ∈
x 0,1 and obtains its prescribed (private) output (x). Let π be an ι-
v ∗ v
∈ { } F
partyprotocolimplementingfunctionality .WewriteI = i ,...,i P for
C 1 t
F { }⊂
6 Stefan Wu¨ller, Ulrike Meyer, and Susanne Wetzel
theindexsetoft<ιcorruptedpartiescontrolledbytheadversary.Weconsider
a malicious adversary which may instruct the corrupted parties to arbitrarily
deviate from the protocol specification.
In the SMPC model from [2], security is stated in terms of the ideal world
vs.therealworldparadigm.ThecapabilitiesofanadversaryAinthereal world
execution of π are compared to the capabilities of an adversary S interacting
in the ideal world where the parties have access to a trusted third party which
computesthetargetfunctionality andprovideseachpartywithitsprescribed
F
output. Consequently, the computation of in the ideal world achieves the
F
highest level of security. In the real world, the parties do not have access to
a trusted third party but have to execute protocol π in order to obtain their
respective outputs. In the following, the ideal world (resp., real world) view of a
party refers to the information (e.g., the received messages) it learns during the
computation of (resp., execution of π).
F
The random variable IDEAL (x,I ,k,a) denotes the ι+1 tuple which
,S C
includes the output of all ι partieFs and the output of the adversary S for input
x, the index set of corrupted parties I , security parameter k, and auxiliary
C
input a 0,1 . Functionality is computed in the ideal world under the
∗
∈ { } F
attack of adversary S. Analogously, the random variable REAL (x,I ,k,a)
π,A C
denotes the ι+1 tuple which is comprised of the outputs where π is executed in
the real world under the attack of adversary A.
Definition 1. (Security in the Malicious Model.) Let π be a ι-party protocol
implementing the ι-party functionality . Protocol π securely implements in
F F
the malicious model iff for any static real world adversary A which corrupts a
subset I of t parties there exists an ideal world adversary S such that
C
c
IDEAL := IDEAL (x,I ,k,a)
F,S { F,S C }x,IC,k,a ≡
REAL (x,I ,k,a) =:REAL
{ π,A C }x,IC,k,a π,A
c
where denotes computational indistinguishability.
≡
3.4 CDN Framework for Secure Computations
Our novel privacy-preserving bartering protocol is designed on top of the CDN
framework [4,3] which allows ι parties to securely compute a protocol π (imple-
menting functionality ) in the presence of a malicious adversary who controls
F
at most a minority of τ < ι/2 corrupted parties. Security is defined accord-
ing to Definition 1 with the restriction that I < ι/2 . Furthermore, each
C
| | (cid:100) (cid:101)
party is allowed to additionally receive a public input and output. Assuming
an honest majority guarantees the termination of a protocol execution with the
correctcomputationresult.TheCDN-frameworkassumesathresholdhomomor-
phic cryptosystem satisfying a set of specific properties. The threshold variant
of the Paillier cryptosystem presented in Section 3.2 satisfies these properties
and will be used in the remainder of the paper. In order to prevent a corrupted
party from cheating, each party has to prove (by the means of zero knowledge
Privacy-Preserving Multi-Party Bartering Secure Against Active Adversaries 7
proofs) that it follows the protocol. Once a party is found to deviate from the
protocol specification it is excluded from the further execution of the protocol.
For the sake of brevity, we will not explicitly address this case in the following
sections.
At the core of the CDN framework there is a universal protocol FuncEval
F
which expects the description of an arithmetic circuit implementing functional-
ity . The circuit has to be composed of some basic gates (see below). A gate ρ
F
isakindofblackboxprotocolcharacterizedbythefactthatitobtainsencrypted
input, specifies how to compute some gate functionality on that input, and
G
returns the encrypted result of the computation.
Loosely speaking, the evaluation of protocol FuncEval can be divided into
F
the following three phases [23]:
Input Phase: All parties encrypt their private inputs and broadcast the cor-
responding ciphertext(s). Additionally, for each broadcasted ciphertext a party
proves in zero knowledge that it knows the corresponding plaintext.
Computation Phase: All parties jointly evaluate the given circuit gate by gate.
Each gate obtains an encrypted input and provides an encrypted output which
in turn may constitute the input for another gate.
Output Phase: All parties who are still participating in the protocol jointly ex-
ecute a private decryption protocol providing each party with its prescribed
output.
We write ( o ) ( x ) (resp., ( o ) ρ( x )) to indicate that all parties
← G ←
have common encrypted input x and common encrypted output o .
One of the basic gates proposed in [3,4] is a multiplication gate ( a b )
(cid:74) (cid:75) (cid:74) (cid:75) (cid:74) (cid:75) (cid:74) (cid:75)
· ←
ρ (( a , b )) allowing to multiply two common ciphertexts a and b of
Mult (cid:74) (cid:75) (cid:74) (cid:75)
plaintexts a,b P such that each party obtains the result a b . Th(cid:74)e br(cid:75)oad-
∈ ·
cast complexity of ρ is in O(ιs) for security parameter s while the round
(cid:74) (cid:75) (cid:74) (cid:75) Mult (cid:74) (cid:75) (cid:74) (cid:75)
complexity is in O(1).
(cid:74) (cid:75)
Theorem 1. (cf.[4].) The FuncEval protocol securely evaluates in the pres-
ence of a malicious adversary controlFling a minority of parties. F
Generalizations: In the literature, several generalizations have been proposed
for the CDN framework: Although the original version of the CDN framework
requiresthat isadeterministicfunctionalityandassumesanhonestmajority,
F
Theorem 1 is still valid for computing probabilistic functionalities and allowing
allbutonepartiesbeingcontrolledbyanadversary[3,15,5].Intheformercase,
it has to be assured that the random bits influencing the protocol output are
jointly computed and remain encrypted throughout the protocol execution. In
case an adversary controls a majority of parties, protocol termination can not
be guaranteed.
Furthermore, there exists a sophisticated technique to integrate new gates
intotheCDNframework.Strictlyspeaking,theintegrationofanewgaterequires
8 Stefan Wu¨ller, Ulrike Meyer, and Susanne Wetzel
onetoprovethatthesimulatedviewofallpartiesisstatisticallyindistinguishable
from the real world view of all parties (given the encrypted input and output).
However, Schoenmakers et al. argue that it suffices to show that a gate can
be simulated in a statistically indistinguishable manner for inputs of a special
form[15,8,10].ThistechniqueexploitsthemodularityoftheproofofTheorem1
in [3] which is centered around an intermediary distribution YADb which is a
function of an encrypted bit b. More precisely, the proof shows that
IDEAL p YAD0 c YAD1 s REAL ,
,S π,A
F ≡ ≡ ≡
p s
where and refertoperfectandstatisticalindistinguishability,respectively.A
≡ ≡
distinguisherfordistributionsIDEAL andREAL yieldsadistinguisherfor
,S π,A
distributionsYAD0 andYAD1.SinceFthegapbetweenYAD0 andYAD1 depends
onthesingleencryptedbitb,thesecurityofaprotocolisreducedtothesecurity
of the underlying cryptosystem. Consequently, a gate obtaining input x can
be simulated for input x˜ = (1 b)x 0 +bx 1 where x 0 and x 1 represent
(cid:104) (cid:105) (cid:104) (cid:105) (cid:104) (cid:105) (cid:104) (cid:105)
x in the YAD0 and YAD1 distrib−utions, respectively. Note that the simulator is
(cid:74) (cid:75)
provided with x 0 , x 1 , and b . More details on this proof technique are given
(cid:104) (cid:105) (cid:104) (cid:105)(cid:74) (cid:75) (cid:74) (cid:75)
in [15,8,10].
(cid:74) (cid:75)
4 Overview
4.1 Bartering Terminology
For a set of parties, a trade generically indicates which party receives (or sends)
which quantity of which commodity from (or to) which other party. We allow
each party to specify one offered and one desired commodity and focus on so-
called(1:1)trades whereeachpartyeitherreceivesandsendsnothingorreceives
somequantityofitsdesiredcommodityfromatexactlyonepartyandsendssome
quantity of its offered commodity to one party.
More specifically, we consider a set of ι parties Pv : v P with P := Nι
{ ∈ }
andapubliclyknownfinitesetC := c1,...,cC ofdivisiblecommodities.Each
{ | |}
party P specifies exactly one quote q(v) :=(o(v),d(v)) where o(v) and d(v) are
v
P ’soffer anddemand,respectively.Wemodelo(v)asa2-tupleo(v) :=(c(v),q(v))
v o o
where c(ov) C specifies the commodity offered by Pv and q(ov) N 0 denotes
∈ ∈ \{ }
the maximum quantity at which c(v) is offered. Similarly, we model d(v) :=
o
(c(dv),q(dv)) with c(dv) ∈ C referring to Pv’s desired commodity and q(dv) ∈ N\{0}
indicating the minimum quantity at which this commodity is desired by P .
v
With q(v) a party P indicates that it is satisfied with a trade if it receives
v
at least q(v) units of commodity c(v) and sends at most q(v) units of c(v). The
d d o o
quantity ranges oftheofferedanddesiredcommoditiesofapartyP aredefined
v
as Q(v) :=[1,q(v)] and Q(v) :=[q(v), ]. We write q(v,v(cid:48)) in order to indicate at
o o d d ∞ c(ov)
which quantity Pv(cid:48) will receive commodity c(ov) from Pv (v,v(cid:48) P, v =v(cid:48)).
∈ (cid:54)
Privacy-Preserving Multi-Party Bartering Secure Against Active Adversaries 9
GC Compatibility Graph Def. 2
GTPC Trade Partner Constellation Graph Def. 3
GPTPC Potential Trade Partner Constellation GraphDef. 4
GAT Actual Trade Graph Def. 6
Table 1: Summary of the main bartering terms.
To allow for an intuitive visualization, all further bartering terminology is
defined in terms of graph theory. Figure 1 provides an example and shows how
the terms build on each other.
For the set of quotes of all parties Q := q(1),...,q(ι) a directed graph,
{ }
referred to as compatibility graph GC, can be constructed where each node is
identified with a party index in P. A directed edge (v,v ) between two nodes v
(cid:48)
and v indicates that condition (c(v) =c(v(cid:48))) (q(v) q(v(cid:48))) is satisfied, i.e., that
(cid:48) o d ∧ o ≥ d
Pv can satisfy the demand of Pv(cid:48). Formally, a compatibility graph is defined as
follows:
Definition 2. (Compatibility Graph.) For a given set of quotes Q= q(1),...,
{
q(ι)} with q(v) = ((c(ov),q(ov)),(c(dv),q(dv))) with v ∈ P, a compatibility graph
GC is a simple directed graph (V,E) with V := 1,...,ι and (v,v ) E iff
(cid:48)
[(c(ov) =c(dv(cid:48)))∧(q(ov) ≥q(dv(cid:48)))]=1 where v,v(cid:48) ∈P,{v (cid:54)=v(cid:48). } ∈
Let deg+(v) (v V) refer to the indegree of node v (resp., let deg (v) refer
−
∈
to the outdegree of node v) and let deg(v):=deg+(v)+deg (v).
−
Similarlyasforacompatibilitygraph,thenodesofatrade partner constella-
tiongraph GTPC areidentifiedwiththe(same)partyindicesinP.However,the
edges of a trade partner constellation graph are generic as well as independent
ofanysetofquotesQandforeachnodev itholdsthatiteitherhasexactlyone
incoming and one outgoing edge (i.e., deg+(v) = deg (v) = 1) or otherwise it
−
is isolated (i.e., deg(v)=0). Put differently, a trade partner constellation graph
eitherindicatesthatapartyP doesnotactivelyparticipateintheencodedcon-
v
stellation or specifies P ’s trade partners. In the latter case, GTPC determines
v
exactly one party from which P receives some quantity of a commodity (P ’s
v v
offerer) as well as exactly one party to which P has to send some quantity of
v
a commodity (P ’s demander). The definition of a trade partner constellation
v
graph ensures that each party which sends some quantity of a commodity in
turn receives some quantity of another commodity.
Definition 3. (Trade Partner Constellation Graph.) A trade partner constel-
lation graph GTPC is a simple directed graph (V,E) with V := 1,...,ι and
{ }
v V : (deg (v)=1 deg+(v)=1) (deg(v)=0).
−
∀ ∈ ∧ ∨
Anm-cycleinacompatibilitygraphorinatradepartnerconstellationgraph
isreferredtoasanm-trade cycle.Toensurethatcommoditiescanbetradedac-
cordingtothedirectionoftheedgesinatradepartnerconstellationgraph,ithas
10 No Author Given
Gate 3. ⇢!� for randomly sampling from a private interval according to
RIE-
distribution D (l P).
D 2
Input: P holds � , µ , ! , ,...,
Output:lP outputs e � R0 R!� Title Suppressed Due to Excessive Length 9
l
1 � := µ h �J K J K J K J K
2 For i8fromN0�otAout!ho�r:GivJenK
J22..12K vwiiJ K ⇢⇢iRnSBtwJVitGcKh((|Rrii,|1) ,..., ri,|Ri|�1 , vi ) Privacy-GPrTePsCerving Multi-Party Bartering Secure Against Active Adversaries 29
3 e� J K⇢Switch( w0 ,..., ew01!:�=,e1�⇥)hW('1)= 0
4 e :=J eK� + � J K J ... K J K Misc Title Suppressed Due to Excessive Length 9
J K J K J K
J K J K J K J K
J K J K J K e0i :=... GTPC
. 1
.
.
J K
e0j :=... GTPC
.
J K.. GT1PC 2 1 2 1 2
e0TPCS := 2
| |
8 NoAuthorGiven
MappingPhase:(...)
J K GTPC
1
0123i PPPPf(rrrrk[[[[;xxxxi====)0001(]]]]8====k21PPPrrr[0[[[xxx,i===])123]]]===111///248;;PPrr[[xx==11]]LJ==L⌘11PK=/=r2([x(T=JT...P2PT]T1=(⌘1()13),/K.,8.).)RRRRR3i0123 ====2((((0000),,,111,,)11G,,21,)T22,P2J,Ce2N01,K3:=)oJe1eKA0i⇥h:....=uW..(.t'1h)=oGGJ0rKT3T4PPGCC iven 3 4 3 4 3
4 PPrr[[xx==21]]==S3Pe/lre8[cxti=on4]P=ha1s/e1:6..;.Prert[uxr=nJ1s](=Kc⇤0P,r.J[.x.=, 3c]⇤⌘=)K=1/(4); 3R,43,=4)(0,1,1,1,1,2,2,2,2,2J,2K,..3,3, 4
OutputPhase:...decrypt...suchthatPllearnsc⇤l =TPTi(l)whereTPTi(1)= e0j :=... (1,2)
8 NoA(4u,t3h)o,rTGPivTeTanib(2l)e=2:(3C,o48n),stTrPucTNtii(oo3)nA=Juotfh(Ko1Rr,2iG)if,voeTJrnPDKT=i(4)B=a(n2d,1!),�T=PT4i(5()iG=2T(N00!P,�0C)).. J K... 1 2 qA 1 2
3 e0TPCS := GPTPC 1 2
Misc | | 1 (2,3)
MappingPhase:(...) q
J K
e01 := e1 ⇥hW('1)= 0 e01 := eG1 ⇥hAWT('1)= 0 B
1 J K J 2K ... J K J 1K J K ... 2 GT4J KPC L1 =(1TPT1(1) ,) G2 PTPC
10 StJee0ifKan:...=W...u¨ller, Ulrike Meyer,Jae0inKd:...=S.u..sanne WetzeLJl⌘ K=( TJ...PT1(⌘) ,K...) 24TitleSuppressedDueto3ExcessiveLength 9 4 qC(3,1) 3 4 3
41 PP1eJ0|e32T0jPqKC...:(=S1|Q)..:=.=( (Ao,↵1e0r),41(4,d3OSq)(ee,uA(Clem1eJiTt0|,eTpc,2P0jtauP)5iKnotTC2)...:niP=Sd(2|h32P).a.h=:.s=ae{)s(:e3.G:.,1.4.d.).P1e,,rcGGTeTrtyTT1P.upPPPT.rtCCniJ(C..s3..),(s=JKuc4c⇤0(hK1,,t}.J2h41.)a.,t,PTJPGcrPl⇤⌘ivlKTae)CciaK(y=4r)-nP(s=r)ceG32⇤ls(e2=r,Pv1TiT)nTi,tgPlTePMTPSiCu(ulTl)pti(iwp-5Pr)hea=esrsrteey(d0TB,DPa0ur)Tte.ei(rt1io)ngE=xcessi2v9eLength 9
MappingPhase:(..4.) LPPP1J234=3M(qqqaTp(((234pP)))iKnT===g1(1P)(((h,a)se((:(CBC(.,.,,.1)840))),,,MLqi3C(1s2(((3JcB,AA1=)q,,,B((6432,T))N)3)PoKTA1u(1t))))hGo,r)TG1GGiP2tilTGT1veTTePPT2SniCCtPPulCpeCpSruespspe2drGeDsTs4ueTedittPDolueCEextScoesuEsivxpG3ecpeLsAesrnivTege1tsPhLseCengdthD9 u2e9to Excessive1 Length2 9
1 2 Privacy-PreOSseeulretvpcintuig1otnMPhPualhtsiae-sP:e.a:.r..td.y.er2Bceratyruptre1tnrJ.isL.nJ.1g⌘(sGKucKTc=⇤0GhP,T(COSt.JPhe2.TuCJlaG9.et...Pt,pc2PtTucTil1ot⇤⌘(⌘n2lPPe))aKhP=,C1rKaPh.ns.GGra(sei.)s:v)cPTT1eGGa.⇤lPrP:.c.iTT1=CCvy.d.PPa-.ePcCTCrcyrerP-etyPsuTper2rriet(4nvslJ.)eisL.nJr.w⌘(vg1sGih3KiTuTncM22eKAc=i⇤0gi1rthtTuGle{lM,ele(t1t.TJhiSu,S.T-JPa.uPul.N14.t...Pt,pp.TiaiTo,-ppPrTP4ic3(Atrrl11}⇤⌘yae(eu)⌘Pslrsets2B)t)s=heyaKeado=,rd1KCr2rBG.ntD.DG(ase.u)rr4)iucGGPtive⇤lneee23GGT2T3trgnvT=toiPPnoT3T4ECCgPTPPExCCPxcCecTs2eG2si9s(islv2)iev93weLGCheLneegrnT1et1ghTtP1hPCTi(1149)=9G2A12T4qc⇤23(o(11),2) 2 3 14 4 23 3
14 4 23 3 (M4,i3s)c,T14Pqc⇤4T(o141(qq4i4()cc⇤⇤,2(o(o1(()q1313)))c⇤=,,(o24(22)))(,33),234),3232T14PT144i(3)4GGGGG=J(MT1T2T3T4P14GGGGG(,TKPPPP1i3T1T2T3T4P1CCCCP,s)TPPPP232Cc,CCCCP)GGGT,C233TJPT1T2T3FPT141i3KiTPPP(g2i.()4CCC41411=):GGGGG=(ET2T3T4P1P2GGGGG3q(TTPPP,x2A(T2T3T4P1P4CCCPP1a,TT)PPP,CC12m,CCCPP))232T,CCpTPleP2323T14iTf(3oqi()r5c⇤144G◆=)(oJ(GiG◆qq4qb4=)2ccTi⇤⇤ATi,c⇤(a4(o(o1(((oqTPKP(13◆qq1134{)r4())cCC⇤),cc,,1⇤⇤0,t(o24((o(o12((,2q,e132))v13v).))))c0,⇤.r14,,,3.(o24()i,G2)G2))Tn.J4)23,C}3gCP)K23Tt3ie(41414r3GG)m=s141GGGGGAAq(a232PGGGGGT4P1P2AA(TT1,TTTTnPPP1P2AA,12PPCPPdTTTPTT))CCCC,PPPPtCTCCCChP2323eiTri(2325rmGGGs)qeweaa=ul⟶elcaexalT2T3Ttf4cint(muat0itariioPPPoie,4tzly n0,ne CCC) s..14 qC(q33A(,111414)q,32B(q)2c⇤,(o3(q44))c⇤,23(o1(q33))c⇤,(o4(22)),3)2323 14 23
GPTPC GPT2PqCB(2,3) qB(2,3) 4
GPT2PC
4 3tewoxhebicceuhtaaGssbosP2GlmuTePPr)TeCe.PGdmCWtaT4hhy4aPilnteC4othtGaqeAbCG(c3Tet,oPP1rT)mCsaPid3mpCeaut3cliytbacinlleietsoyaurgselryadpeishxjeomci4nuattyqa(4GC(ba3cA,ll1oTes)no(terae.igfn3e.,rmrG3eGuCdlttPiinopTlaFesPigtsCuriamrdeue1ltcac4ynocneloteausisnolysf 3
GATPC 1
one 2-traGdAeTPcCycle anGdATone 3-trade cycle but only one of them is executable at a
timebGecAaTuPCseP isinvolvedinbothcycles),apotentialtradeconstellationgraph
1
correspoGnAdTsGtoP1aTsPuCbgGrAaTph of either one trade cycle or multiple simultaneously
executGabATle trade cycles (e.g., GP1TPC and GP2TPC in FigurGe 1P).TPC
2
Definition 4. (PotentialTradePartnerConstellationGraph.)Foragivensetof
quotes Q, aGtraPdTePpaCrtner constellation graph GTPC is referred to as a potential
trade partner c2onstellation graph GPTPC iff GTPC is a subgraph of GC, written
PTPC
GTPC GC. G
(cid:118)
We writGe GPTTPPCC:= {GT1PC,...,GTGPTCPC } for a set of trade partner constel-
lation graphs. For a given GTPC an|d GC|, the set of potential trade partner
constellation graphs is denoted as GPTPC. According toGDAefiTnPitiCon 4, it holds
that GPTPC GTPC (cf. Figure 1).
⊆
GATPC
Definition 5. (Welfare Function.) A welfare function ():GTPC N 0
W · → ∪{ }
maps a trade partner constellation graph in GTPC to a welfare.
GAT