ateniese et al. - 2014 - fault-tolerant oblivious assignment with m slots in synchronous systems

8/16/2019 Ateniese Et Al. - 2014 - Fault-Tolerant Oblivious Assignment With m Slots in Synchronous Systems

1/14

J. Parallel Distrib. Comput. 74 (2014) 2648–2661

Contents lists available at ScienceDirect

J. Parallel Distrib. Comput.

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

Fault-tolerant oblivious assignment with m slots insynchronous systems

Giuseppe Ateniese, Roberto Baldoni, Silvia Bonomi ∗, Giuseppe Antonio Di LunaResearch Center of Cyber Intelligence and Information Security, Universitá degli Studi di Roma La Sapienza, Via Ariosto, 25, I-00185 Roma, Italy

h i g h l i g h t s

• We defined the SOmA problem in a failure-prone environment.• We provided an algorithm solving the SOmA problem with up to f failures.• We provided correctness proofs.• We provided an analysis of the average latency to get a slot.

a r t i c l e i n f o

Article history:

Received 5 April 2013Received in revised form

24 January 2014

Accepted 25 February 2014

Available online 17 March 2014

Keywords:

Distributed coordination abstractions

Secure computationsMutual exclusion

Distributed systems

Failures

a b s t r a c t

Preserving anonymity and privacy of customer actions withina complex software system, such as a cloudcomputing system, is one of the main issues that should be addressed to boost private computationoutsourcing. In this paper, we propose a coordination paradigm, namely oblivious assignment with mslots of a resource R (with m ≥ 1), allowing processes to compete in order to get a slot of R, whileensuring at the same time both fairness in the assignment of resource slots and that no process learnswhich slot of R is assigned to a specific process. We present a distributed algorithm solving obliviousassignment with m slots within a distributed system, assuming (1) a bounded number of crash failures f ,(2) the existence of at least f + 2 honest processes, and (3) m ≤ n (where n is the number of processes).

Thealgorithm is based on a rotating token paradigm andits correctnessis formallyproved. A probabilisticanalysis of the average waiting time before getting a slot is also provided.

© 2014 Elsevier Inc. All rights reserved.

1. Introduction

In this paper, we investigate the problem of oblivious assign-ment with m slots. Informally, we consider n non-anonymous pro-cesses competing for accessing one of the m slots of a resource R.Each slot can be assigned to at most one process at a time. Whena resource is not needed anymore, it is released and assigned to

another requesting process. Note that, processes are utterly iden-tifiable but we strive to protect the allocations of resource slots toprocesses. Thus, processes are oblivious and in particular they are un-aware of assignments between processes and resource slots.

This problem is particularly interesting because it crystallizesthe difficulty in coordinating processes that wish to interactwith a resource without being noticed by anyone else. Resource

∗ Corresponding author.E-mail addresses: [email protected] (G. Ateniese),

[email protected] (R. Baldoni), [email protected] (S. Bonomi),

[email protected] (G.A. Di Luna).

sharing environments and channel assignments in telco systemsare examples of domains where this problem can be relevant. Asan example, an oblivious assignment scheme can help a groupof clients of a cloud provider to hide and protect their allocationof resources within a virtualized environment or across distinctdomains. Resources canthus be obliviously allocatedto clients. Noteven the cloud provider is aware of these various assignments.

As one of the major obstacles to the growth of cloud computingconcerns the level of privacy that can be guaranteed when storingand processing the data in the cloud [1,14], oblivious assignmentscan be thus considered a basic coordination paradigm to beemployed in such untrusted environment.

We target organizations moving to the cloud, or outsourcingtheir services, that wish to access or allocate virtual resourcesanonymously. Cryptographic systems, such as fully homomorphicencryption [10], do not solve the oblivious assignment problem.Homomorphic encryption allows clients to perform computationover encrypted data ensuring that sensitive information remainsinaccessible to the cloud provider. However, the provider can de-rive which resourcesare allocatedto which clients. This constitutes

http://dx.doi.org/10.1016/j.jpdc.2014.02.008

0743-7315/© 2014 Elsevier Inc. All rights reserved.

http://dx.doi.org/10.1016/j.jpdc.2014.02.008http://www.elsevier.com/locate/jpdchttp://www.elsevier.com/locate/jpdcmailto:[email protected]:[email protected]:[email protected]:[email protected]://dx.doi.org/10.1016/j.jpdc.2014.02.008http://dx.doi.org/10.1016/j.jpdc.2014.02.008mailto:[email protected]:[email protected]:[email protected]:[email protected]://crossmark.crossref.org/dialog/?doi=10.1016/j.jpdc.2014.02.008&domain=pdfhttp://www.elsevier.com/locate/jpdchttp://www.elsevier.com/locate/jpdchttp://dx.doi.org/10.1016/j.jpdc.2014.02.008


2/14

G. Ateniese et al. / J. Parallel Distrib. Comput. 74 (2014) 2648–2661 2649

a side-channel leak we aspire to prevent. We stress that this typeof side-channel has not been considered before in the context of cloud computing.

The paper considers the StrongOblivious Assignment with m slots(SO-mA) problem introduced in [2] and addresses it in a crashfailure prone distributed environment. Informally, the SO-mAproblem states that given a process pi, no other process will learnwhether any slot was assigned to pi or not. That is, it is not possibleto infer whether a specific process is using a resource slot ornot. We show that a standard perpetual circulating algorithm issuccessful only in the presence of n − 1 honest processes (where nis the number of processes). Then, we introduce a fault-tolerantrotating token distributed algorithm solving SO-mA where weassume an upper bound f on the number of possible failures, theexistence of at least f + 2 honest processes, and that m ≤ n.The algorithm employs an adaptation of the ElGamal encryptionscheme to ensure obliviousness of the assignment. Finally, thecorrectness of the algorithm is formally proved and a probabilisticanalysis of the average waiting time before getting a slot is alsoprovided.

The rest of the paper is organized as follows: related work is inSection 2 and the system model is defined in Section 3. Section 4

formalizes the strong oblivious assignment with m slots problemand provides some solvability conditions, while Section 5 presentsa distributed fault tolerant algorithm solving the strong obliviousassignment problem and Section 6 proves its correctness. Section 7provides a performance analysis and finally, Section 8 concludesthe paper.

2. Related work

Defining distributed algorithms for accessing resources inmutual exclusion has been a mainstream field of research in theeighties [17] and several efficient algorithms have been devised(e.g., [18,21,15] just to cite a few). To facilitate fault tolerancewithout assuming failure detection, the general mutual exclusion

problem has been extended to the k-mutual exclusion one [16],where at most k different processes can concurrently accessthe same resource; general strategies working in a failure-freeenvironment have been adapted to solve this more generalproblem in an asynchronous message passing system (e.g. [13,7]).

A different generalization of the mutual exclusion problem,namely k-assignment, has been presented in [8]. (In k-assignment,there are k < n resources that may be requested by n processes.)The authors have shown that the problem can be solved in anasynchronous distributed system as long as at most k/2 processescan fail.

Similarly, in the renaming problem [3], each participatingprocess is initially associated to a unique identifier from a largename space and the final objective is to select unique identifiers

from a smaller name space. A more general specification, calledk-assignment with m slots, is defined in [4] by combining togetherrenaming and k-exclusion. Informally, such a problem requiresthat at most k processes access concurrently one of the mdistinct available slots. All these existing algorithms do not maskthe assignment between slots and competing processes. On thecontrary, they exploit their knowledge about assignments tominimize the number of exchanged messages.

Generally, the oblivious assignment problem can be solvedusing secure multi-party computation [22]. This is a paradigmthat allows several parties to evaluate a function f ( x1, . . . , xn), ormultiple functions, without revealing the inputs x1, . . . , xn. Thatis, every party pi contributes xi but at the end of the protocolit will only learn f ( x1, . . . , xn) and nothing else. Unfortunately,

these generic techniques are notoriously very expensive and callfor an exorbitant number of messages to be exchanged. However,

there exist more efficient alternatives for many functionalities.The one that is more closely related to the oblivious assignmentfunctionality is referred to as mental poker . Mental pokeralgorithms [20] allow people to play card games over networkswithout any trusted dealer. The basic idea is to assign cards toplayers such that cards stay private and can be safely shuffled.In addition, it is possible to detect cheaters. While the originalscheme [20] represented each card with a large number of bits,more recent work [5] makes card sizes smaller and independentof the number of players.

The oblivious assignment problem does not fit completelywithin the mental poker framework, however. In our model, wemust avoid starvation andensure liveness andthus allow a processto pick a specific slot of a resource within a fixed amount of time (while this is not possible in mental poker). The release of aresource is also significantly simpler than discarding a card fromhand. Indeed, we do not have to preserve the value of the slot (orcard) and thus we can just set, obliviously, a Boolean flag.

3. System model

The distributed system is composed of a set of n processes Π ={ p1, p2, . . . , pn}, each one having a unique identifier, that competefor m distinct slots {r 1, . . . , r m} of a resource R. Each process picompetes to get exclusive access to a slot of R and it maintains alocal state Si(t ) represented by a snapshot of its local memory attime t .

