 Research
 Open Access
Providing privacy on the tuple space model
 Edson Floriano^{1},
 Eduardo Alchieri^{1}Email authorView ORCID ID profile,
 Diego F. Aranha^{2} and
 Priscila Solis^{1}
https://doi.org/10.1186/s1317401700703
© The Author(s) 2017
Received: 6 September 2017
Accepted: 22 November 2017
Published: 20 December 2017
Abstract
Conceptually, tuple spaces are shared memory objects that provide operations to store and retrieve ordered sets of data, called tuples. Tuples stored in a tuple space are accessed by the contents of their fields, working as an associative memory. Although there are some proposals for secure tuple spaces, accessing tuples through field contents makes these systems susceptible to attacks that could impair user and data privacy, since servers must access tuple data. In order to deal with these limitations and provide privacy in the tuple space model, this paper proposes some extensions to DepSpace, a tuple space system that implements dependability and security properties through a set of mechanisms that are not enough to ensure privacy. The resulting system provides privacy and, at the same time, allows tuple selection/matches similar to the traditional insecure model, i.e., it does not constraint the matching possibilities. The main problem to be addressed is that servers must select tuples based on their contents without knowing them. The proposed solution uses robust cryptographic schemes, as orderpreserving encryption and homomorphic encryption, to provide this functionality without revealing the tuple contents. An analysis concerning security aspects of DepSpace is presented, as well as the benefits of the proposed solutions. A set of experiments, executed with an implementation of the proposed protocols, shows the feasibility of the proposed solutions and shed some light on both the behavior of the system and the costs to provide privacy in the tuple spaces model.
Keywords
1 Introduction
The distributed computing community has given a lot of attention to the security issues on the design and development of distributed applications. A system is secure if it satisfies the confidentiality, availability and integrity properties [1]. Furthermore, one can intuitively understand privacy, under the perspective of some entity, as the confidentiality of its sensitive information (data and metadata) [2]. This entity may be a person, an organization, a nation, etc. Therefore, privacy is closely connected to the confidentiality of information.
Currently, there are many factors that increase the risk related to the security of applications [2]: (i) the world is becoming a huge infrastructure, interconnected and interdependent; (ii) there are massive amounts of correlated data available; (iii) the entities are exposing themselves much more; and (iv) the number of software vulnerabilities is increasing.
In face of this scenario, many systems aim to provide information confidentiality by protecting only the secret data itself, without any care of the correlated nonconfidential data. However, statistical inference attacks [3] often are able to recover secret information from the analyses and correlation of public available data. Consequently, it becomes interesting, if not mandatory, to develop solutions and provide means to protect all information handled by secure applications.
These aspects are particularly relevant when we consider data shared through a tuple space [4, 5], since in this model the accesses are done by the tuple contents, working as an associative memory. As examples of distributed systems that could benefit from a secure tuple space, it is possible to mention either highlevel applications such as secure biddings [6], and applications that need a distributed shared memory [6, 7] or synchronization building blocks as shared counters and distributed lists [8].
Although there are some proposals to secure tuple spaces [5, 8–11], the fact that the tuples are accessed by their contents makes these systems susceptible to attacks that could impair the privacy of the data and, consequently, of their users. The main problem to be addressed in order to provide privacy in this model is that servers must select tuples based on their contents without knowing them.
Among the existent proposals, DEPSPACE [5] is the system that provides the higher security level, employing both access control and cryptographic mechanisms. This system suggests the classification of the tuple fields as follows: public – the data is public and all parties/processes can access it; comparable – a hash of the field content is available, consequently, if the range of values that a field can take is known and limited, then a preimage attack can disclose its contents; and private – no information is available. Given this classification, at least one field of each tuple needs to be public or comparable to allow tuple accesses, i.e., to allow servers to execute matches among tuples and templates (Section 2). This approach, although adequate since it provides some level of confidentiality, brings a big challenge to the development of applications: if a lot of public and/or comparable fields are used, then the system becomes vulnerable to correlation, preimage and collision attacks; otherwise, as servers are not able to execute searches/matches in private fields, the tuple searches/matches possibilities are significantly reduced, limiting its use in the development of distributed applications.
In order to circumvent these problems, this paper proposes extensions to the DEPSPACE field classification to prevent that the privacy of data and users are breached by attackers. Through the use of robust and modern cryptographic mechanisms, the proposed extensions preserve the security properties and, at the same time, allows more flexibility in the execution of tuples searches/matches. Moreover, this paper presents an analysis about the security provided by DEPSPACE, as well as about the resulting system after the inclusion of the proposed solutions.

It increases the security provided by DepSpace, mainly privacy, by proposing new field classification that uses robust cryptographic schemes and, consequently, reduces (and even eliminates) the need for public or comparable fields. Additionally, the proposed new fields bring more flexibility in the execution of tuples searches/matches since they use searchable encryption schemes.

It presents an analysis of the security provided by DepSpace prior and after the inclusion of the proposed solutions.

It analyzes, through a set of experiments, the impact on the system performance caused by the suggested extensions.