At any time, each slot can be assigned to at most one processand allocated slots must be released within a finite period of time. Specifically, when process pi needs to acquire one of them slots of R, it invokes a request() operation and waits until agrantResource() event occurs returning the slot r j assigned to pi.To release the slot r j, pi invokes a release() operation. During thecomputation, up to f processes may fail by crashing.

We assume the existence of a coalition C ⊂ Π (with 1 ≤|C| ≤ n − f − 2) of honest-but-curious processes [11]. Such

processes act according to their algorithm but they can at anytime collaborate to acquire and share information about othersprocesses. We denote as coalition state CS(t ), the union of localstates of processes belonging to the coalition C (i.e., CS(t ) =

i∈C Si(t )).Processes not belonging to the coalition C are said to be honest ,

i.e., they behave according to the algorithm, and do not attemptto infer anything more than what can be inferred during theexecution of the algorithm. The set of honest processes is denotedbyH .

Processes coordinate their access to slots of R by exchangingmessages. We assume that for any pair of processes p i, p j ∈ Π ,there exists a reliable FIFO point-to-point communication channelconnecting them. We assume that the underlying communication

system is synchronous and that there exists an upper bound onthe time needed to deliver messages. In addition, we assumethat each process can access a perfect failure detector reportingon failed processes. We observe that a synchronous system isharder to deal with than an asynchronous one with respect toobliviousness. Indeed, the adversary can exploit synchrony toacquire further knowledge, for instance, on the activities of certainhonest processes.

4. Strong oblivious assignment withm slots

Given a generic resource R, it can be used concurrently bydifferent processes; however, any of its m slots can be used in anexclusive way. We remark that every process can always get at

most one slot of R

, thatis, the assignment of multiple slots to a single process is not allowed. At the same time, it must be guaranteed that


3/14

2650 G. Ateniese et al. / J. Parallel Distrib. Comput. 74 (2014) 2648–2661

competing processes will eventually obtain a slot of R. In addition,resource assignment must be kept private. In the following weformalize the problem of Strong Oblivious Assignment introducedin [2] and we adapt it to take into account process failures.

4.1. Preliminary definitions

Before providing the formal specification of the problem, letus introduce the notions of assignment to a set of processes andtentative assignment to honest processes.

Definition 1 ( Assignment at Time t ). Let X be a subset of processesof the distributed system (i.e., X ⊆ Π ) and let Y be a subset of slotsof the resourceR (i.e., Y ⊆ {r 1, r 2, . . . , r m}). An assignment of slotsY to the subset of processes X at time t , denoted as At Y , X , is a setsuch that:

• each element of the set is a pair ⟨ pi, r j⟩ where pi ∈ X is a processidentifier and r j ∈ (Y ∪ {⊥}) is a slot of the resource R;

• for each process pi ∈ X , ∃! a pair ⟨ pi,−⟩ in At Y , X .

As an example, consider a distributed system composed attime t 0 of n = 4 processes, i.e., Π = { p1, p2, p3, p4}, where p2and p4 are honest-but-curious processes (i.e., H = { p1, p3} andC = { p2, p4}). Consider, also, a resource R with the following 3slots R = {r 1, r 2, r 3}. The following set, therefore, represents anassignment at some time t

At R,Π = {⟨ p1, r 3⟩, ⟨ p2, r 1⟩, ⟨ p3,⊥⟩, ⟨ p4,⊥⟩}.

In the rest of the paper, we may need to consider only resourcesallocatedat some time t to a specific subset of processes X . Wewilldenote such a subset of slots with Rt X and define it as follows:

Definition 2. Let At R,Π be an assignment at time t .

Rt X = {r i|(∃⟨ p j, r i⟩ ∈ At R,Π ) ∧ ( p j ∈ X )} \ {⊥}.

When clear from the context, we will use simply R X (withoutthe time t ).

Continuing from our previous example, we could distinguishbetween slots assigned to honest processes and slots assigned tothe coalition. Hence, we get the following sets:

Rt H

= {r 3} Rt C

= {r 1}.

Note that, given an assignment At R,Π , honest-but-curiousprocesses are always able to determine the assignment of thecoalition At RC ,C since they can share their knowledge through, forexample, out-of-band messages. Using this knowledge, honest-but-curious processes can try to guess an assignment for honestprocesses. This guess, namely tentative assignment , is defined asfollows:

Definition 3 (Tentative Assignment at Time t ). Let At R,Π be an

assignment at time t , let Rt C

= (R \ Rt C) be the set of slots of the

resourceR not assigned to processes of the coalition at time t . Let

F t H

= (H \ F H ) the set of non-faulty honest processes at time t .

A tentative assignment at time t of slots Rt C

to non-faulty honest

processesF t H

, denoted asTAt RC ,F H

,isasetofpairs ⟨ pi, r j⟩ such that:

• for each process p j ∈ F t H

, there exists one pair ⟨ p j,−⟩ ∈TAt

RC ,F H

• for each ⟨ p j, r k⟩ ∈ TAt

RC ,F H , r k ∈ (R

t C

∪ {⊥})

• for any ⟨ pi, r i⟩, ⟨ p j, r j⟩ ∈ TAt

RC ,F H , if r i = r j then r i = ⊥ and

r j = ⊥

• there exists at least one pair ⟨ pi, r i⟩ ∈ TAt RC ,F H such that r i ̸ = ⊥.

Definition 4 (Tentative Assignment Set at Time t ). Let At R,Π be an

assignment at time t and let Rt C

be the set of slots of the resourceR

notassignedto processesof thecoalition at time t .LetF t H

the set of non-faulty honest processes at time t . A Tentative Assignment Set attime t , denoted as TASt

RC ,F H , is the set of all the possible tentative

assignments that can be obtained at time t .

Assuming that no failure occurred to an honest process (i.e., ateach time t , F t

H = ∅) and considering the previous scenario,

tentative assignment set TASt RC ,F H

is composed of the tentative

assignment listed in the following:

TASt RC ,F H

=

{⟨ p1, r 3⟩, ⟨ p3, ⊥⟩}{⟨ p1,⊥⟩, ⟨ p3, r 3⟩}

× {⟨ p1, r 2⟩, ⟨ p3,⊥⟩}{⟨ p1,⊥⟩, ⟨ p3, r 2⟩}

× {⟨ p1, r 2⟩, ⟨ p3, r 3⟩}{⟨ p1, r 3⟩, ⟨ p3, r 2⟩}.

4.2. Strong oblivious assignment with m slots (SO-mA) problem

Let At R,Π be an assignment at time t and let Rt C

be the set of slotsof the resourceR not assigned to honest-but-curious processes at

time t and let CS(t ) be the knowledge of the coalition at time t .Let F t

H be the set of honest non-faulty processes at time t and let

TASt RC ,F H

be the tentative assignment set at time t .

At any time t , the following properties have to be satisfied:

1. UniqueAssignment: If pi and p j both access the resource R attime t , then the slot r x assigned to pi at the same time t isdifferent from the slot r y assigned to p j

(i.e., ∀⟨ pi, r i⟩ ∈ At R,Π : r i ̸ = ⊥ then p j : ( p j ̸ = pi)∧(⟨ p j, r j⟩ ∈

At R,Π ) ∧ (r i = r j)).2. LockoutAvoidance: If a honest non-faulty process pi requests

the access to the resource R at time t , then it eventually getsa slot r j of R.

3. StrongObliviousAssignment: For any pairs of tentative assign-ments TA, TA′ ∈ TASt

RC ,F H , the probability that any honest-but-

curious process can distinguish among TA andTA′ is a negligiblefunction w.r.t. some parameter n, i.e.,

Prob( At

RC ,F H = TA)|CS(t )

= Prob( At

RC ,F H = TA′)|CS(t )

± ε(n).

In our previous example, honest-but-curious processes will notbe able to infer which is the actual honest assignment amongthose belonging to the tentative assignment set at time t by justlooking at the coalition assignment At RC ,C = {⟨ p2, r 1⟩, ⟨ p4,⊥⟩}.Indeed, all six assignments have nearly the same probability of being considered.

4.3. Ruling out trivial perpetual circulating token algorithms

Let us consider a trivial token circulating algorithm, dubbedtrivial-A, working as follows: the token owner can access a slot assoon as it receives the token, without sending out any notification.Once the token owner releases the slot, the token is passed to thenext process in the logical ring.

Note that this algorithm satisfies properties 1 and 2.The following lemma shows that this simple algorithm

implements SO-mA only if there is at most one honest-but-curiousprocess.

Lemma 1. Let F t H

be the set of honest non-faulty processes at time t.Consider an algorithm trivial-A running on the top of the distributedsystems described in Section 3 and satisfying properties 1 and 2 . If

|C| > 1 and |F t H

| < 2, trivial-A cannot ensure SO-m A property.


4/14


Proof. Consider the following run where two honest-but-curiousprocesses (namely pi−1 and pi+1) are respectively the predecessorand the successor of an honest process pi in the ring and thecommunication delay is bounded by δ (see Section 3). Let usconsider the time t when pi receives the token sent by pi−1.

The algorithm trivial-Amakes it possible to assign at most oneslot at each time. Thus, at time t , none of the processes in the coali-tion owns a slot (i.e., RC = ∅) and all the resource slots R are avail-able to be selected (i.e., RC = R). As a consequence, the tentativeassignment set TASt

R,F H at time t will include at least all the possi-

ble permutations of |R| slots to honest non-faulty processes. How-ever, exploiting the structure of the algorithm and the knowledgeabout the process having thetoken at time t , processes of the coali-tion may infer that any other honest non-faulty process p j has aunique possible assignment, that is ⟨ p j,⊥⟩. Therefore, all tentativeassignments TA j ∈ TAS

t R,F H

containing a pair ⟨ p j, r j⟩ with r j ̸ = ⊥

have probability 0 to occur while there exist at least |R| tentativeassignments TA′ ∈ TASt

R,F H with probability strictly greater than

0 to occur (i.e., all the tentative assignment where all honest pro-cesses have no assigned slot while pi has one of the R slots). Thisviolates the SO-mA property. Lemma 1

5. A fault-tolerant token-based algorithm for solving SO-m A

In this section, we first provide thegeneral idea of thealgorithmby explaining how it works during nice executions (i.e., runswith no failures) and then we will discuss when failures affectsthe algorithm and how they are handled. Finally, we providethe detailed explanation of the pseudo-code and we prove itscorrectness.

5.1. A rotating token algorithm in nice executions

Our algorithm is token-based and works in rounds. Each roundis led by a coordinator pc that takes care of the token creation,

encoding, and dissemination. The token circulates on the top of alogical ring formed by the processes (i.e., each process p i passesthe token to its neighbor p(i+1) mod n). Each round is characterizedby twophases, allocation phase (corresponding to the managementof request() operations), where resource slots are allocated toprocesses, and release phase, where each process frees its assignedslot once it has done with it. A round ends when all allocatedslots are released. The next round is coordinated by the non-faultyprocess that follows pc in the logical ring. In the following, we willuse the term ticket to indicate a numeric representation of a slot.The coordinator will create n tickets (that is, a ticket per process inthe system) regardless of the number of actual slots.

Allocation phase: The coordinator of the current round creates atoken, request _token, containing a set of tickets {tk1, tk2, . . . , tkn},

each oneidentifyinga resource slot. Only m outof n tickets will uni-vocally be associated to actual slots of the resource (i.e. valid tick-ets) while the remaining n − m tickets (i.e. invalid ticket ) representdummy slots. Invalid tickets help prevent leakage of informationon actual assignments.

At the beginning of each round, the coordinator picks oneticket, encrypts the request _token via ElGamal encryption [9], andforwards thetoken to the next process in thering. Upon the receiptof the token, a process pi picks a ticket, re-encrypts the token tomake it indistinguishable, and forwards it to the next process inthe ring. After getting the ticket, pi will decrypt it by asking otherprocesses for their ephemeral keys: if the ticket is valid and pirequested a slot of R, then it will trigger the grantResource event.

Release phase: Therelease phase startsonly when therequest _token

returns to the coordinator. The coordinator creates a release_token,used to collect released tickets, and starts to circulate it in the

logical ring. A ticketis released by a process pi in twocases: (i) pi didnot request a slot of R or, (ii) pi finished with the slot (i.e., wheninvoking the release() operation). Every time the release_token ispassed to the next process, it is re-encrypted to avoid informationleakage. We implemented an ‘‘implicit’’ release mechanism, i.e., aprocess releasing a ticket does not provide any information aboutthe ticket itself but it just manifests its willing to release it. Thetoken release_token circulates continuously till the coordinator

verifies that all the processes released the slot. At this point, theround is completed and the next process in the ring becomes thenew coordinator for a new round.

5.2. Handling crash failures

In order to guarantee the obliviousness of the assignment inpresence of honest-but-curious processes, each process encryptsand decrypts both the request and the release tokens. As aconsequence, a failure may block the protocol as tickets cannot berevealed.

A naive solution consists in allowing processes to stop and dropthecurrent round as soon as a failure is detected.Then,a newroundcan be started adjusting the size of the token to the new group and

deleting all the information related to faulty processes. However,this naive adaptation has two main drawbacks; first it needs tore-initialize all the data structures and in particular all the keysneeded to encrypt and decrypt tickets, and second all the currentassignments will be lost.

In the following, we will propose a smarter algorithmwhere weintroduce redundancy in the encryption/decryption steps.

Key-based redundancy. We will use the (h, n) secret sharingschemes [19] that is used to divide a key in n shares, such that anysubset of h shares is necessary and sufficient to recover the key.

Each process stores a piece (i.e., share) of any other key main-tained by other processes. When a failure occurs and is detectedby some process pi, the latter will send to all the non-faultyprocesses its piece of the share so that any other non-faulty pro-cess will be able to reconstruct the key of the faulty one and use it

to decrypt tokens.In addition, to preserve the liveness of the protocol, when a

failure is detected, the predecessor of the faulty process must takecorrective actions: (i) it needs to update its next in the ring and(ii) it must forward the last token it saw. Finally, special attentionmust be devoted to the failure of the coordinator. When the failuredetector reveals the failure of the coordinator, a new one must bedeterministically elected. In ourcase, we select the next non-faultyprocess in the logical ring. When a process becomes coordinator,it needs to verify whether the current phase of the algorithm isrequest, release, or idle, and, based on that, create and propagatethe corresponding tokens.

Note that, in order to tolerate f failures still being able tocontinue to decrypt tickets, we must have that the number of

shares h (necessary to reconstruct a faulty key) cannot be greaterthan the number of non-faulty processes (i.e., h ≤ n − f ). On theother hand, the number of shares h cannot be smaller than thesize of the coalition of honest-but-curious processes (i.e., h > |C|)because such processes may collaborate to decrypt any ticket theyprocess, violating any form of obliviousness.

5.3. ElGamal encryption with multiple parties

Notation and assumptions. In the following, we use y ← f ( x) toindicate the assignment to y of the value obtained evaluating a

function f over theinput x, while wewilluse y u←− S to indicate that

y is a randomelement uniformly selected from a set S. We indicatewith Zq the class of residues modulo q. In the following, we will

assume to have a cyclic subgroup G of prime order q and generator g where the Decisional Diffie–Hellman (DDH) assumption [6]


5/14


holds. Informally, the DDH assumption states that given a triple

( g x, g y, g xy) with x, y u←− Zq it can be distinguished from a triple

in the form ( g x, g y, g z ), with z u←− Zq, by using a probabilistic

polynomial time algorithm, with negligible probability.For a concrete instantiation, we consider G to be the set of

quadratic residues of Z∗ p where p is a safe prime, i.e., p = 2q+1withprime q. A generator g of the group G is simply found by selecting

¯ g u←− Z∗ p and setting g = ¯ g 2 mod p whenever ¯ g ̸ = 1.

ElGamal encryption. The idea behind ElGamal scheme is to use g xy

as a shared secret between sender and recipient. The private key is

y u←− Zq while the public key is the value g

y ∈ G.To encrypt an element m ∈ G, it is enough to randomly select

an element r u←− Zq and compute the ciphertext as a pair (c 1, c 2) =

( g r ,mg ry) ∈ G × G. The recipient of the ciphertext (c 1, c 2) recoversm by computing c 2/c

y1 ∈ G.

Note that, under the DDH assumption, ElGamal encryption issemantically secure [6]. Intuitively, a semantically secure schemedoes not leak any information about the encrypted message. Inparticular, given a ciphertext (c 1, c 2) of one of two messages m0and m1, an adversary cannot tell which message was encrypted.

This holds even if the adversary chooses both messages, as long asthey are both in G.

Adaptation. We adapt the ElGamal crypto-system to work with

multiple parties. Each process pi has a private key Pr _keyiu

←−Zq, and the corresponding public key is calculated as g

Pr _keyi . In

addition, pi also maintains the group public key as the value g Y =

g

pi ∈Π Pr _keyi .

We use the ElGamal crypto-system to encrypt tickets whosevalues contain relevant information about slots of the resource R(e.g. such as network address, memory location, and printer ID).Thus, generic numerical tickets must be mapped into elements of the subgroup G of quadratic residues in Z∗ p .

The standard mapping-then-encrypt procedure works as fol-

lows: (i) consider the ticket t as an element of Zq, (ii) set t̄ = t + 1,and (iii) encrypt the value t̄ 2 mod p. The decryption phase is moreinvolved: (i) decrypt and recover the plaintext m̄ = t̄ 2 mod p, (ii)compute a square root of m̄ as m = m̄( p+1)/4 mod p, and return theticket m − 1 if m ≤ q, or p − (m − 1) when m > q. In the rest of the paper we assume that tickets or any arbitrary messages are inG, either directly or through the mapping described above.

A ticket t is encrypted for the group of processes as ( g r , tg rY ).Each process must contribute to the decryption phase in orderto recover the ticket by computing the partial value g rPr _keyi . Theproduct modulo p of these partial values from allprocesses is equalto g rY which is used to recover t as in standard ElGamal. We definea function removeLayer that receives as input a valid ciphertext andremoves the component g rPr _keyi from it, effectively allowing other

processes to decrypt the message. This function is executed locallyby the process pi.