It discusses some relevant aspects around such extensions, like other implementation possibilities and current limitations.
The remainder of this paper is organized as follows. Section 2 details the concept of tuple space and introduces DEPSPACE, analyzing the security properties provided by this system. Section 3 discusses robust cryptographic schemes that are used in the proposed extensions, which are presented at Section 4. Section 5 discusses the integration of the proposed solutions within DEPSPACE. An experimental evaluation about the proposed solutions is presented at Section 6. Section 7 brings some important discussions about the proposed solutions. The related works are discussed at Section 8. Finally, conclusions and future work are given in Section 9.
2 Tuple space
Conceptually, a tuple space can be seen as a shared memory object that provides operations to store and to retrieve ordered data sets, called tuples. Processes in a distributed system can then interact through this shared memory abstraction. A tuple is an ordered sequence of fields, where a field that contains a value is said to be defined. A tuple t where all the fields are defined is called entry (or tuple). A tuple \(\overline {t}\) is called template if any of its fields does not have a defined value. A tuple t and a template \(\overline {t}\) combine (or match) if, and only if, both has the same numbers of fields and all the values and types of the defined fields in \(\overline {t}\) are identical to the values and types of the corresponding fields in t. For example, a tuple 〈JISA,2017,SBC〉 combines/matches with the template 〈JISA,∗,∗〉 (’ ∗’ denotes a undefined field, called wildcard).
Process coordination through tuple spaces, introduced by the programming language LINDA for parallel systems [4], supports decoupled communications in space (processes do not need to know each other locations) and in time (processes do not need to be active at the same time). Besides that, this model of coordination provides some synchronization power.
Manipulations performed in tuple spaces consist in invocations of three basic operations [4]: out(t) that stores the tuple t in the space; \(in(\overline {t})\), that removes from the space a tuple that matches the template \(\overline {t}\); \(rd(\overline {t})\), used to read from the space a tuple that matches the template \(\overline {t}\), without removing it. Operations in and rd are blocking, i.e., if there is no tuple that matches the template in the space, the process gets blocked until one is available. A common extension to this model is the inclusion of nonblocking variants of these operations, denominated inpn and rdp. These operations work exactly like the previously, except by the fact that they return even if there is not a tuple that matches the template (indicating its nonexistence).
Another operation implemented in some tuple spaces (e.g., DEPSPACE [5]) is the \(cas(\overline {t}){t}\) (conditional atomic swap) [12, 13]. This operation works like an atomic execution of the code: if \(\neg \ rdp(\overline {t})\) then out(t) (\(\overline {t}\) is a template and t an entry/tuple). The operation inserts t in the space iff \(rdp(\overline {t})\) does not return any tuple, i.e., if there is no tuple in the space that matches \(\overline {t}\); otherwise it returns a tuple that matches \(\overline {t}\).
2.1 DEPSPACE: A BFT coordination system
The DEPSPACE [5] system provides a Byzantine FaultTolerant (BFT) [14] coordination service based on the tuple space model. The following security and dependability attributes (or properties) are necessary for this model [1]: (1) reliability – the operations executed in the tuple space change its state according to their specification; (2) availability – the tuple space is always ready to execute the operations required by authorized parties; (3) integrity – no improper alteration of the tuple space can occur; (4) confidentiality – the content of tuple fields cannot be disclosed to unauthorized parties. With the goal of ensure these properties, DEPSPACE is built over a set of layers, each one responsible for the execution of a different functionality.
2.1.1 DEPSPACE layers
Replication. To maintain consistency in the tuple space, DEPSPACE utilizes State Machine Replication [15, 16] as the bottom layer. This mechanism is related mainly with the properties of availability, integrity and confidentiality. Considering a system with n replicas/servers, it ensures that operations are executed according to their specification even if up to f=(n−1)/3 replicas are malicious (the correct replicas mask the behavior of the malicious ones). Through these protocols, the correct replicas execute the same sequence of operations and returns the same values, evolving in a synchronized way.
Confidentiality. Since tuples are maintained replicated in a set of servers, the provision of confidentiality (and privacy) must not be attributed to a single server because up to f of them could fail and expose the tuple contents to unauthorized parties.
Consequently, DEPSPACE implements confidentiality through the use of a (n,f+1)Publicly Verifiable Secret Sharing (PVSS) [15] scheme. The clients, which represent the dealers in the scheme, generate a secret that they use to encrypt the tuples. Later, they generate a set of n shares of this secret and one different share is sent to each server. The secret can be recovered only with a combination of f+1 shares, what makes it impossible for a collusion of up to f malicious servers to expose the tuple contents.

Public (PU): the field content itself is used as its fingerprint, i.e, no cryptographic method is applied to the field content and it remains exposed.

Comparable (CO): a hash of the field content is used as its fingerprint (using a collision resistant hash function), allowing servers to execute searches/matches in these type of fields while, at the same time, providing some level of security.

Private (PR): a special symbol (PR) is used as fingerprint of these fields. Although it provides a level of security higher than the CO classification, no information in this field is available at the servers to verify if a tuple matches a template.
Once it is not possible to send different versions of a request for different servers in the state machine replication approach (containing only its share of the secret used to encrypt the tuple), the client encrypts each share with a secret key shared with the server that will store it. Consequently, each server will access only its share and, as a malicious server does not have access to all shares, it can not restore and expose the tuples contents.

The client generates a secret s and encrypts the tuple using this secret.

The client uses the PVSS scheme to generate n shares of s.

The client encrypts each share with a secret key shared with each server (one share per server).

The client computes the fingerprint according to the fields classification.

The client uses the state machine replication protocol to send a request to the servers (in this protocol it must wait for f+1 replies to finish the request execution). The request contains the encrypted tuple, the encrypted shares, the proof that these shares are valid and the tuple fingerprint.

When a server executes this request, it only stores all received data and sends an acknowledge to the client as a reply.

The client computes the fingerprint for the template according to the field classification. The fingerprint of a undefined field is the wildcard itself.

The client uses the state machine replication protocol to send a read/remove operation to the servers containing the generated fingerprint.

When a server executes this request, it chooses a tuple deterministically such that its fingerprint matches the received fingerprint (if it is a removal operation, this tuple is removed from the space). In case its share was not yet verified, it extracts its share and verify if this share is valid using the proofs received during the out operation. Afterward, the server replies to the client with the encrypted tuple, its encrypted share (to avoid eavesdropping on the replies), the tuple fingerprint and proofs that the share is valid.

The client waits for f+1 replies, decrypts the shares, verifies their validity and combines them to recover the secret s. Finally, the client decrypts the tuple using s.

The client verifies if the fingerprint it used is valid for the recovered tuple. If the fingerprint is valid, the operation is finished. Otherwise, a repair procedure is executed to remove invalid data from the space and the operation is repeated.
Notice that, according to the fingerprint definitions, searches are possible only in public and comparable fields, i.e., private fields cannot be used to verify if a tuple matches a template and are always used as undefined fields on the template. This limitation brings at least two consequences. On the one hand, a tuple with many private fields makes the search very restricted, losing the flexibility in the development of applications because a template with many undefined fields does not allow a finegrained match at the servers. On the other hand, a tuple with many public and/or comparable fields is susceptible to many attacks, like correlation and preimage attacks.
Policy enforcement. This layer allows a finegrained access policy execution [7] that takes into account three parameters (identifier of the invoker, operation and arguments, and the current tuples stored in the space) to decide if an operation is approved or denied. These policies are defined by the users and are loaded at the servers during the system setup.
Access control.
Access control is a fundamental mechanism to keep the integrity and confidentiality of information (tuples) stored in the DEPSPACE since it prevents unauthorized clients from getting access to the tuples. Moreover, this mechanism prevents malicious clients from saturating the tuple space by sending a lot of tuples. Currently, the DEPSPACE implements the access control based on credentials: for each tuple inserted in the DEPSPACE, a set of credentials are necessary to access it, both to read and to remove it from the space (access control at tuple level). These credentials are defined by the process that inserts the tuple. Moreover, it is possible to define which credentials are necessary to insert a tuple into the space (access control at space level) during its setup. The implementation of this functionality is realized through the association of access control lists to each tuple and space.
2.1.2 Security analysis