Notice that, ElGamal ciphertexts can easily be randomized,i.e., given a ciphertext (c 1, c 2) anyonecan produce a newciphertext(c ′1, c

′2) on the same message without knowing any secret key

or learning the message itself. Indeed, given ( g r , tg rY ), i t i s

enough to select r ∗ u←− Zq and compute a new and unlinkable

ciphertext ( g r +r ∗, tg (r +r

∗)Y ). The security of this randomizedElGamal encryption still holds as shown in [12].

5.4. The algorithm

In this section, we provide the details of the oblivious assign-

ment scheme for our system model. In particular, we first describethe data structures maintained locally by each process pi, then we

provide the details about the coordinator selection and the roundphases: the assignment phase and the release phase.

Data structures. Each process pi maintains locally the following data

structures:

• roundi: is an integer representingthe round pi is participating in.

• coordinator i: is an integer variable storing the identifier of the

current coordinator, initially set to p1.• statei: is a variable that can be set to {NCS,waiting , CS} and it

represents the state of pi, respectively pi is not interested in any

resources, pi is waiting fora resource, pi has obtained a resource.

• phasei: it can have the following values idle, request, releaseand indicates the current phase of the protocol perceived by pi.

More in detail, a process is idle (i)before it delivers or creates the

request token and (ii) when it delivers the notification that the

coordinator is changed due to the end of the release; a processis in the request phase when it delivers the request token and

until it delivers the release token and it is in the release phase

from the deliver of the release token until it is notified about a

new coordinator.

• next i: is the identifier of the process that follows p

i in the logical

ring used in the assignment phase.

• ticket i: is a pair ⟨rd, tk⟩ where tk is an encrypted ticket associ-ated to a slot (whether real or not) and rd is a random number

used by the encryption algorithm and it is necessary but not

sufficient to recover the decrypted value of the ticket.

• Pr _keyi/Pb_keyi: ElGamal private/public keys used to de-crypt/encrypt tickets.

• keysi: rq_keysi and rl_keysi: they are two sets storing theephemeral keys needed do decrypt respectively the selectedticket and the release token (in case pi is coordinator).

• resourcei: is an integer representing the slot id obtained by pi.

• releasing i: is a Boolean flag. It is set to true when pi has no as-signed slot of R, false otherwise.

• correct i: is a set maintaining the current set of alive processes.

• last _messagei: is a variable storing the last message sent out onthe logical ring by pi. It is used to prevent token losses.

• shared_keysi[]: it is an array of n elements. The jth entry storesa piece of the share of the key of p j.

• faulty_keysi[]: it is an array of sets. The jth entry of the arraystores the pieces of the share of p j collected from other pro-

cesses.

In addition, the algorithm also employees two tokens, namely

request _token and release_token. A request _token is essentially aset containing encrypted tickets and each ticket refers to real or

dummy slots. A release_token is essentially a number encrypted

to store the value 1 (i.e. all the tickets have been released) or adifferent number (i.e. there exists at least one ticked not released).

Round and coordinator change. The pseudo-code for the round and

coordinator change is shown in Fig. 1.

We defined the following functions to simplify the code:

• init_private_key( pi)/init_public_key(): initialize pi’s private andpublic keys.

• select_valid_slot({r 1, r 2, . . . , r n}): given the set of (real anddummy) resource slots {r 1, r 2, . . . , r n}, select a real slot.

• select_notValid_slot({r 1, r 2, . . . , r n}): given the set of (real anddummy) resource slots {r 1, r 2, . . . , r n}, select a dummy slot.

• create_request_token(r 1, r 2, . . . , r n−1): given the set of (realand dummy) resource slots {r

1, r

2, . . . , r

n−1}, create a set of

tickets and the corresponding request token.


6/14


7/14


Fig. 2. The request() protocol (code for pi).

A slot is released by calling the release() operation. In this case,the variable statei is set to NCS and the flag releasing i is set to true(lines 01–02). When pi receives release_token, it checks whether itis the coordinator for the current round. If pi is not the coordinator,according to its state, it releases or keeps the assigned slot (line05), it re-randomizes the token (line 06), set its phase to release(line 07), and finally passes the token to its neighbor in the logicalring (line 08) and stores such message for possible retransmission(line 09). If pi is the coordinator for the current round, then itchecks in which phase of the algorithm it is. If it is in the releasephase it means that the release token has done a full run in thering and then it could check whether all other processes releasedtheir assigned slots (lines 10–13). In order to do that, p i sends a

get_release_ephemeral_key message to other processes (line 12).On the other hand, if pi is the coordinator and it is not in the releasephase, it may happen that it became coordinator due to the fault of the previous one and in this case, the token has not yet circulatedalong all the ring. Thus, pi enters the release phase and forwardsthe token (line 14–16).

When a process pi receives a get_release_ephemeral_key( j, tk)message, it generates a temporary key that can only be used todecrypt the token tk (line 19) and returns itto p j. When a process pireceives a release_ephemeral_key(k, j) message, it stores the keyk sent by p j in a buffer rl_keysi (line 22).

When all ephemeral keys of non-faulty processes are availableand all the shares of faulty processes allow p i to reconstruct the‘‘faulty’’ keys (line 23), then p i decrypts the token and checks if

all slots were released. If so, then pi elects the new coordinatorand sends a new_round message to its neighbor so that a new

round can be started (line 30). Otherwise, the current token isdiscarded and a new turn of the release phase is started (lines32–35). Finally, when a process pi receives a new_round message,it updates the local variables roundi and coordinator i and forwardsthe new_round message to its neighbor (lines 36–42). Finally, itswitches again the phase to idle.

The crash() event management . When a process p j isdetectedby thefailure detector (see Fig. 4), each process pi first updates its list of non-faulty processes by removing p j (line 01) and then it checks if one of the following cases holds:

• p j was the next of p i in the logical ring (lines 02–06): in thiscase, the logical ring is temporarily disconnected and pi needs

to update its next i variable to the next non-faulty process in thering. In addition, pi will also forward the last message seen tothe new neighbor to handle the possible loss of the token dueto the failure of p j.

• p j was the coordinator forthe current assignment (lines 07–10).In this case a new coordinator must be selected through thefollowing deterministic rule: the new coordinator is the non-faulty process with the smallest identifier greater than the oldcoordinator (mod n).In all cases, after a crash of a process p j is detected, p i sends

to every non-faulty process its piece of the shared key that willbe used to reconstruct the keys of p j, decrypt tickets, and releasetokens (lines 11–13).

Any process pi will store the share of the key of p j in the jthentry of the array faulty_keys

i[ j] and eventually use it to decrypt

encrypted messages (lines 14–15).


8/14


Fig. 3. The faulty resilient release() protocol (code for pi).

6. Correctness proofs

In this section, we prove the correctness of the protocol shownin Figs. 1–4. In particular, Theorem 1 proves that our protocolsatisfies the UniqueAssignment property, Theorem 2 proves theLockoutAvoidance property by means of the results shown inLemma 2 and Corollary 1 and finally, Theorem 3 proves that theprotocol in Figs. 1–4 satisfies the SO-mA property. To simplify thelatter proof, we prove some intermediate results. In particular,we defined the Correct Assignment Indistinguishability Experiment (CAIE) used to show that, in absence of failures, an adversarycannot do better than guessing the correct assignment when thereare only two honest processes (Lemma 3). As a consequence, weare able to state the obliviousness of both the assignment phase(Lemma 4) and release phase of our algorithm (Lemma 5) in the

absence of failures. Finally, we prove the obliviousness of ourprotocol when failures do occur (Theorem 3).

Theorem 1. Let Π = { p1, p2 . . . pn} be the set of processes of thedistributed system and let {r 1, r 2, . . . , r m} be the set of slots of theresource R. Given the algorithm shown in Figs. 1–4 and given two

processes pi, p j ∈ Π , if pi and p j access concurrently the resource R,then the slot r x assigned to pi andthe slot r y assigned to p j are distinct.

Proof. We prove this lemma by contradiction. Assume that r x =r y. Thus, pi and p j executed line 28, Fig. 2 and resourcei is equalto resource j. The latter implies that there exist two tickets ticket iand ticket j that store the same encrypted value. But this is acontradiction.

Note that, processes obtain tickets by selecting them from therequest _token (line 07, Fig. 2) and the request token is createdby the coordinator of the current round at the beginning of theassignment phase (line 16, Fig. 1). But the request token does notcontain duplicates and resource slots are distinct, thus there canonly be one ticket associated to r x (or r y). Theorem 1


9/14


Fig. 4. The crash protocol (code for pi).

Lemma 2. Given the algorithm shown in Figs. 1–4, then every roundeventually terminates.

Proof. The proof is done by induction. Let us first prove that fromround 1, eventually allthe non-faulty processes will move to round2 and then we will show that the same happens also in a genericround i.

Basic step: round 1. Round 1 starts with the Init statement whereall processes are non-faulty, all local variables are initialized totheir default values (lines 01–06, Fig. 1) and the coordinator for thecurrent round is deterministically selected.

In particular, when executing this procedure at round 1, p1will select itself as coordinator, and the assignment phase startswith the transmission of the request message (line 18, Fig. 1)to p2, containing the created token. p2 will forward the message

just received to the process whose identifier is stored in its next 2

variable, i.e., p3, (see line 13, Fig. 2) and so on, until the requestmessage returns to p1.

If no failure occurs, the request message containing the requesttoken will return to p1 in n hops and the release phase will thenbegin. We now show that, also in case of failures, the requestmessage will circulate along the logical ring until it reaches againthe coordinator.

When a process p j fails while the request message is travelingalong the logical ring, the crash( p j) procedure is activated (cfr.Fig. 4). Independently from the role of the faulty process in thecurrent assignment, the procedure allows non-faulty processes toupdate their next i variable to the next non-faulty process in thelogical ring in order to keep it connected (lines 01–04, Fig. 4). Inaddition, the predecessor of the faulty process will also forward

the last message delivered before the failure to its new next node(line 05, Fig. 4).

Let us observe that there exist only three types of messages cir-culating along the logical ring: (i) request (request _token), (ii) to-ken_release (release_token) and (iii) new_round (round, leader )and that each time the first-type message is delivered to the coor-dinator, a second-type message is transmitted and the delivery of a second-type message prompts the transmission of a third-typemessage. Thus it is clear that, at each time unit, only one token iscirculating in the ring (respectively request token, release tokenand new round token). In addition, since point-to-point channelsare FIFO and reliable, it follows that once a token has been createdit cannot be lost, in case of failures, before it reaches again the co-ordinator.

Hence, the only relevant case to consider during the requestphase is thefailure of thecoordinator. In particular, thecoordinator

can fail (1) before sending the request (request _token) or (2)immediately after process in the logical ring with respect to the

coordinator.

• Case 1—the coordinator fails beforesending the request (request _token). The request token is never created and there is nothingcirculating in the logical ring. When the failure detector willnotify p2 about the coordinator failure, it will execute lines07–10 by electing itselfas thenew coordinator.This will initiatethe coordinator changeprocedure, where p2 will check whetheran assignment is already running or not (line 08, Fig. 1). Inthis case, since the request token has never been sent, the newcoordinator will find its phase2 variable set to idle and will actas if the round was just started, by executing lines 08–20, Fig. 1.

Let us note that if both p1 and p2 fail, p3 will become the newcoordinator only after that the failure detector revealed boththe crashes (see line 08, Fig. 4). Thus, the case of the failure of

p2 can be reduced to case 1 (if the failure is detected later thanthe failure of p1) or to the general case discussed before of anon-coordinator failure (if it is detected before than the failureof p1).

• Case 2—the coordinator fails after sending the request (request _token). Two further cases can occur: (a) p2 has not deliveredthe request token and (b) p2 has already delivered the requesttoken.– Case 2a— p2 has not delivered the request token. This is

equivalent to case (1) where p2 acts as coordinator from thevery beginning of the round.

– Case 2b— p2 delivered the request token. Since p2 has alreadydeliveredthe request token,it hasexecuted lines 03–14,Fig.2and in particular it has set its phase2 variable to request. As

a consequence, when the coordinator change procedure isactivated, p2 will not take any action and will just wait untilthe request (request _token) comes back to then start therelease phase.

At this point, the current coordinator will create a release tokenand will send it to its next node through a token_release message(line 13).

While delivering the token_release message, this process willexecute line 08 and forward the release token to its next node andso on, until the release token also returns to the coordinator.

If a failure occurs, the notification of the failure detector willtrigger the update of local variables and the transmission of therelease token. Thus, also in this case, the only interesting event

to consider is the failure of the current coordinator. Without lossof generality, we consider the case where the old coordinator


10/14


p1 failed during the assignment phase and the new coordinator p2 fails during the release. Let us consider the following cases:(3) p2 fails beforesending the token_release (release_token),(4) p2fails after sending the token_release (release_token) message butbefore sending the new_round(round, leader ) message, and (5) p2fails just after sending the new_round(round, leader ) message.

• Case 3: p2 fails before sending the token_release (release_token)

message. We note that if p2 has not already sent therequest (request _token) message, we fall back to the case of failures during the assignment phase, which we have alreadyconsidered.

• Case 4: p2 fails after sending the token_release (release_token)message but before sending the new_round(round, leader )message. If p2 sends the token_release (release_token) messageand then fails, the message can be lost, in which case we fallback to the previous case. Therefore, we assume next that thetoken_release (release_token) is delivered by p3 and then p2happens to fail. Such a failure is notified to all processes andin particular to the predecessor and successor of p2 in the ring(i.e., pn and p3). When p3 is notified about the failure of p2, itexecutes lines 07–10, Fig. 4 and becomes coordinator. Note that

(by assumption), p3 has already delivered the release token,thus its phase3 variable is set to release. Therefore, it takes nofurther action.

When pn is notified about the failure of p2, it executes lines01–05, Fig. 4, thus updating its next n variable to p2 andforwarding the last delivered message. If pn has not alreadydelivered the token_release (release_token) message sentoriginally by p2, then the last message delivered was therequest (request _token) sent by p2. This message will thus beforwarded to the new coordinator p3 that will process it bystarting the release phase (if it is not already started). On thecontrary, if token_release (release_token) message originallysent by p2 has already been delivered, then p3 decrypts therelease token while checking if all slots were released (i.e., lines10–13 and lines 18–25, Fig. 3).

Note that the condition in line 23, Fig. 3 will eventually besatisfied.Indeed, non-faultyprocesseswill eventuallyanswer tothe get_release_ephemeral_keymessage with their respectivekeys, while keys of faultyprocesses will be reconstructed by theunion of the shares transmitted when failures are detected (cfr.lines 11–15, Fig. 4). If all slots have been released, then p3 startsa new round and sends a new_round message to its next nodethat, in turns,will execute lines 36–44,Fig.3 going to thesecondround as well.

On the other hand, if there are processes that still ownslots of the resource R, then the coordinator will againcirculate a new release token in the ring (lines 32–34, Fig. 3).Since processes follow the protocol specification, eventually allassigned slots will be released and the condition in line 25 will

be satisfied so that a new round can be started.Let us note that if p3 also fails, the new coordinator will

become the process next to p3 in the logical ring (i.e. p4) and,depending on the order in which the failure detector revealsfailures, we fall down in one of the previous cases.

• Case 5: p2 fails after sending the new_round(round, leader )mes-sage. If p2 fails just after sending the new_round(round, leader )message, but before it is delivered to p3, such a message canbe lost and it is as it was never sent. Therefore, we fall backto the previous case. As a result, we consider only the casewhere p3 delivered the new_round(round, leader ) messagefrom p2 and then it is notified about its failure. p3 executes theround and coordinator change procedure, thus propagating thenew_round (round, leader ) message, electing itself as new co-

ordinator, and setting its phase3 variable to idle. Thus, when thefailure detector reveals the failure of p2, p3 just updates its setof

non-faulty processes and takes no further action. On the otherhand, the process pn (predecessor of p2) will set its next nodeto p3, elect p3 as the new coordinator, and forward the to-ken_release (release_token) message which was originally sentby p2. This message will be filtered out by p3, which will propa-gate only the new_round(round, leader ) message.

Induction step: round i. Note that, when moving from a generic

round i − 1 to the current round i , the coordinator of the roundi − 1 sends a new_round message that will circulate in the logicalring. Therefore, every process p j delivering such a message willexecute lines 36–44, Fig. 3 updating their round j local variable.Thus, every p j will execute line 41 re-initializing its local variables,returning to thescenario describedin thebasic step. The claim thusfollows. Lemma 2

Corollary 1. Let Π = { p1, p2 . . . pn} be the set of processes of thedistributed systemand let f be themaximum number of failures. Giventhe algorithm shown in Figs. 1–4, then every non-faulty process pieventually becomes coordinator at the beginning of a round.

Proof. The claim simply follows by considering that a non-faulty

process pi becomes leader infinitely often when one of thefollowing conditions holds: (i) a failure of the current leaderoccursand pi follows the failed leader in the logical ring (lines 07–10,Fig. 4) or (ii) a round ends, the non-faulty coordinator sends anew_round message and p i follows the old leader in the logicalring (lines 26–30, Fig. 3). Let us not that in case (i), pi may becomeleader during the execution of a round. However, the number of failures is bounded by f and thus this may happen at most f times.As a consequence, pi will be eventually leader due to condition(ii). Corollary 1

Theorem 2. Let Π = { p1, p2 . . . pn} be the set of processes of thedistributed system, let {r 1, r 2, . . . , r m} be the set of slots of theresource R and let f be the maximum number of failures. Given thealgorithm shown in Figs. 1–4, if a non-faulty process p

i requests the

access to the resource R, then it eventually gets a slot r j of R

Proof. The claim directly follows from Lemma 2 and Corollary 1by observing that when a process pi becomes coordinator at thebeginning of the round, it executes lines 09–15 of Fig. 1. As aconsequence, it is able to select a valid ticket as soon as it isinterested in accessing a slot. Considering that the number of failures is finite, this situation occurs infinitely often, hence theclaim follows. Theorem 2

Security of the assignment—correct assignment indistinguishabilityexperiment (CAIE). We consider the worst-case scenario in whicha non-adaptive adversaryA compromises n − 2 processes. We willshow that if A is able to guess the correct assignment of pi and