Ciphertextonly attack (COA): In this kind of attack, an adversary tries to obtain the decryption key or the plaintext only having the ciphertext at its disposal. This is the weaker type of attack and, therefore, a system vulnerable to this attack is considered insecure.

Knownplaintext attack (KPA): In this attack, the adversary has at its disposal a significant amount of plaintexts and their corresponding ciphertexts. Through the comparison of plaintexts and their corresponding ciphertexts, the adversary tries to discover the decryption key or to decrypt another ciphertext.

Chosenplaintext attack (CPA): the adversary chooses a plaintext and receives the corresponding ciphertext for analysis, which may allow him/her o discover the plaintext corresponding to another ciphertext.

Adaptive chosenplaintext attack (CPA2): This attack is similar to CPA, however the attacker can choose new plaintexts depending on the received answer.

Chosenciphertext attack (CCA) In this kind of attack, the adversary chooses a ciphertext and receives (without access to the decryption key) the corresponding plaintext. The adversary uses the analysis of this correlation to discover the plaintext corresponding to another ciphertext.

Adaptive chosenciphertext attack (CCA2): This attack is similar to the CCA, however the attacker can choose new ciphertexts depending on the received answer. This attack is considered very strong and much harder to implement.
The attacks above are presented in order of increasing complexity. A system vulnerable to a weak attack will be classified at a lower security level, even if it resists a stronger attack. Although these are the main attacks considered in the literature, many other attacks could be possible depending on the system characteristics. For example, in [3] the authors show that it is possible to perform inference attacks by means of correlation of the ciphertexts with additional public information. In this case, if there is a strong correlation between the encrypted and the public data, the plaintexts could be recovered with high accuracy. Considering encrypted databases of hospitals, [3] presented a study in which more than 60% of the data deterministically (Section 3.1) encrypted (e.g.: sex, race and mortality risk) could be discovered in 60% of the hospitals, while more than 80% of data encrypted with order preserving (Section 3.2) encryption (e.g.: age and disease severity level) were recovered in 95% of the hospitals.

Indistinguishability against chosenplaintext attacks (INDCPA): the cipher offers INDCPA if for all attempts i=1,2,...q, given two messages \(m_{i0}, m_{i1}\in \mathcal {M}\) of the same size, chosen by \(\mathcal {A}\) and submitted to an oracle that answers with the ciphertext \(c_{i}=E(k, m_{ib}) \in \mathcal {C}\) for some key k selected randomly in \(\mathcal {K}\) and b∈{0,1}, the probability that \(\mathcal {A}\) can distinguish between c _{ i }=E(k,m _{ i0}) or c _{ i }=E(k,m _{ i1}) is negligible.

Indistinguishability against chosenciphertext attacks (INDCCA): the cipher offers INDCCA if, for the same conditions of the INDCPA, the adversary \(\mathcal {A}\) also can get access to a oracle that given a ciphertext c _{ i }∉{c _{1},...,c _{ i−1}} answers with the corresponding plaintext m _{ i }=D(k,c _{ i }) and, in the same way, the probability that \(\mathcal {A}\) can distinguish between c _{ i }=E(k,m _{ i0}) or c _{ i }=E(k,m _{ i1}) is negligible. In this case, \(\mathcal {A}\) can make as many requests as it wants to the decryption oracle, however only until it has received the challenge ciphertext from the encryption oracle.

Indistinguishability against adaptive chosenciphertext attacks (INDCCA2): the cipher offers INDCCA2 if, besides the conditions established to the INDCCA, the adversary can continue using the decryption oracle even after it had received the challenge cryptogram. The only restriction is that it is not allowed to submit this cryptogram for decryption.

Indistinguishability against distinct chosenplaintext attacks (INDDCPA): the cipher \(\mathcal {E}\) offers INDDCPA if it is deterministic and for all attempts i=1,2,...,q, given two messages \(m_{i0}, m_{i1}\in \mathcal {M}\) of the same size chosen by \(\mathcal {A}\), distinct for each attempt (∀i,j∈{1,2,...,q},m _{ i0}≠m _{ j0} and m _{ i1}≠m _{ j1}), submitted to the oracle that answers with the ciphertext \(c_{i}=E(k, m_{ib}) \in \mathcal {C}\) for some key k selected randomly in \(\mathcal {K}\) and b∈{0,1}, the probability that \(\mathcal {A}\) can distinguish between c _{ i }=E(k,m _{ i0}) or c _{ i }=E(k,m _{ i1}) is negligible [19].

Indistinguishability against ordered chosenplaintext attacks(INDOCPA): the cipher \(\mathcal {E}\) offers INDOCPA if it preserves the order between the plaintexts and for all attempts i=1,2,...,q, given two messages \(m_{i0}, m_{i1}\in \mathcal {M}\) of the same size, chosen by \(\mathcal {A}\) and submitted always in the same order (i.e., m _{ i0}<m _{ j0} ⇔ m _{ i1}<m _{ j1} for all 1≤i,j≤q) to an oracle that answers with the ciphertext \(c_{i}=E(k, m_{ib}) \in \mathcal {C}\) for any key k selected randomly in \(\mathcal {K}\) and b∈{0,1}, the probability that \(\mathcal {A}\) can distinguish between c _{ i }=E(k,m _{ i0}) or c _{ i }=E(k,m _{ i1}) is negligible [20].

Comparable fields allow tuple selection/matches without servers knowing the field contents, but the use of hash functions makes the system vulnerable to collision and preimage attacks. In fact, an adversary is able to get a desired amount of inputs and their respective outputs by calculating their hashes. Consequently, if the set of values that a comparable field could assume is small and known, then the attacker can calculate the hashes for all possible values, learning the correspondence between plaintexts and ciphertexts. This attack is similar to the knownplaintext attack, except for the fact that in this case there is no encryption and decryption functions.