p j with probability better than 1

2 + negl( x), where negl( x) is anegligible function1in the security parameter x = | p|, then thereexists a probabilistic polynomial-time algorithm that can solveDDH in G (breaking the semantic security of ElGamal encryption).

We define the Correct Assignment Indistinguishability Experi-ment (CAIE) as follows:

• The adversary A outputs the set of processes C to becompromised.

• An assignment phase is run. At the end of it, the adversary A isprovided with a transcript L of all messages exchanged and, inaddition, the memory content of all processes in C .

1 A function f : N → R is negligible if ∀ p polynomial function p : N →R∃n0 s.t ∀n > n0 | f (n)| ≤

1| p(n)|

.


11/14


• The adversary A outputs a guess a = ⟨ pi, r k⟩, ⟨ p j, r t ⟩.• Theoutputof the experiment is defined to be1 if a is the correct

assignment of slots for pi, p j, 0 otherwise.

Recall thatA embodies honest-but-curious processes, and thuscannot inject or manipulate messages but must faithfully followthe algorithm specifications. We want to show that the probabilitythat A outputs the correct guess is 1/2 plus a negligible function

in the security parameter. Note that the assignment itself doesnot leak information over the usage or not of a slot, so provingSO-mA for the assignment phase means to show that all theassignment of slots (reals and dummies) have the same likelihoodwhen the assignment phase ends. Let pi and p j be the two honestprocesses and let At

RC ,F H be the assignment of slots not owned by

the coalition to honest non-faulty processes at time t .In this case |Prob

At

RC ,F H = {⟨ pi, r k⟩, ⟨ p j, r t ⟩}|CS(t )

− Prob

At RC ,F H

= {⟨ pi, r t ⟩, ⟨ p j, r k⟩}|CS(t )

| ≤ ε( x) it is trivially equivalent

to Prob At

RC ,F H = {⟨ pi, r t ⟩, ⟨ p j, r k⟩}|CS(t )

= 1

2 + ε( x).

Lemma 3. Under the DDH assumption in G, the probability that Awins in CAIE is ≤ 1/2 + ε( x).

Proof. We fix an adversaryA and set |Pr [CAIEA(k) = 1] − 1/2| =ϵ( x). We build an adversary A′ that usesA to violate the semanticsecurity of ElGamal encryption. The adversary A′ obtains a publickey g yi and plays the CPA-security game [11]. In this game, A′

generates two challenge messages of the same length and receivesthe encryption of one of them. A′ must guess which message wasencrypted.

We build A′ as follows:

• A′ starts A and obtains C.• A′ sets g yi as public key of pi. We assume w.l.o.g. that 1 < i < j

and that the leader is p1. A′ simulates an assignment phase for

A and generates a transcriptL. Itis easy tosee that, even thoughA

′ does not know the secret key of pi, the simulation is perfectand the transcript L is correct. Indeed, A′ knows the actual

content of encrypted tickets and can respond to decryptionqueries (via ephemeral keys).

A′ picks two encrypted tickets t 0 = ( g

r , r 0 g rY ), t 1 = ( g

r ′ ,

r 1 g r ′Y ) uniformly at random from the token entering pi. It then

sets (r 0, r 1) as the challenge messages in the CPA-game. A′

receives the response to the challenge ( g r , r b g ryi), and embeds

the ticket t ′ = ( g r , r b g ryi g

r

∀ pk ∈Π \{ pi} yk ) into the token exiting

from pi. A′ cannot respond to decryption query of t ′. If in the

transcript L a process in C selects t ′, A′ stops the execution of A, it aborts, and restarts the simulation.

• A outputs its guess a. If pi is paired with t 0, A′ outputs 0,

otherwiseA′ outputs 1.

A′ runs in polynomial time and wins whenever A wins in the

CAIE experiment. Since ElGamal is semantically secure, it must be

that ϵ( x) is negligible and this proves the lemma. Lemma 3

Thanks to the previous lemma, we can show that our algorithmis oblivious during the release and assignment phases:

Lemma 4. Given the algorithm shown in Figs. 1–4, if |C| ≤ n − 2andf = 0, then theSO-m A property is satisfiedduring theassignment

phase.

Proof. The lemma follows directly from Lemma 3. Indeed, theexperiment CAIE is well defined when we have at least two honestparties. The adversary A′ can use an adversary A that breaks CAIEwith more than two honest processes to break ElGamal encryptionwith multiple messages. A′ creates two possible assignments of tickets to the k honest processes a0 = (r 0, r 1, . . . , r k−1), a1 =

(r ′

0,r ′

1, . . . ,r ′

k−1)andusesA to distinguish theencryption of one of

these two assignments under an unknown private key. Lemma 4

Lemma 5. Given the algorithm shown in Figs. 1–4, if |C| ≤ n − 2and f = 0, then the SO-m A property is satisfied during the release

phase.

Proof. Let us suppose to have n − 2 processes in C and twohonest processes pi, p j i < j. To infer any information on therelease of either pi or p j, the processes in C must extract someinformation from the token t ′ which is sent by pi. This would

allow processes in C to rule out some possible assignments,thus violating SO-mA. This problem, however, is straightforwardlyreducible to the problem of deciding if a triple ⟨ g a, g b, g c ⟩ (inour case ⟨ g r , g Pr _key j, g c ⟩) is a DDH-tuple. The latter is known tobe hard under the so-called DDH assumption. Therefore, the onlyinformation available to processes inC is the output of the secure-OR. But this information only allows processes in C to learn if some process in H is using a valid slot. But this is exactly theindistinguishability definition of SO-mA. Lemma 5

Lemma 6. Given the algorithm shown in Figs. 1–4, if |C| ≤ n − 2and f = 0, then the SO-m A property is satisfied.

Proof. The proof follows directly from Lemmas5 and 4. Lemma 6

Obliviousness in case of faults. Dueto previous lemmas, we have thatthe algorithm shown in Figs. 1–4 needs at least two honest non-faulty processes to preserve the obliviousness of the assignment.As a consequence, in case of faulty processes, we have |C| ≤(n − f ) − 2. But, on the other hand, we have the other trivialbound due to the secret sharing scheme, that is C < h . Therefore,|C| ≤ min(n − f − 2, h − 1), which implies |C| ≤ n − f − 2.

In the following, we will prove that the adaptation of theprotocol provided in this section solvesthe SO-mA problem,as longas |C| ≤ n − f − 2.

Theorem 3. Let Π = { p1, p2 . . . pn} be the set of processes of thedistributed system and let {r 1, r 2, . . . , r m} be the slots of the resourceR. Given the algorithm shown in Figs. 1–4, if |C| ≤ n − f − 2 thenthe SO-m A property is satisfied.

Proof. Due to Lemmas 6 we have that if no process fails during theassignment and release phases, then SO-mA is satisfied. Thus, inthe following, we will consider only the scenario where a failureoccurs.

Every process pi could fail: (1) before it participates in theassignment phase, (2) after it participates in the assignment phasebut before it writes on the release token or (3) after it writes on therelease token.

• Case 1: pi fails before selecting a ticket . Let x be the number of non-faulty processes at the beginning of the assignment phase.If p i fails before selecting a ticket, it simply does not get anyticket and it is excluded from the set of non-faulty processes.As a consequence, as soon as its predecessor detects its failure,it will forward again the request token to pi’s next node. This is

equivalent to an assignment of m slots to x − 1 processes whereno failure occurs. Due to Lemma 6, SO-mA property is satisfied.

• Case 2: pi fails after selecting a ticket . When the failure of piis detected, every process transmits the share of the p i’s keyit stores (lines 11–13, Fig. 4). Thus, processes in C will learnthe private key of pi and they could remove the encryptionof pi on the request token. However, all tickets contained inthe request token are encrypted with the key of at least twonon-faulty honest processes, hence the SO-mA property ispreserved. Regarding the release phase, notice that p i simplydoes not participate. But, due to the property of the secure ORused in therelease phase,the case in which a faultyprocessdoesnot participate in the release phase is equivalent to the case inwhich a non-faulty process participatesin therelease phase andreleases the slot. Thus, no leakage can occur during the releasephase and the SO-mA property is thus still preserved.


12/14


• Case 3: pi fails after it writes on the release token. Similarly tothe previous case, there is a time t after which processes in Clearn theprivate keyof pi. Thus, processesinC couldremove theencryption of pi on the release token T , obtaining the token T

′.However, the relevant information of T ′ is still protected by theencryption of at least two non-faulty honest processes. Thus,also in this case, the SO-mA property is preserved and the main

claim follows.

Theorem 3

7. Performance analysis

In a nutshell, Theorem 2 proves that the algorithm shown inFigs. 1–4 provides fairness for slot allocation: i.e., if an honestnon-faulty process requests a slot of a resourceR, it will eventuallyget it. However, it may happen that an honest non-faulty process

p j requests a slot at some round i but it gets a slot only when itbecomes coordinator (thisis the worst-casescenario).In particular,in the worst-case scenario, p j must wait n − 1 rounds before beingassigned a slot, even if several are available. As a consequence, thealgorithm may suffer from poor utilization of resource slots andlarge waiting periods.

In the following, we will evaluate, in a failure-free scenario, theaverage numberof slots assigned at each round and theprobabilitythat an honest process, requesting a slot at round i, will get one insome following round i + k, where k ∈ N is the delay between therequest and the following grant of a slot (i.e. we evaluate the prob-ability that a honest process waits k rounds before getting a slot).

Let us focus on a generic round i. According to our algorithm, atthe beginning of a round, each process can be in one of the follow-ing states: waiting or NCS . We denote with w the number of pro-cesses in the waiting state and with n −w the number of processesin the NCS state. Consider now the token tk at round i; it will becomposed of n tickets, m of which will be associated to valid slotswhile the remaining n − m will be associated to non-valid ones.

Let Si be the random variable representing the number of validslots assigned at the end of round i, in the following we willcompute:

1. The expected number E [Si] of slots assigned to processes in thewaiting state at the end of round i.

2. The probability that a process requesting a slot at round i getsit at round i + k.

Note that, the round coordinator is the only process that hasaccess to the entire set of slots and can always get a valid slot incase it needs one. Thus, we will not consider the coordinator whencalculating the probability of getting slots.

Lemma 7. Let Si be the random variable representing the number

of valid slots assigned at the end of round i. Let w be the number of processes in the requesting state at the beginning of round i. Theexpected number of slots assigned to processes in the waiting state at

the end of round i is E [Si] =w

j=1

j

w j

n−wm− j

( nm ) = mw

n .

Proof. The expected value of the random variable Si is computedas the mean of the distribution of S i. In particular, we have that

E [Si] =min(w,m)

x=0 x × P (Si = x), where P (Si = x) is the probabilitythat x processes in the waiting state get a valid slot during round i.

Note that, the assignment of a slot during a specific roundi is independent of the assignments in the previous rounds. Inaddition, the assignment performed at each round can be seen asthe problem of having w man wearing a white hat and n − w

wearing a black hat, selecting balls from a container with n balls,m of which are white while the others are black. Each person picks

Fig. 5. Probability that a process in waiting state gets a slot within a distributed

system with n = 100 processes.

a ball at random from the container. This problem is well-knownand can be represented by a binomial distribution. In particular,

P (Si = j) =

w

j

n−w

m− j

n

m

wherew

j

is the number of possible assignments of j slots to w

processes,

n−w

m− j

is the number of possible assignments of m − j

slots to the remaining processes, and

n

m

is the total number of

possible assignments of m slots. The claim follows. Lemma 7

Lemma 8. Let p j be a process requesting a slot of a resource R at round i. The probability that p j gets at least one valid slot at round

i + k is psucc = 1 −

1 − mn

k.

Proof. We denote with X i the event ‘‘valid slot at round i’’ and let X i be the event ‘‘non-valid slot at round i’’. Note that, X i is a randomvariable following the binomial distribution. In particular,

p( X i) =

n−1

m−1

n

m

= mn.

Conversely, the probability of not picking a valid ticket is p( X i) =1 − p( X i). At each round, a process p j selects a ticket form thecurrent token and this event is independent of all past selections.Thus, P ( X i+k ∩ X i ∩ X i+1 ∩. . . X i+k−1) = P ( X i)

k, hence theprobability

of picking at least one valid ticket in one out of k rounds is 1 −P ( X i+k ∩ X i ∩ X i+1 ∩ . . . X i+k−1). Lemma 8

In Fig. 5, we show the probability of getting a slot versus thenumber of waiting rounds in a configuration with n = 100 pro-cesses and m = {10, 20, 30, 40, 50} slots.

In the worst case, a process will be assigned a valid slot after

n rounds. However, the probability to get a valid slot approaches1 exponentially quickly. As a matter of fact, it is quite simple

to compute the expected number of rounds a process must waitbefore getting at least one slot. This is shown by the next lemma.

Lemma 9. Let p j be a process requesting a slot of a resource R at round i. The expected number of round E [k] to wait before getting aslot is n

m.

Proof. E [k] = P ( X 0) + (1 − P ( X 0))(1 + E [k]) this leads to E [k] =1

P ( X 0) = nm . Lemma 9


13/14


8. Conclusion

Thanks to cloud computing, organizations, companies, and in-dividual users can reduce their computing assets and outsource

their computational workloads. These benefits come with a se-curity price: cloud providers cannot be considered trusted, thusdata and interactions should be kept private from them. There-

fore, there is the need for basic communication and coordinationparadigms that are able to ensure an inherent degree of privacy.

This paper addressed the strong oblivious assignment problem,i.e., a coordination problem where n processes compete to getexclusive access to one of the m available slots of a resourceR, while still maintaining the obliviousness of the assignment.A rotating token algorithm, solving the oblivious assignmentproblem in the presence of at most f crash failures, has beenintroduced. This algorithm has been proven correct as long as atleast two processes remain honest. We also performed a rigorousanalysis showing that the probability of being assigned a slotat round i + k, after requesting one at round i, approaches 1exponentially quickly with k.

Acknowledgments

The authors want to thank the anonymous reviewers for theircomments that greatly improved content and presentation of thepaper. The work has been partially supported by TENACE project(MIUR-PRIN 2013).

Appendix A. Glossary of symbols

In the following we will report the list of symbols used in thepaper and the corresponding explanation:

• Π : is the set of all the processes { p1, p2 . . . pn} participating in

the oblivious assignment computation;• C: is the subset of Π identifying honest-but-curious processes;

• H : is the subset of Π identifying honest processes (i.e. H =Π \ C);

• R: resource made of m distinct slots shared by processes in Π ;

• R: is the set of m slots {r 1, r 2 . . . r m} of the resource R;

• f : upper bound on the number of processes that may fail bycrash;

• At Y , X : assignment of a set of slots Y to the subset of processes X the at time t ;

• Rt H

: is the set of slots assigned to honest processes at time t ;

• Rt C

: is the set of slots assigned to honest-but-curious processesat time t ;

• Rt C: is the set of slots not assigned to honest-but-curiousprocesses at time t (i.e. Rt

C = R \ Rt

C);

• F t H

: the set of faulty honest processes at time t ;

• F t H

: the set of non-faulty honest processes at time t (i.e. F t H

=H \ F t

H );

• TAt RC ,F H

, is a tentative assignment at time t of the resource slots

non assigned at the coalition to honest non-faulty processes;

• TASt RC ,F H

: is the set of all the possible tentative assignments

that can be obtained at time t

Appendix B. Cryptographic details

This appendix provides thedetailson theimplementation of thecryptographic functions used in the algorithm shown in Figs. 1–4.

Fig. 6. Crypto Operations A.

Fig. 7. Crypto Operations B.

Ticket assignment . The round leader p1 encodes the set of tickets,encrypts them, andsendsthem to allprocesses positioned logicallyas a ring structure. In particular, the set of tickets are first encodedas elements of G, T : {t 1, t 2, . . . , t x}, then encrypted, obtainingT ′ : {( g r 1, t 1 g

r 1Y ), ( g r 2, t 2 g r 2Y ) , . . . , ( g r x , t x g

r x Y )}, andsent throughthe ring structure. Each process in the ring can perform severalactions on the incoming set of encrypted tickets. It can permutetheset, re-randomizeeach element, or removeits encryption layer.Thus, the basic idea is to let each process pick uniformly at randoman encrypted ticket from T ′ which will have to be opened incooperation with all other processes in the ring. The remainingtickets arethen re-randomized andthe new setis shuffled andsentto thenext process. Theassignment ends when theset of encrypted

tickets reaches again the leader (see Figs. 6–9).Ticket release. The release of tickets is handled by the round leader

p1. The basic ideais tocollect used tickets by querying each process.To make the release oblivious, processes will still use ElGamalencryption to encode a Boolean flag True/False. If a process wantsto release a ticket t j, it will alter the jth ciphertext to indicate aTrue value and hence that the jth ticket is now released. Beforealtering any encryption though, the process pi must remove itskey component g rPr _keyi from all ciphertexts and re-randomize theresults.

This is accomplished as follows: the round leader p1 preparesa vector V := [( g r 1, g r 1Y ), ( g r 2 , g r 2Y ) , . . . , ( g r n , g r nY )] and sendsit through the ring of processes. V [ j] is essentially an ElGamalencryption of ‘1’ that corresponds to the jth ticket. To release

a ticket t j, it is enough to alter the ciphertext ( g r j

, g r jY

) into( g r j,Dg r jY ), for some dummy value D ̸ = 1. Before forwarding V tothe next process, each process pi will have to re-randomize everyciphertexts in V and, at the same time, remove its key component

g rPr _keyi .

Functions. We define a series of functions to capture thecryptographic operations described above. The functions are:decode_element, randomize_token, release_resource and remove_layer. The function decode_element takes as input a ticket fromthe assignment token, and returns the element decrypted, thisfunction needs to communicate with all processes. The functionrandomize_token takes as input a token, randomizes all theelements. The function release_resource takes as input a releasetoken and a Boolean value and adds the value to the token. Thefunction remove_layer takes as input a release token and removesthe layer of encryption of the local process.


14/14