Public fields are not subject to a disclosure attack since their contents are already public. However, these fields could provide useful information to an attacker, which could correlate the encrypted tuple contents with a public database and execute an inference attack. Comparable fields also could be used for these attacks since their contents could be inferred.
3 Robust cryptographic schemes
In order to circumvent the aforementioned limitations and vulnerabilities, this section introduces some robust cryptographic schemes that allow searches and computations over encrypted data. These schemes were used to improve DEPSPACE security. Based on its characteristics, mainly the way fingerprints work, we looked for cryptography schemes that best fit this system.
3.1 Deterministic and probabilistic ciphers
A cipher \(\mathcal {E}=(E,D)\) defined over \((\mathcal {K}, \mathcal {M}, \mathcal {C})\) is called probabilistic if, for a fixed key \(k\in \mathcal {K}\) and messages \(m\in \mathcal {M}\) that are used as inputs of the encrypt function \(E: \mathcal {K}\times \mathcal {M}\to \mathcal {C}\), the output c=E(k,m) may assume different values. Otherwise, the cipher is said to be deterministic [18].
Naturally, an inherent characteristic of deterministic ciphers is the leakage of equality of texts encrypted under the same key, that is, m _{0}=m _{1} ⇔ E(k,m _{0})=E(k,m _{1}). This fact could be used to perform equality searches over encrypted data [21, 22]. Clearly, this kind of cipher does not achieve security against the ChosenPlaintext Attack (CPA) since an adversary may submit in the beginning two copies of the same message m _{0} to the oracle and receive two identical ciphertexts c _{0}=E(k,m _{0}). Afterwards, the attacker could send the messages m _{0} and m _{1} to the oracle, receiving c _{ b }=E(k,m _{ b }), where b∈{0,1}. Now, it is enough to compare c _{ b } (b∈{0,1}) with c _{0} to know if it is E(k,m _{0}) or E(k,m _{1}).
Probabilistic ciphers can resist stronger attacks, achieving the INDCCA2 security level when combined with authentication primitives.
3.2 Orderpreserving encryption  OPE
A symmetric orderpreserving cryptography scheme preserves the order relation among the encrypted values [20]: for all i and j and for all keys k, E(k,i)<E(k,j) ⇔ i<j. This kind of cipher leaks the order among plaintexts through the ciphertexts, therefore not achieving the INDCPA security level. Observing that this security level is not achievable by a deterministic algorithm with such property, even considering a weak security level (INDOCPA), applying pseudorandom generators and functions (PRF’s and PRG’s) was proposed [20]. This approach provides a flexible (but strong) level of security called pseudorandom orderpreserving function under chosenciphertext attack (POPFCCA).
However, this security definition does not determine what kind of data could leak, besides the order. In [23], Order Revealing Encryption (ORE) is proposed, a construction that minimizes the amount of leaked data. Although this approach presents a higher level of security, it is impractical since the initial proposal presents poor performance. Trying to circumvent this limitation, a practical ORE algorithm [24] was proposed. This algorithm achieves the INDOCPA security level since it could leak only the first bit that differs in the compared values. Finally, an ORE algorithm that resists inference attacks [25] was proposed and presents a good performance for encrypted database applications [22].
3.3 Homomorphic encryption
Homomorphic encryption [26] allows computations over encrypted data without decrypting them and without the knowledge of the secret keys. Given any two messages, m _{1} and m _{2}, a homomorphic encryption function E and a key k, we have that E(k,m _{1})∘_{ c } E(k,m _{2})=E(k,m _{1}∘_{ m } m _{2}), where ∘_{ m } denotes an arithmetic operation on the message domain and ∘_{ c } denotes an arithmetic operation on the ciphertext domain.
Fully homomorphic systems generally present poor performance and are not practical in the development of applications. However, it is possible to avoid the performance issues of fully homomorphic schemes while preserving some of their functionality, since many applications need only some kind of operations, what can be done by a “somewhat” homomorphic scheme [27]. These schemes present a better performance and are practical. Paillier [28] and exponential ElGamal [29] are examples of efficient “somewhat” homomorphic ciphers. These schemes are also probabilistic, achieving the INDCPA security level.
4 Providing privacy on DEPSPACE
This section presents our proposal to increase security of the DEPSPACE system. In a nutshell, new types for field classifications are introduced, which use the previously discussed robust cryptographic schemes to provide the same functionality as the originally proposed DEPSPACE (or even bringing more flexibility to the development of applications since these fields allow the implementation of previously impossible secure searches), however, with stronger security properties.
Before presenting the new field classifications, let us introduce another very important characteristic of DEPSPACE. This system uses a (n, f+1)PVSS scheme [15] to split a secret key, that is used to encrypt some tuple (Section 2.1), among n servers, requiring f+1 of them to recover the secret key. This approach works fine since at most f malicious servers are supposed in the system. However, to avoid such compromise, these keys must be known only to the clients, that must previously share it utilizing a publickey cryptographic algorithm with a mechanism that provides public key verification and protection against “maninthemiddle” attacks [30]. Independent groups of processes that must communicate through the space can have a different shared key. This protocol is orthogonal to the way fingerprints work in DEPSPACE, which is the focus of this paper.
4.1 Improving fingerprint security

Comparable deterministic (CD): the field content f is encrypted through a deterministic symmetric encryption algorithm by using a function encryptCD(key _{ shared },f). The resulting ciphertext is used as fingerprint and, as the algorithm is deterministic, it allows servers to execute searches/matches in these fields. Notice the same key is used to decrypt these fields.

Operable (OP): the field content f is encrypted through a homomorphic or “somewhat” homomorphic asymmetric encryption algorithm by using a function encryptOP(key _{ public },f). The resulting ciphertext is used as fingerprint and allows computations at the servers. Notice that this scheme is asymmetric: the public key is used for encryption and computations over f; the private key is used to decrypt the result.