Fig. 8. Functions A.

Fig. 9. Functions B.

References

[1] MichaelArmbrust, Armando Fox,Rean Griffith,AnthonyD. Joseph,Randy Katz,Andy Konwinski, Gunho Lee, David Patterson, Ariel Rabkin, Ion Stoica, MateiZaharia, A view of cloud computing, Commun. ACM 53 (4) (2010) 50–58.

[2] Giuseppe Ateniese, Roberto Baldoni, Silvia Bonomi, Giuseppe Antonio Luna,Oblivious assignment with m slots, in: Proceedings of 14th InternationalSymposium on Stabilization, Safety, and Security of Distributed Systems, (SSS2012), in: Lecture Notes in Computer Science, vol. 7596, Springer, Berlin,Heidelberg, 2012, pp. 187–201.

[3] H. Attiya, A. Bar-Noy, D. Dolev, D. Peleg, R. Reischuk, Renaming in anasynchronous environment, J. ACM 37 (1990) 524–548.

[4] H. Attiya, J. Welch, Distributed Computing: Fundamentals, Simulations and

Advanced Topics, second ed., John Wiley Interscience, 2004.[5] A. Barnett, N.P. Smart, Mental poker revisited, in: Kenneth G. Paterson(Ed.), Cryptography and Coding, Proceedings of the 9th IMA InternationalConference, in:Lecture Notes in Computer Science, vol. 2898, Springer Verlag,2003, pp. 370–383.

[6] D. Boneh, The decision Diffie–Hellman problem, 1423, 1998, pp. 48–63.http://dx.doi.org/10.1007/BFb0054851.

[7] S. Bulgannawar, N.H. Vaidya, A distributed k-mutual exclusion algorithm,in: International Conference on Distributed Computer Systems, 1995,pp. 153–160.

[8] J.E. Burns, G.L. Peterson, The ambiguity of choosing, in: Proceedings of theEighth Annual ACM Symposium on Principles of Distributed Computing,Priciple of Distributed Computing’89, ACM, New York, NY, USA, 1989,pp. 145–157.

[9] T. El Gamal, A public key cryptosystem and a signature scheme based ondiscrete logarithms, in: Proceedings of CRYPTO 84 on Advances in Cryptology,Springer-Verlag New York, Inc., New York, NY, USA, 1985, pp. 10–18.

[10] C. Gentry, Fully homomorphic encryption using ideal lattices, in: Proceedingsof the 41st Annual ACM Symposium on Theory of Computing, ACM, 2009,

pp. 169–178.[11] O. Goldreich, Foundations of Cryptography: Volume 2, Basic Applications,

Cambridge University Press, New York, NY, USA, 2004.[12] P. Golle, M. Jakobsson, A. Juels, P. Syverson, Universal re-encryption for

mixnets, in:In Proceedings of the2004 RSAConference,Springer-Verlag, 2002,pp. 163–178.

[13] H. Kakugawa, S. Fujita, M. Yamashita, T. Ae, A distributed k-mutual exclusionalgorithm using k-coterie, Inform. Process. Lett. 49 (4) (1994) 213–218.

[14] D. Davide Lamanna, Giorgia Lodi, Roberto Baldoni, How not to be seenin the cloud: a progressive privacy solution for desktop-as-a-service,in: Robert Meersman, Hervé Panetto, Tharam S. Dillon, Stefanie Rinderle-Ma,Peter Dadam, Xiaofang Zhou, Siani Pearson, Alois Ferscha, Sonia Bergamaschi,Isabel F. Cruz (Eds.), OTM Conferences, in: Lecture Notes in Computer Science,vol. 7566, Springer, 2012, pp. 492–510.

[15] M. Maekawa, A square root n algorithm for mutual exclusion in decentralized

systems, ACM Trans. Comput. Syst. 3 (2) (1985) 145–159.[16] K. R aymond, A distributed algorithm for multiple entries to a critical section,

Inform. Process. Lett. 30 (4) (1989) 189–193.[17] M. Raynal, Algorithms for Mutual Exclusion, MIT Press, Cambridge, MA, USA,

1986.[18] G. Ricart, A.K. Agrawala, An optimal algorithm for mutual exclusion in

computer networks, Commun. ACM 24 (1) (1981) 9–17.[19] Adi Shamir, How to share a secret, Commun. ACM 22 (11) (1979) 612–613.

[20] A. Shamir, R.L. Rivest, L.M. Adleman, Mental Poker, Technical Report MIT-LCS-TM-125, Massachusetts Institute of Technology, 1979.[21] I. Suzuki, T. Kasami, A distributed mutual exclusion algorithm, ACM Trans.

Comput. Syst. 3 (4) (1985) 344–349.[22] A.C. Yao, Protocols for secure computations, in: 23st Annual IEEE Sympo-

sium on Foundations of Computer Science, IEEE Computer Society, 1982,

pp. 160–164.

Giuseppe Ateniese is an Associate Professor of ComputerScience at Sapienza—University of Rome and JohnsHopkins University, USA (on leave of absence). He wasa researcher at IBM Zurich Research lab and a visitingscientist at the Information Sciences Institute of theUniversity of Souther California. During his stay at JHU,he briefly worked as a visiting professor at Microsoftin Redmond (USA). He received the US NSF CareerAward for his research in cryptography and network

security. He has contributed to areas such as proxyre-cryptography, anonymous communication, two-party

computation, secure storage, and provable data possession. He has served in theprogram committees of international conferences (such as ACM CCS, IEEE Oakland,and NDSS) and as panelist of the US National Science Foundation. He has recentlyreceived the Google Faculty Research Award and the IBM Faculty Award.

Roberto Baldoni isProfessor atthe University ofRome‘‘LaSapienza’’ where he leads the Distributed Systems groupand the MIDLABLaboratory. His research interestsincludedistributed computing,dependable and secure distributedsystems, distributed information systems and distributedevent based processing. His research at the University of Rome has been funded along the years by the EuropeanCommission, the Ministry of Italian Research, IBM, Mi-crosoft, Finmeccanica and Telecom Italia. In 2010, he re-ceived the Science2business Award and the IBM Faculty

Award. He is the author of around 150 research papersfrom theory to practice of distributed systems. He belongs to the Steering Com-mittee of ACM DEBS that he chaired in 2008 and he is a member of ACM, IEEE andof the IFIP WG 10.4.

Silvia Bonomi is a Ph.D. in Computer Science at theUniversity of Rome La Sapienza. She is doing researchon various computer science fields including dynamicdistributed systems and event-based systems. In theseresearch fields, she published several papers in peerreviewed scientific forums. As a part of the MIDLABresearch group, she is currently involved in an EU-fundedproject dealing with energy saving in private and publicbuildings (GreenerBuildings project) and she workedon dependable distributed systems (ReSIST network of excellence)and onthe definition ofnew semantic toolsfor

e-Government (SemanticGov).

Giuseppe Antonio Di Luna is a Ph.D. student at the‘‘Dipartimento di Ingegneria Informatica Automatica eGestionale—A. Ruberti’’ at the Sapienza University of Rome. He is currently working on security related aspectsof distributing computing like privacy preserving algo-rithms and detection of distributed attacks.
http://refhub.elsevier.com/S0743-7315(14)00036-7/sbref1http://refhub.elsevier.com/S0743-7315(14)00036-7/sbref1http://refhub.elsevier.com/S0743-7315(14)00036-7/sbref1http://refhub.elsevier.com/S0743-7315(14)00036-7/sbref2http://refhub.elsevier.com/S0743-7315(14)00036-7/sbref2http://refhub.elsevier.com/S0743-7315(14)00036-7/sbref2http://refhub.elsevier.com/S0743-7315(14)00036-7/sbref2http://refhub.elsevier.com/S0743-7315(14)00036-7/sbref2http://refhub.elsevier.com/S0743-7315(14)00036-7/sbref2http://refhub.elsevier.com/S0743-7315(14)00036-7/sbref2http://refhub.elsevier.com/S0743-7315(14)00036-7/sbref3http://refhub.elsevier.com/S0743-7315(14)00036-7/sbref3http://refhub.elsevier.com/S0743-7315(14)00036-7/sbref4http://refhub.elsevier.com/S0743-7315(14)00036-7/sbref4http://refhub.elsevier.com/S0743-7315(14)00036-7/sbref5http://refhub.elsevier.com/S0743-7315(14)00036-7/sbref5http://refhub.elsevier.com/S0743-7315(14)00036-7/sbref5http://refhub.elsevier.com/S0743-7315(14)00036-7/sbref5http://dx.doi.org/10.1007/BFb0054851http://dx.doi.org/10.1007/BFb0054851http://refhub.elsevier.com/S0743-7315(14)00036-7/sbref8http://refhub.elsevier.com/S0743-7315(14)00036-7/sbref8http://refhub.elsevier.com/S0743-7315(14)00036-7/sbref8http://refhub.elsevier.com/S0743-7315(14)00036-7/sbref8http://refhub.elsevier.com/S0743-7315(14)00036-7/sbref9http://refhub.elsevier.com/S0743-7315(

ateniese et al. - 2014 - fault-tolerant oblivious assignment with m slots in synchronous systems

Documents