Orderly (OR): the field content f is encrypted through an orderpreserving symmetric encryption algorithm, as OPE, by using a function encryptOR(key _{ shared },f). The resulting ciphertext is used as fingerprint, allowing the execution of matches and the ordering among these fields. Notice the same key is used to decrypt these fields.
The new field classification brings a key management issue since it is necessary to share a secret key for CD and OR fields or a key pair (public and private) for OP fields. These keys must be shared among the processes that are communicating through the tuple space. For OP fields, the public key also is available to the servers allowing they to execute computations over these fields. Fortunately, key management is not a problem in our model since the tuple space itself could be used for this coordination (Section 7.3).
CD fields. We strongly recommend the preference of CD fields over CO. By using a deterministic symmetric cipher instead of a hash value, an attacker would need to access the secret key to encrypt a field, making it impossible to mount a preimage attack (Section 2.1.2). However, the CD classification must be employed carefully since this cipher reveals if plaintexts are equal. Consequently, if the field content belongs to a small domain, using few external information is enough to disclose it. For instance, consider the encryption of a field that contains the sex in a database that is known to have more men than women. An attacker could observe that there are only two possible ciphertexts and conclude that the one with more occurrences refers to the male sex. Therefore, this cipher should be used for fields that store indexes, with a high amount of possible values, and for nonsensitive data like identifiers, email address, name of process nodes, among others.
Some cryptographic algorithms use operation modes with randomized initialization vectors (IV), in the form c=E(k,m,IV), as a way to provide probabilistic encryption. To provide deterministic encryption, these algorithms usually fix the IV (e.g. in zero). In these cases, we recommend the use of a PRF (pseudo random function) over the message m by using a key k _{1}, producing a pseudorandom output r=F(k _{1},m). The encryption function then uses r as IV and another key k _{2} to produce the encrypted output c=E(k _{2},m;r). Since the PRF generates the same output for the same message and key, the algorithm remains deterministic. Moreover, the PRF generates different outputs for different messages inputs (even under the same key) and, therefore, different IV’s are obtained for different messages, achieving the INDDCPA security level [18].
OP fields. OP fields allow the computation over encrypted data. For these fields, a homomorphic or a “somewhat” homomorphic cipher (Section 3.3) should be used, such as Paillier [28], according to the application requirements. These fields increase the functionality provided in DEPSPACE. For instance, it is possible to update values used to synchronize decoupled process without revealing process status.
If the field needs only one kind of arithmetic operations (e.g.: addition/subtraction or multiplication/division), a “somewhat” homomorphic cipher can be used to offer better performance than a fully homomorphic alternative.
Notice that all fingerprint fields are used only to select tuples, except for OP fields. In these cases, the updated value to be read is in the fingerprint, not in the decrypted tuple, and the client must consider this value during a reading/removal operation.
OR fields. This classification brings a lot of functionalities for the tuple spaces allowing servers to execute some operations, as (1) tuples ordering based on a field, (2) execution of queries for a field belonging to some range and (3) select a tuple with a field storing the maximum/minimum value. To execute these operations in the original DEPSPACE system, fields should be classified as PU, losing security. If they are classified as PR, clients need to read and decrypt all tuples prior to perform these operations. Allowing servers to execute such processing improves the system performance since fewer data are transferred through the network [8].
The OR fields must be chosen carefully since these fields are vulnerable to inference attacks if all possible values of a domain are present in the data collection [3]. For instance, if a tuple field refers to the age of patients in a hospital that is known to have patients of all ages from zero to 100 years old, then data could be revealed due to this association.
To overcome this vulnerability, we suggest the use of a composition of algorithms. First, encrypt the data with an OPE algorithm [20] and later use the output as input of an ORE algorithm [24]. By this approach the system achieves the INDOCPA security level, with the leakage of the first bit that differs in the compared values. The distance between OPE encrypted numbers is a random value and it does not have any connection with the distance of the original numbers. This is the reason for the first step since in this case the leaked bit is from the OPE encrypted number instead of the original number.
Security level for each field type
PU  CO  CD  OR  OP  PR 

Insecure  Preimage/collision  INDDCPA  INDOCPA^{a}  INDCPA  INDCCA2 
Finally, the security of a system depends on the correct use of each cipher, considering the characteristics of the data stored in each field. Keeping all data encrypted, it is possible to avoid inference attacks that could cause a big damage to applications using lower computational effort.
5 Implementation

Public (PU): no cryptography is used in these fields since their original contents are used in the fingerprint (plaintext).

Comparable (CO): to process these fields we used the SHA1 algorithm, which generates a hash output of 20 bytes.

Private (PR): no original field information is used in the fingerprint, only a special symbol PR indicating its classification.

Comparable Deterministic (CD): for these fields we used a HMACSHA256 (Hashbased Message Authentication Code with SHA256) algorithm and a secret key of 256 bits to generate an encrypted output of 32 bytes.

Operable (OP): for these fields we used the javallier library [31], a Java implementation of the Paillier algorithm [28]. This “somewhat” homomorphic encryption library implements the addition operation between two encrypted numbers, from which the subtraction can also be derived. Additionally, an encrypted number could be multiplied by a small plaintext number using repeated addition operations. For the asymmetric algorithm we used a key pair (public and private) of 512 bits.

Orderly (OR): for these fields we used the jope library [32], a Java implementation of an OPE algorithm [20]. We employed this library without the composition with a ORE algorithm (see Section 3.2). This library outputs a deterministic BigInteger that preserves exactly the same order than the non encrypted number, with pseudorandom distances between any two encrypted numbers. To perform inequality queries (e.g.: less than or greater than), we implemented at the proxy layer of the client side a detector to identify the presence of these queries and handle them in a way that the tuple space layer at the servers side can understand, i.e, the tuple space layer was modified to perform matches using these queries. For instance, a tuple field containing the number 10 matches a template field containing a query “less than 11”. The current supported queries are: lt (less than), le (less than or equal to), eq (equal to), gt (greater than), and ge (greater than or equal to).
Considering the previously example, the OR tuple field contains the encrypted number 10 while the OR template field contains a query lt(11) (less than 11).
6 Experimental evaluation
In order to assess the performance of the proposed solutions and better understand the costs to provide privacy in the tuple space model, we conducted some experiments with the previously described implementation in Emulab [33].
6.1 Experimental setup
The Emulab environment was configured with 5 d710 machines (2.4 GHz 64bit Intel Quad Core Xeon E5530 with 2 CPU threads per core, 12 GB of RAM and 1 Gbps network cards) and a 1Gbps switched network. The software installed on the machines was Ubuntu 14 64bit and a 64bit Java virtual machine version 1.8.0_121. For all experiments, the system was configured with four replicas hosted in separate machines to tolerate up to one replica failure, while the clients were executed in the remaining machine.
We employed this library without the composition with a ORE algorithm (see Section 3.2). This library outputs a deterministic BigInteger that preserves exactly the same order than the non encrypted number, with pseudorandom distances between any two encrypted numbers. To perform inequality queries (e.g.: less than or greater than), we implemented at the proxy layer of the client side a detector to identify the presence of these queries and handle them in a way that the tuple space layer at the servers side can understand, i.e, the tuple space layer was modified to perform matches using these queries. For instance, a tuple field containing the number 10 matches a template field containing a query “less than 11”. The current supported queries are: lt (less than), le (less than or equal to), eq (equal to), gt (greater than), and ge (greater than or equal to).
For executing out operations, we used tuples with only defined fields for each configuration described above (e.g.: 〈1,2,3〉, 〈1,2,3,4,5〉 and 〈1,2,3,4,5,6〉). Notice these fields were protected according to their configuration (PU, CO, PR, CD, OP or OR). On the other hand, the templates used for rdp and inp operations were configured with one defined field while the remaining ones were configured as wildcards (e.g.: 〈1,∗,∗〉, 〈1,∗,∗,∗,∗〉 and 〈1,∗,∗,∗,∗,∗,∗〉), except for the configurations PR and OP in which all fields were configured as wildcards since it is not possible to execute matches in these fields (Section 7).
We evaluated the raw throughput of the system at the servers and the latency perceived at the clients in all configurations. To evaluate latency, we used one client to execute each operation 1000 times and obtained the 90th percentile and the average time discarding the 10% values with greater variance. On the other hand, to execute throughput experiments, we variated the number of clients (from one to ten) and measured the maximum throughput obtained in each configuration. In order to stress the servers, each client preprocessed 1000 requests (most of the cryptographic costs are at the client side) before sending them to the servers, that measured the throughput periodically at each 100 executed requests. Although the DepSpace does tolerates faults, all performance values were obtained in faultfree executions.
6.2 Results
Costs related to cryptographic processing necessary to (1) generate a fingerprint, (2) verify if a fingerprint is good for a tuple received from servers, (3) extract a operable field from the fingerprint and (4) execute a match at the servers
Fingerprint  Verify  Extract  Query/Match  

(\(\overline {av}\) / σ)  (\(\overline {av}\) / σ)  (\(\overline {av}\) / σ)  (\(\overline {av}\) / σ)  
PU  –  –  –  – 
CO  (0.003 / 0.0003)  (0.003 / 0.0003)  –  – 
PR  –  –  –  – 
CD  (0.033 / 0.0067)  (0.033 / 0.0067)  –  – 
OP  (0.619 / 0.0322)  –  (0.601 / 0.1064)  – 
OR  (375.091 / 2.3129)  (375.348 / 1.9041)  –  (0.001 / 0.0002) 
A configuration with fields PU or PR presented the best performance since no cryptographic operations is need to generate the fingerprint, followed by configurations CO and CD. Although more time is necessary to process the fingerprint for CD when compared to CO (Table 2), this fact does not impact its performance since it demands less than a millisecond to execute (0.033 ms). The configuration OP also presented an acceptable performance, although more time is necessary to process the fingerprint. On the other hand, the configuration OR presented poor performance since a lot of time was necessary to process the fingerprint.
Amount of data (in bytes) sent in a request/reply for each configuration and operation
OUT (request / reply)  RDP/INP (request / reply)  

3 fields  5 fields  7 fields  3 fields  5 fields  7 fields  
PU  (874 / 133)  (917 / 133)  (951 / 133)  (364 / 1081)  (386 / 1122)  (408 / 1156) 
CO  (937 / 133)  (1064 / 133)  (1195 / 133)  (336 / 1147)  (358 / 1269)  (380 / 1405) 
PR  (794 / 133)  (831 / 133)  (859 / 133)  (288 / 996)  (310 / 1038)  (332 / 1072) 
CD  (1144 / 133)  (1399 / 133)  (1665 / 133)  (403 / 1342)  (425 / 1610)  (447 / 1868) 
OP  (1763 / 133)  (2433 / 133)  (3113 / 133)  (288 / 1969)  (310 / 2640)  (332 / 3324) 
OR  (825 / 133)  (866 / 133)  (916 / 133)  (297 / 1026)  (319 / 1081)  (341 / 1124) 
Another very important aspect is that most of the cryptographic costs are executed at the client side, i.e., the costs reported at columns fingerprint, verify and extract of Table 2. Only the query/match (last column of Table 2) for OR fields are executed by the servers during the search for a tuple which has a fingerprint that matches the fingerprint of the template in a read or removal operation. Moreover, most of the costs related to the execution of the PVSS scheme also are placed at the client side [5]. This is important because it shows that it is possible to have a tuple space that ensures the privacy of the information it stores and, at the same time, is scalable. Consequently, although these costs impact the latency, it is not expected to have a significant impact on the system throughput.
Another important aspect to be observed in the experiments is that the number of fields in a tuple does not significantly impacted the system performance for both latency and throughput. In fact, for all configurations and operations, the performance for 3, 5, and 7 fields are similar, except for the OR fields since they demanded much more time to generate the fingerprint (Table 2).
7 Discussions
This section presents some important discussions about some aspects of the proposed solutions.
7.1 (Im)possibility of combinations of fields types

OR type also provides a deterministic encryption and could be used as CD or CO, i.e., it allows equality match queries.

CO and CD provide the same functionality but with different security levels.

PU type provides all functionalities, but it is insecure.

OP fields are not deterministic since they use an asymmetric randomized algorithm and, therefore, each encryption of the same number with the same key may produce different results. Consequently, it does not provide the functionalities of CD or CO.

OP is the only secure field that allows computation.

OR is the only secure field that allows ordering.

PR type presents the best security level, but does not provide any functionality.
7.2 State machine replication vs. operable fields

Firstly, when decrypted after a reading/removal operation, the OP fingerprint field may not match the corresponding OP tuple field. Consequently, during this verification (Section 2.1), OP fields are always considered valid. Moreover, the value in the tuple field should be replaced by the updated value in the fingerprint field.

Secondly, and more critical, during the State Machine Replication (SMR) protocols execution at the client [16, 34], the replies received from the servers may be different since the OP fields use a nondeterministic algorithm. In fact, the cryptograms resulting from some computation at the servers may differ among them, although they refer to the same decrypted value. These aspects impact the SMR protocols, which require f+1 identical replies to terminate by returning some of these replies. In order to circumvent this problem, it is necessary to decrypt the OP fields prior to count the number of received replies.
7.3 Key management

Each client c generates a secret key k and defines a tuple t=〈secret_key,k〉 and a template \(\overline {t} = \langle secret\_key, * \rangle \), both defined as 〈 PU, PR 〉 (first field is public and the second is private).

Later, c invokes a \(cas(\overline {t},t)\) operation. If it returns null, then c uses k as a shared secret key since no other previous defined secret key was inserted into the space. Otherwise, the operation returns a tuple t ^{′}=〈secret_key,k ^{′}〉 read from the space and c uses k ^{′} as the shared secret key.
The protocol to exchange a key pair (OP fields) is very similar, the only difference is that the client should create a tuple t=〈OP_keys,k _{ pub },k _{ priv }〉 and a template \(\overline {t} = \langle OP\_keys, *, * \rangle \) in the first step, both defined as 〈 PU, PU, PR 〉.
Finally, the DEPSPACE access control subsystem must be used and it is enough to ensure that only the group of communicating processes is allowed to access the tuples storing the keys (notice that is is possible to use different keys for different fields). To remove some process from the group, the key must be redefined and shared with the appropriated access control configuration, as previously described. Notice that all tuples/fingerprints generated through the old key need to be replaced by another that uses the new key. On the other hand, the addition of some process in the group is straightforward since a new tuple with the same key but with appropriated access control configuration (including the new process) must be inserted into the space and the joining process only needs to read it from the space.
7.4 Alternatives for fingerprint implementation

Increasing the system security level.

CD fields: it is possible to improve the security level provided in or implementation for CD fields to achieve the level reported in Table 1 in the following way. First, use the tuple field as input of a HMACSHA256 function under the first 16 bytes of a secret key of 256 bits, generating the IV (initialization vector). After, apply the native Java AES CBC mode encryption over the tuple field using the second half of the secret key and the computed IV.

OR fields: we used a OPE algorithm alone for OR fields, but it is possible to use it in conjunction with an ORE algorithm to meet the security level reported in Table 1.


Improving system performance: our implementation for OR fields presented a poor performance because it is based on hypergeometric distribution functions, which present high computational costs. This is a natural candidate to be replaced by another cipher with the same functionality.
8 Related works
Comparison among tuple spaces approaches
Replication  Transaction  Access control  Confidentiality  Allows operations and searches over encrypted data  

TSpaces [35]  \(\mathcal {X}\)  √  \(\mathcal {X}\)  \(\mathcal {X}\)  \(\mathcal {X}\) 
JavaSpaces [36]  \(\mathcal {X}\)  √  \(\mathcal {X}\)  \(\mathcal {X}\)  \(\mathcal {X}\) 
GigaSpaces [37]  \(\mathcal {X}\)  √  \(\mathcal {X}\)  \(\mathcal {X}\)  \(\mathcal {X}\) 
FTLinda [12]  √  \(\mathcal {X}\)  \(\mathcal {X}\)  \(\mathcal {X}\)  \(\mathcal {X}\) 
ParallelLinda [38]  √  \(\mathcal {X}\)  \(\mathcal {X}\)  \(\mathcal {X}\)  \(\mathcal {X}\) 
SecSpaces [10]  \(\mathcal {X}\)  \(\mathcal {X}\)  √  \(\mathcal {X}\)  \(\mathcal {X}\) 
KLAIM [9]  \(\mathcal {X}\)  \(\mathcal {X}\)  √  \(\mathcal {X}\)  \(\mathcal {X}\) 
SECOS [11]  \(\mathcal {X}\)  \(\mathcal {X}\)  √  \(\mathcal {X}\)  \(\mathcal {X}\) 
DepSpace [5]  √  \(\mathcal {X}\)  √  √  \(\mathcal {X}\) 
DepSpace+this paper solutions  √  \(\mathcal {X}\)  √  √  √ 
Stronger and robust cryptographic mechanisms were used in the database context aiming to provide confidentiality and protection against information leakage through the processing of queries over encrypted databases [21, 22]. In these works, different cryptography schemes are used in the same application according to the specificity of the data to be stored and the expected queries to be executed over these data (e.g.: equality, comparison and words occurrence in texts). Homomorphic encrypted data, for instance, can accept UPDATE operations without been decrypted. In the same way, OPE and ORE ciphers are used to perform comparison queries, like ≤ or ≥, with a good performance/security tradeoff. Our proposal for new field classification employs these cryptographic mechanisms aiming to mitigate the security problems for applications that use the tuple space programming paradigm.
In CryptDB [21] and related works, such as the framework for searching encrypted databases [22], the performance decreases with the use of cryptographic functions, being more substantial when increasing either the number of client or database sizes. In the proposed system, the server side is not significantly impacted with the execution of cryptographic functions since the heavy cryptographic processing occurs at the client side (Table 2).
9 Conclusions and future work
This paper reports on our efforts to provide privacy in the tuple spaces model by applying robust cryptographic schemes. The main challenge in this model is that tuples are accessed by their contents (associative memory), being necessary to supply some information about them to allow servers to select tuples that match templates. To overcome this problem, this paper proposes the use of robust cryptographic schemes that allow both computations and definition of an order over encrypted data. A set of experiments illustrated the costs related to the proposed solutions.
As future work we intend to investigate the performance of other robust cryptographic libraries that provide the same security level and characteristics of these used in the first implementation. Additionally, we intend to develop a application that uses all the computation power provided by our solution and some secure extensible distributed coordination services, like shared counters, distributed queues and distributed barriers.
Declarations
Acknowledgements
We would like to thank the universities involved for the support provided. We also thank the many contributions from the reviewers.
Funding
Not applicable.
Availability of data and materials
Not applicable.
Authors’ contributions
EF is a student at PPGInf/CIC/UnB and has conducted the analysis about the security of DepSpace and proposed the new fields classifications and implementations. Prof. EA is the advisor of EF and helped mainly in the definitions of the proposals and in the implementations and experiments. Prof. DA is coadvisor of EF and, together with Prof. PS, worked mainly in the security aspects of the work. Moreover, all authors participated in all discussions and in the written phase of the final text. All authors read and approved the final manuscript.
Ethics approval and consent to participate
Not applicable.
Consent for publication
All authors agree to the submitted version.
Competing interests
The authors declare that they have no competing interests.
Publisher’s Note
Springer Nature remains neutral with regard to jurisdictional claims in published maps and institutional affiliations.
Open Access This article is distributed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits unrestricted use, distribution, and reproduction in any medium, provided you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license, and indicate if changes were made.
Authors’ Affiliations
References
 Avizienis A, Laprie JC, Randell B, Landwehr C. Basic concepts and taxonomy of dependable and secure computing. IEEE Trans Dependable Secure Comput. 2004; 1(1):11–33.View ArticleGoogle Scholar
 Veríssimo P. Dialogue on Cyber Policies between Brazil and the EU: prospecting threats and opportunities of the cyberspace. Dialogue Cyber Policies. 2016.Google Scholar
 Naveed M, Kamara S, Wright CV. Inference attacks on propertypreserving encrypted databases. In: Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security. New York: ACM;2015. p. 644–55.Google Scholar
 Gelernter D. Generative Communication in Linda. ACM Trans Programing Lang Syst. 1985; 7(1):80–112.View ArticleMATHGoogle Scholar
 Bessani AN, Alchieri EP, Correia M, da Silva Fraga J. DEPSPACE: A byzantine faulttolerant coordination service. In: Proceedings of the 3rd ACM SIGOPS/EuroSys European Conference on Computer Systems 2008. New York: ACM;2008. p. 163–76.Google Scholar
 Alchieri EAP, Bessani AN, Fraga dSJ. A dependable infrastructure for cooperative web services coordination. In: IEEE International Conference on Web Services. Beijing: IEEE;2008. p. 21–8.Google Scholar
 Bessani AN, Correia M, Fraga JS, Lung LC. Sharing memory between Byzantine processes using policyenforced tuple spaces. In: Proceedings of 26th IEEE International Conference on Distributed Computing Systems. Lisboa: IEEE;2006.Google Scholar
 Distler T, Bahn C, Bessani A, Fischer F, Junqueira F. Extensible distributed coordination. In: Proceedings of the Tenth European Conference on Computer Systems. EuroSys ’15. New York: ACM;2015.Google Scholar
 De Nicola R, Ferrari GL, Pugliese R. KLAIM: A Kernel Language for Agents Interaction and Mobility. IEEE Trans Softw Eng. 1998; 24(5):315–30.View ArticleGoogle Scholar
 Busi N, Gorrieri R, Lucchi R, Zavattaro G. SecSpaces: a DataDriven Coordination Model for Environments Open to Untrusted Agents. Electron Notes Theor Comput Sci. 2003; 68(3):310–27.View ArticleGoogle Scholar
 Vitek J, Bryce C, Oriol M. Coordinating processes with Secure Spaces. Sci Comput Program. 2003; 46(1–2):163–93.View ArticleMATHGoogle Scholar
 Bakken DE, Schlichting RD. Supporting FaultTolerant Parallel Programing in Linda. IEEE Trans Parallel Distrib Syst. 1995; 6(3):287–302.View ArticleGoogle Scholar
 Segall EJ. Resilient distributed objects: Basic results and applications to shared spaces. In: Proceedings of the 7th IEEE Symposium on Parallel and Distributed Processing  SPDP’95. San Antonio: IEEE;1995. p. 320–7.Google Scholar
 Lamport L, Shostak R, Pease M. The Byzantine generals problem. ACM Trans Program Lang Syst. 1982; 4(3):382–401.View ArticleMATHGoogle Scholar
 Schoenmakers B. A simple publicly verifiable secret sharing scheme and its application to electronic voting. In: Proceedings of the 19th Annual International Cryptology Conference on Advances in Cryptology  CRYPTO’99. Santa Barbara: Springer Berlin Heidelberg: 1999. p. 148–64.Google Scholar
 Castro M, Liskov B. Practical Byzantine faulttolerance and proactive recovery. ACM Trans Comput Syst. 2002; 20(4):398–461.View ArticleGoogle Scholar
 Menezes AJ, Vanstone SA, Oorschot PCV. Handbook of Applied Cryptography, 1st. Boca Raton: CRC Press, Inc.; 1996.View ArticleMATHGoogle Scholar
 Boneh D, Shoup V. A Graduate Course in Applied Cryptography. 2015. https://crypto.stanford.edu/~dabo/cryptobook/draft_0_2.pdf. Accessed Nov 2017.
 Bellare M, Desai A, Pointcheval D, Rogaway P. Relations among notions of security for publickey encryption schemes. In: Advances in Cryptology  CRYPTO ’98, 18th Annual International Cryptology Conference. Santa Barbara: Springer Berlin Heidelberg: 1998. p. 26–45.Google Scholar
 Boldyreva A, Chenette N, Lee Y, O’Neill A. OrderPreserving Symmetric Encryption. 2012. Cryptology ePrint Archive, Report 2012/624. http://eprint.iacr.org/2012/624. Accessed Nov 2017.
 Popa RA, Redfield CMS, Zeldovich N, Balakrishnan H. CryptDB: Protecting confidentiality with encrypted query processing. In: Proceedings of the TwentyThird ACM Symposium on Operating Systems Principles. New York: ACM;2011. p. 85–100.Google Scholar
 Alves PGMR, Aranha DF. A framework for searching encrypted databases. In: XVI Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais (SBSEG 2016). Niterói: SBC;2016. p. 142–55.Google Scholar
 Boneh D, Lewi K, Raykova M, Sahai A, Zhandry M, Zimmerman J. Semantically Secure OrderRevealing Encryption: MultiInput Functional Encryption Without Obfuscation. 2014. Cryptology ePrint Archive, Report 2014/834. http://eprint.iacr.org/2014/834. Accessed Nov 2017.
 Chenette N, Lewi K, Weis SA, Wu DJ. Practical OrderRevealing Encryption with Limited Leakage. 2015. Cryptology ePrint Archive, Report 2015/1125. http://eprint.iacr.org/2015/1125. Accessed Nov 2017.
 Lewi K, Wu DJ. Orderrevealing encryption: New constructions, applications, and lower bounds. In: Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, CCS ’16. New York: ACM;2016. p. 1167–78.Google Scholar
 Tourky D, ElKawkagy M, Keshk A. Homomorphic encryption the “holy grail” of cryptography. In: 2016 2nd IEEE International Conference on Computer and Communications (ICCC). Chengdu: IEEE;2016. p. 196–201.Google Scholar
 Naehrig M, Lauter K, Vaikuntanathan V. Can homomorphic encryption be practical? In: Proceedings of the 3rd ACM Workshop on Cloud Computing Security Workshop. New York: ACM;2011. p. 113–24.Google Scholar
 Paillier P. Publickey cryptosystems based on composite degree residuosity classes. In: Proceedings of the 17th International Conference on Theory and Application of Cryptographic Techniques. EUROCRYPT’99. Berlin: SpringerVerlag;1999. p. 223–38.Google Scholar
 Gamal TE. A public key cryptosystem and a signature scheme based on discrete logarithms. IEEE Trans Inf Theory. 1985; 31(4):469–72.MathSciNetView ArticleGoogle Scholar
 Khader AS, Lai D. Preventing maninthemiddle attack in diffiehellman key exchange protocol. In: 22nd International Conference on Telecommunications. Sydney: IEEE;2015. p. 204–8.Google Scholar
 Analytics N. A Java library for Paillier partially homomorphic encryption. Available at https://github.com/n1analytics/javallier. Accessed Nov 2017.
 Savvides S. Orderpreserving encryption in Java. Available at https://github.com/ssavvides/jope. Accessed Nov 2017.
 White B, Lepreau J, Stoller L, Ricci R, Guruprasad S, Newbold M, Hibler M, Barb C, Joglekar A. An Integrated Experimental Environment for Distributed Systems and Networks. In: Proc. of 5th Symp. on Operating Systems Design and Implementations. Boston: ACM;2002.Google Scholar
 Schneider FB. Implementing faulttolerant service using the state machine aproach: A tutorial. ACM Comput Surv. 1990; 22(4):299–319.View ArticleGoogle Scholar
 Lehman TJ, et al. Hitting the distributed computing sweet spot with TSpaces. Comput Netw. 2001; 35(4):457–72.View ArticleGoogle Scholar
 JavaSpaces. JavaSpaces Guide. 2016. Available at http://www.oracle.com/technetwork/articles/java/javaspaces140665.html. Accessed Nov 2017.
 GigaSpaces. GigaSpaces Homepage. 2016. Available at http://www.gigaspaces.com/. Accessed Nov 2017.
 Xu A, Liskov B. A design for a faulttolerant, distributed implementation of Linda. In: Proc. of the 19th Symposium on FaultTolerant Computing. Chicago: IEEE;1989. p. 199–206.Google Scholar