REU Group 2 - Paper

Range Queries Over Encrypted Data on Cloud
Christian Granier1
and Scott Payne2
1
New Jersey Institute of Technology
2
Missouri University of Science and Technology
Abstract. While Cloud Computing allows for massive amounts of data
to be outsourced to off-site servers, it is in the best interest of consumers
with sensitive information to encrypt their data before storage. Given
the potentially large amount of encrypted data and the computational
resources required for decryption, performing various operations on en-
crypted data becomes important.
Secure range queries over encrypted data is one such operation, and the
subject of our research. In this paper, rather than focusing on range
querying itself, we shall experiment and analyze the underlying proto-
cols and computations required for its implementation, such as Secure
Comparison (SC) and Secure Bit Decomposition (SBD). Various SC and
SBD protocols that have been suggested in our related works will be
explored and tested, having each been implemented using a basic secret
sharing scheme and the Paillier cryptosystem.
Keywords: Secure Comparison, Secure Bit Decomposition, Range Queries,
Secret Sharing, Pallier Encryption, Multi-Party Computing
1 Introduction
With the increasing availability of cloud computing services, many companies
are now finding it more cost effective to store and maintain the data they col-
lect on servers maintained by third parties. Cloud computing offers a convenient
and cost effective method for storing, maintaining, and operating on large quan-
tities of data, all available on an as needed basis. As the outsourcing of data
becomes more and more common, issues of privacy and security for that data
are a pressing concern. For companies outsourcing sensitive data, the solution
has been to first encrypt their data before migrating it to the cloud, to undoubt-
edly insure the integrity of that data. However, the layer of security provided
by this encryption step reduces the number of operations that can be performed
on the data, remotely, without decrypting or revealing information about that
data to the cloud service provider. One of the more common features of many
outsourced database services is the querying of data. To allow this feature to be
implemented when data is encrypted, the operation of querying encrypted data
must be refined to run extremely efficiently and securely.
In this paper, we focus on the underlying protocols that make queries on
encrypted data possible. Secure comparison (SC) and secure bit decomposition

(SBD) are the two most integral, but these also rely heavily on the simpler
operations of adding and multiplying two encrypted values. By making the SC
and SBD operations more secure and efficient, the process of querying encrypted
data also becomes more practical. The work we have done has involved the im-
plementation of these major protocols using C/C++ to build towards a working
application for performing queries on an encrypted database.
The benefit of implementing various different pre-existing protocols for SC
and SBD is to verify their accuracy, while building a solid understanding of their
proposed workings. Implementations for two different cryptographic schemes, se-
cret sharing and Pallier encryption, were explored and developed independently,
with unique methods for performing the operations of comparison and bit decom-
position on their forms of encrypted data. Through our work to design functional
applications using these protocols, some small errors were found in the originally
proposed algorithms, and changes were made to make them perform as intended.
In our working C/C++ code, the inner workings of these protocols is displayed
clearly in a way that should be very easy to understand with basic knowledge of
the C programming language.
2 Preliminary
2.1 Secret Sharing
Secret Sharing is a method for protecting sensitive data, much like other crypto-
graphic schemes. It does this by dividing a secret value into multiple shares, to
be distributed to different parties for storage or future computations. The orig-
inal secret value can only be known by reconstructing a predetermined number
of shares, requiring collusion between parties. Security is ensured by requiring a
number of shares to be compromised before any information can be determined,
thus reducing the feasibility of security breach.
Mathematical operations can still be performed on distributed secret shares,
without revealing the original value or the separate partys shares, through coop-
eration between parties. By allowing operations to be performed on/with shares,
it is not required to reconstruct original values each time. This allows multiple
operations to be computed in sequence, without ever reconstructing solutions
or revealing the answers to any party, until the desired end solution is reached.
For purposes of simplicity, in our implementations for secret sharing a very basic
two-party form of additive shares are used. In this way, a number X is split into
two shares, x1 and x2, such that:
X = (x1 + x2) mod N (1)
Where N is a public global value known by both parties. As operations are
performed, the results are returned as shares of their solution, such that each
party holds a share of the completed operation. This allows more computations to
take place on these resulting shares, any number of times, until a final solution
is reached and they are recombined by the participating parties to reveal the
desired information.

2.2 Paillier Encryption
The Paillier encryption scheme is an asymmetric cryptosystem that is additively
homomorphic; two keys are generated, a public key given by pk(N, g) and a secret
key given by sk(λ, µ). The two keys are generated by performing a number of
mathematical operations on two randomly generated large prime numbers. The
public key is made public and given to anyone that the key owner desires, as
data can be encrypted, but not decrypted, with just the public key. The secret
key however is usually kept only by the key owner, or shared privately only with
those that are allowed access to encrypted information. To encrypt an integer m
and store it in value c, the equation
c = gm
∗ rn
mod N2
(2)
is used. To decrypt c and return the initial message m, the equation used is
m =
cλ
mod N2
− 1
N
∗ µ mod N (3)
The homomorphic properties of this cryptosystem are imperative to the se-
cure computations we will be performing with it; the two properties in question
are the homomorphic addition and multiplication. Given the pair of encryption
and decryption functions given respectively as Epk and Dsk as well as two in-
tegers a and b within ZN , the homomorphic properties state that the following
are true:
Addition: Dsk(Epk(a) ∗ Epk(b)) = a + b mod N (4)
Multiplication: Dsk(Epk(a)b
) = a ∗ b mod N (5)
Understanding these properties is important in our implementation of protocols
that utilize the Paillier encryption scheme.
Another property to note that is commonly used in this paper is that N − 1
is equal to −1 under ZN , meaning that the following operation is true:
Epk(x) ∗ Epk(y)N−1
= Epk(x) ∗ E(y)−1
= Epk(x) ∗ Epk(−y) = Epk(x − y) (6)
Raising Epk(y) by the exponent N − 1 computes the value of Epk(x − y) using
only integers, as Epk(y)−1
would return a fraction otherwise.
2.3 Secure Multi-Party Computation
Multi-party computation is a method for parties to cooperatively compute a
function over their individual inputs, while preserving the privacy of these inputs.
Consider a scenario with multiple parties, each holding an input value xi , that
want to compute some output value based on all of their inputs. This can be
accomplished by exchanging messages and performing local computations, until
the desired output is calculated and revealed to all parties.
For multi-party computation to be secure, privacy of the data must be se-
cured in the face of adversarial behavior, by an external party or some of the
participants. This security is addressed in diﬀerent ways by our two previously
mentioned cryptographic schemes, secret sharing and Pallier encryption.

3 Related Works
3.1 Secure Multiplication
Our implementations of SC and SBD, within the secret sharing cryptography
scheme, rely heavily on multiplications between secret shared integers. For these
larger protocols to remain secure and perform efficiently, a solid implementation
of secure multiplication was very important. Using the shared multiplication
algorithm proposed in [4] as a base, a modified and more simplified version was
designed for our purposes. In our secure multiplication protocol, three parties are
needed, two with shares of the individual values to be multiplied and a third to
generate random numbers for purposes of masking the shares. The shares must
be securely masked, so that they can be securely sent back and forth between
the first two parties and used in computations.
3.2 Secure Comparison
Secure Comparison (SC) is, on its own, essential to performing range queries,
as secure data must be compared to determine the range in which it falls in.
Additionally, SC is often a necessary component of secure bit decomposition
(SBD), and other such operations on secure data. The goal of SC is (given two
parties, one holding two secure values) to compare the two values and return a
secure result as to their relation (whether greater than or equal to or less than
or equal to), all without revealing the actual values and result to either party.
Existing methods of secure comparison have been researched and explored
for the purposes of this paper, as well as the implementation of SBD protocols.
One such method we explored computes the comparison of two integers with the
input of two shares from each integer, using the secret sharing method. [3] XOR
and Prefix-OR operations must be performed in the SC protocol, both of which
were manually implemented with help from the Prefix-OR protocol suggested
in the paper. Using these operations, a Bitwise less-than protocol is suggested,
which computes a secure output of whether the first input is less than the second
input, all of which are masked by shares. This SC protocol is necessary in our
implementation of secure bit decomposition that utilizes secret sharing.
Another method of SC we have explored utilizes two encrypted integers (en-
crypted with the Paillier encryption scheme) as input, and computes an en-
crypted result of their comparison. [2] In this implementation, two parties are
used, the first which holds the two encrypted values to be compared and the
second holds the private key, the public key being known to both parties. Us-
ing a series of calculations that serves to mask both the original values and the
resulting comparison from both parties, a result is computed for one of the two
comparison functions, greater than or less than, which is randomly chosen. Un-
like the SC of secret shared values, this SC protocol is not necessary to perform
secure bit decomposition on encrypted values.

3.3 Secure Bit Decomposition
Bit decomposition is the process of converting, or decomposing an integer into
its binary representation through a mathematical process; Secure Bit Decompo-
sition is performing this operation on secure values without revealing the actual
value to any party involved. In our research we explored two methods of SBD,
one that securely decomposes secret shared values and one that securely decom-
poses encrypted values.
Assuming two parties, each of which holds a share of a certain value, the
shares can be converted into shares of each bit of said value using the protocol
outlined in [5]. This protocol utilizes both the secret sharing multiplication as
well as SC in order to carry out the operation. The input value is first masked
by a randomly generated number, in order to prevent the reveal of data, as two
shares of each bit of the input are computed then given to the two participating
parties.
SBD can also be performed on an encrypted integer, using two parties of
which one has an encrypted value, the second has a secret key, and the pub-
lic key is known to both. [1] Using the homomorphic properties of the Paillier
cryptosystem, the encrypted input is masked by a random number, and a series
of calculations are performed between the two parties to produce the encrypted
value of each bit of the input. This is accomplished without revealing any infor-
mation about the encrypted value to the party that holds the secret key.
4 Problem Statement and Motivation
While performing range queries over encrypted data securely, especially with
data stored in the cloud, is important, the actual process of performing these
queries is relatively simple. The established protocols for these range queries
are straightforward and sufficiently efficient, and require a large database of
encrypted data in order to test any range query algorithms. For this reason, we
have decided to instead research the underlying protocols and algorithms that,
while not exclusively useful to range queries, are essential for it to function.
Our research brought us to two main methods of querying, one using Paillier
encryption and one using the secret sharing method. With each method, we
discovered that secure bit decomposition is essential to querying, as the queries
are performed with binary values as opposed to integer values. In addition to the
SBD protocol, other secure computation algorithms such as secure comparison
and secure multiplication were found; since secure comparison and multiplication
are necessary for our secret sharing implementation of SBD to function, we
researched and implemented these protocols as well.
Our two goals in the research and implementation of these protocols are as
follows: to verify the multi-party security and accuracy of each protocol by im-
plementing each on a simulated multi-party environment, and to compare the
efficiency, strengths, and weaknesses of the two main methods (Paillier encryp-
tion and secret sharing) of each protocol.

5 System Architecture and Algorithms
5.1 GMP Library
The use of the GNU Multi-Precision library (GMP) was vital in facilitating the
use of encryption keys with bit lengths numbering in the thousands, much larger
than would be possible with standard primitive data types. Functions provided
by the GMP library streamline the process of performing simple mathematical
operations on extremely large numbers. By allowing the use of extremely large
encryption keys and encrypted values, our applications stayed truer to the needs
of modern cryptography.
5.2 Multi-Party Computing
Multi-party computation (MPC) is an integral part of both cryptosystem im-
plementations we worked on. All of the protocols described below require some
amount of cooperation between multiple machines, in order to prevent informa-
tion about the data being discovered in the process of their execution. Providing
security while using a single computing party would be impossible, because if it
were to be compromised all data would be lost.
In both of our implementations more than one machine are used to preserve
privacy of data during processing. To facilitate their cooperation we established
a very simple communication network between machines, to allow data to be
transferred as needed. Many rounds of communication are required, with com-
putations taking place locally on each machine between the transferring of data.
Computations are done in parallel whenever possible, to minimize downtime of
machines and decrease the overall time required for operations to take place.
5.3 Sockets
Our communication network is comprised of a very basic client/server relation-
ship between machines using sockets provided with the GNU C library. The
requirement for three machines to all be simultaneously connected is addressed
by having each machine launch as both client and server. In this way, each
machine both hosts a socket connection requested by one machine, while itself
requesting a connection hosted by the remaining machine.
For our purposes, this primitive communication network fulﬁlled the basics
of what was required to perform computations with multi-parties. Without pre-
vious knowledge of networking, no more time was spent than necessary creating
an eﬃcient network to satisfy our requirements for implementing . This aspect
of our implementations, including both the establishment of connections and
transferring of messages, could be greatly improved upon to increase the speed
at which our applications perform.

5.4 Secure Multiplication
Secure multiplication is the most critical building block of our method for secure
comparison of secret shared values. All of the communication required for se-
cure comparison to take place is done within the multiplication of secret shared
values. Since secure comparison is in turn the most crucial part of secure bit
decomposition of secret shared values, the multiplication protocol contains the
vast majority of communications for the entire proposed implementation of range
queries on data encrypted with a secret sharing scheme.
Our implementation of secure multiplication was heavily influenced by the
protocol presented in [4]. However, many changes were made to simplify and
streamline the process for our purposes. The basic concept is explained very
well in [4] and is still followed by our modified protocol, but our final algorithms
differ greatly from the ones proposed. Only the very similar underlying equation
is examined here.
Assuming the two parties, P1 and P2, want to multiply two secret shared
values, x1 and x2, it is noticed that:
(x1 + a1) ∗ (x2 + a2) = x1 ∗ x2 + x1(x2 + a2) + x2(x1 + a1) − a1 ∗ a2 (7)
which allows the desired product x1 x2 to be expressed as:
x1 ∗ x2 = (x1 + a1) ∗ (x2 + a2) − x1(x2 + a2) − x2(x1 + a1) + a1 ∗ a2 (8)
The multiplication protocol used in our implementation still takes advantage of
this simple algebraic equation. Through the use of the random values a1 and a2,
generated by a third party, P1 and P2 are able to mask their respective shares
to be securely transmitted and used in local computations by each other. These
local computations produce different segments of the above equation, held by
each party, that become their new share values of the product x1 ∗ x2. The
differences in our modified protocol and the one suggested here by [4] lie in
the distribution of the random values a1 and a2 , explained in our later section
covering our own implementation.
5.5 Secure Comparison
Our implementation of secure comparison is directly based off the protocol pro-
posed in [3] and detailed by Algorithm 1. This BIT-LT protocol compares two
bitwise shared values to determine whether one is less than the other. The end
result is a secret shared value of either a 1 or 0 corresponding to the result of
the functionality a < b, with 1 indicating that the functionality is true and 0
indicating false. In the initial for loop, a bitwise XOR function is computed, re-
turning bitwise shared values to P1 and P2 of the value A XOR B, represented
by [e]p , where A and B are the plain-text values represented by the bitwise
shares [a]B and [b]B . This is done using the simple algebraic equation:
A XOR B = A + B + 2 ∗ (A ∗ B) (9)

Algorithm 1 Bit LT([a]B, [b]B) → [c]P
1: for i = 0 → l − 1: do
2: [ei]P ← XOR([ai]P , [bi]P )
3: end for
4: ([fl−1]P , . . . , [f0]P ) = PREV ([el−1]P , . . . , [e0]P )
5: [gl−1]P = [fl−1]P
6: for i = 0 → l − 2: do
7: [gi]P ← [fi]P − [fi+1]P
8: end for
9: for i = 0 → l − 1: do
10: [hi]P ← MULT([gi]P , [bi =P )
11: end for
12: [h]P ← l−1
i=0[hi]P
13: Output [h]P
where each partys shares of A and B are used to locally construct shares of
A + B and a single secret multiplication operation is used to to compute shares
of the product A ∗ B, all carried out for each bitwise share. The purpose of this
is to pinpoint the location of bit differences in the original values A and B, while
preserving the privacy of their values.
Using the result of the previous XOR operation, a preOR function is calcu-
lated on the bitwise shares of [e]p by first copying the most significant bitwise
shares in [e]p to [f]p and then computing an OR operation on each following
bitwise share with the one before it using the equation:
A OR B = A + B + A ∗ B (10)
carried out in the same way as the previous XOR computation. The purpose
of this is to locate the most significant bit (MSB) difference between A and B,
represented by the first location of a 1 in the value A XOR B, and replace all
subsequent bits with 1s.
After this preOR calculation has been made, a calculation can be made on the
bitwise shares in [f]p to further isolate the location of the bitwise shares of the
MSB different between A and B. To accomplish this, first the MSB bitwise shares
of [f]p are copied to [g]p , and then each subsequent bitwise share is subtracted
from the previous one. The end result of this operation is a bitwise shared binary
value with a single 1, representing the location of the MSB difference between
A and B.
Once the MSB difference between A and B is isolated, a bitwise secure mul-
tiplication can be performed between each bitwise share of [g]p and [b]B . This
results in a bitwise shared binary value with either a 0 or a single 1 in place of
the MSB difference location. If a 0 is calculated at this location, B is less than
A, as in this case the binary value B contained a 0 in the place of the MSB dif-
ference, because (0 * 1) = 0. Otherwise, if a single 1 is calculated in this bitwise
multiplication, A is less than B, because B contained a 1 in the location of the
MSB difference.

After this ﬁnal bitwise shared binary value is calculated, all that is left is a
summation of each bit, resulting in bitwise shares of either a 1 or 0. In this way, a
secure comparison is computed on two bitwise shares and further computations
can be carried out on them, without revealing the result of the comparison to
either party, unless cooperatively reconstructed.
The Paillier encryption version of the SC method, given by Algorithm 2, [2]
assumes the use of an additively homomorphic cryptosystem, in this case Pail-
liers, with public key pk(N, g) and secret key sk(λ, µ), as well as two parties, P1
and P2. P2 holds both the private and public keys, while P1 holds the encrypted
values to be compared, Epk(a) and Epk(b) (where 0 ≤ a, b ≤ 2m
, meaning both
a and b are less than m bits), as well as the public key. This setup gives P2 the
ability to encrypt and decrypt data, P1 the ability to encrypt data, and provides
the encrypted integers to the party that is unable to decrypt them, keeping the
data secure. The goal of this algorithm is to determine the functionality c : a ≥ b,
where c = 1 if true and c = 0 if false. The result, c, is calculated in a fashion
that hides it from both parties.
The algorithm begins with P1 calculating l = 2−1
mod N. P1 then randomly
chooses a functionality, between a ≥ b and b ≥ a + 1, denoted by F. This is
a temporary functionality, used to mask the result of the operation from both
parties; the overall goal of the algorithm is still the comparison a ≥ b. If the
functionality a ≥ b is chosen, then the encrypted value of a − b is determined by
performing the following calculations:
Epk(d) = Epk(a − b) = Epk(a) ∗ Epk(b)N−1
(11)
Similarly, if the functionality b ≥ a+1 is chosen, the encrypted value of b−(a+1)
or b − a − 1 is computed as below:
Epk(d) = Epk(b − a − 1) = Epk(b) ∗ Epk(a + 1)N−1
(12)
where Epk(a + 1) = Epk(a) ∗ Epk(1). All of these calculations are made possible
by the Paillier cryptosystems homomorphic properties.
The result of this calculation is assigned to Epk(d), where Epk(d) is then
assigned to δ. P1 and P2 then begin computing the encrypted value Epk(d ).
First, P1 masks the value of Epk(d) by multiplying τ = δ ∗ Epk(ri) where ri
is a random number in ZN ; τ is then sent to P2 and decrypted, the previous
operation serving to randomize the result, making it impossible for P2 to know
the value of d. The decrypted value, denoted as τ, is then examined, and the
variable s is set to Epk(0) if τ is even, and Epk(1) if τ is odd. s is then sent to
P1, where Epk(di) is set to either s if the above ri is even, or Epk(1) ∗ sN−1
if ri
is odd. Epk(d ) is then updated each iteration by multiplying Epk(di), resulting
in Epk(d ) = Epk(
m
i=1 di). P1 then updates δ to Epk( d
2 ) by performing the
calculations:
φ = δ ∗ Epk(di)N−1
(13)
δ = φl
(14)

Algorithm 2 PallierSecureComparison(Epk(a), Epk(b)) → Epk(c)
Require: P1 holds Epk(a) and Epk(b) where a and b are not known to either parties,
and 0 ≤ a, b ≤ 2m
. The Public and secret keys, pk(N, g) and sk(λ, µ), are known
to P2, while only the public key is known to P1
1: P1:
(a) l ← 2−1
mod N and d ← 0
(b) Randomly choose the functionality F
(c) if F : a ≥ b then Epk(d) ← Epk(a − b)
if F : b ≥ a + 1 then Epk(d) ← Epk(b − a − 1)
(d) δ ← Epk(d)
2: for i = 1 → m do:
(a) P1:
• τi ← δ ∗ Epk(ri), where ri ∈ ZN
• Send τi to P2
(b) P2:
• τi ← Dsk(τi)
• if τi is even, then si ← Epk(0)
else si ← Epk(1)
• Send si to P1
(c) P1:
• if ri is even, then Epk(di) ← si
else Epk(di) ← Epk(1) ∗ sN−1
i
• Epk(d ) ← Epk(d ) ∗ Epk(di)2i−1
• φ ← δ ∗ Epk(di)N−1
and δ ← φl
• if i = m then
- G ← Epk(d) ∗ Epk(d )N−1
- G ← Gr
, where r ∈ ZN
- Send G to P2
3: P2:
(a) Receive G from P1
(b) if Dsk(G ) = 0 then c ← 1
else c ← 0
(c) Send Epk(c ) to P1
4: P1:
(a) Receive Epk(c ) from P2
(b) if F : a ≥ b then Epk(c) ← Epk(c )
if F : b ≥ a + 1 then Epk(c) ← Epk(1) ∗ Epk(c )N−1

These operations serve to securely compute Epk(d − d ), where Epk(d) is
defined as above, and Epk(d ) is defined by
i
j=1 dj ∗2j−1
. The result, Epk(d−d ),
is computed in the final round of the protocol and assigned to the variable G by
performing G = Epk(d) ∗ Epk(d )N−1
. The value of d − d is then randomized by
performing G = Gr
, where r is a random number under ZN , multiplying d − d
by a random number and disguising it from P2. P2 then receives and decrypts
G , and sets the value c = 1 if Dsk(G ) = 0, or c = 0 otherwise. The encrypted
value of this, Epk(c ) is then sent to P1, where depending on the functionality,
the result is determined by Epk(c) = Epk(c ) if the functionality F is given as
a ≥ b, or Epk(c) = Epk(1) ∗ Epk(c )N−1
otherwise, where c is either 1 or 0, and
is the final result of the comparison a ≥ b.
5.6 Secure Bit Decomposition
For secure bit decomposition of secret shared values, Algorithm 3 is used. [5]
The protocol takes [X], a single share of an integer X, where 0 ≤ X ≤ 2m
− 1;
additionally, the secret sharing scheme uses the integer N as its global modulus
variable. The intended output of the algorithm is a single share of the bitwise
representation of X, denoted by ([Xm−1], . . . , [X0]), or more easily as [X]B.
First, a random number r within ZN is generated and bitwise shared, and
the output of X +r mod N is computed, denoted by the variable c. The variable
c is then calculated as c = c + N. A secure comparison of the bitwise share of
r and c is then performed, to determine if [r]B is greater than c. The result, [f],
is a share of 1 or 0, representing true or false respectively. A bitwise share of ¯c
is then computed using the formula
[¯ci] = [f] ∗ (ci − ci) + [ci] (15)
where the unshared bits in the ith position of c and c are subtracted, multiplied
by the share [f], then the share of the bit in the ith position of [c]B is added.
Algorithm 3 SecretSharingSBD([X]) → ([Xm−1], . . . , [X0]).
1: [r]B ∈ ZN
2: c ← output([X] + [r]B)
3: c ← c + N
4: [f] ← [r]B >?c
5: for i = 0 → m do
6: [¯c]B ← [f] ∗ (ci − ci) + [ci]
7: end for
8: [¯c]B ← ([¯cm], . . . , [¯c0])
9: [X mod 2m
] ← [X]
10: for i = m − 1 → 1 do
11: [ui] ← [r mod 2i
]B >?[¯c mod 2i
]B
12: [X mod 2i
] ← [¯c mod 2i
] − [r mod 2i
] + 2i
∗ [ui]
13: [Xi] ← 2−i
∗ ([X mod 2i+1
] − [X mod 2i
])
14: end for

This computes [¯c]B, a bitwise share of ¯c, where ¯c is the true value of X + r.
These calculations are necessary to compute ¯c, as in the initial output of adding
the shares of X and r, the result is modulo N, as per the rules of secret sharing.
If the true value of X + r is in fact greater than N, then simply computing c is
problematic. Thus, ¯c = X + r is computed in this fashion.
Following this, the calculation of the bitwise share of X is started. First, the
value of [X mod 2m
] is set equal to the input share [X]. Then, starting from
m − 1, the comparison of [r mod 2i
]B and [¯c mod 2i
]B is computed, resulting in
the share [ui]. This notation means that, for example, [r mod 2i
]B would be the
i least signiﬁcant bit shares of r, or the shares of the rightmost i bits. Following
this comparison, [X mod 2i
] is calculated like so:
[X mod 2i
] = [¯c mod 2i
] − [r mod 2i
] + 2i
∗ [ui] (16)
where [¯c mod 2i
] and [r mod 2i
] are the integer shares of [r mod 2i
]B and [¯c mod
2i
]B, computed by the equation [z] =
m
i=0 2i
∗ [zi]. Next, the calculation
[Xi] = ([X mod 2i+1
] − [X mod 2i
]) ∗ 2−i
(17)
is performed. In the initial case of i = m − 1, the previously set value of
[X mod 2m
] is used as [X mod 2i+1
]. The operation [X mod 2i+1
] − [X mod 2i
]
is equal to 2i
∗ [Xi], thus the multiplication by 2−i
. Thus, a share of the ith bit
of X is calculated; the loop is then repeated until a share of every bit of X is
calculated.
Algorithm 4, the algorithm for encrypted SBD [1] utilizes the Paillier cryptosys-
tem, and is performed without the need for secure comparison. We assume two
parties, P1 and P2, where P2 holds both the secret key sk(λ, µ) and the public
key pk(N, g), while P1 holds the public key as well as an encrypted value Epk(z),
where z is the integer to be securely decomposed, and 0 ≤ z ≤ 2m
. Epk(z) is the
input of this algorithm, with the encrypted binary representation of z, denoted
by Epk(z1), . . . , Epk(zm), being the intended result.
P1 begins by computing the modular multiplicative inverse of 2 and N, stor-
ing the value in variable a. The encrypted input Epk(z) is then set to the variable
U. With z being less than m bits, each bit of z, from 1 to m, is computed.
For each step from 1 to m, P1 disguises the value of z by ﬁrst adding a
random bit rb to z, calculated by Epk(z) ∗ Epk(rb) and stored in variable L. L
is then raised to the power of a and multiplied by Epk(r), where r is a random
number under ZN , and stored in the variable M. M is represented as:
M = L ∗ Epk(r)
= La
∗ Epk(r)
= (U ∗ Epk(rb))a
∗ Epk(r)
= (Epk(z) ∗ Epk(rb))a
∗ Epk(r)
= Epk(a ∗ (z + rb) + r)

Algorithm 4 PallierSBD(Epk(z)) → [Epk(z1), . . . , Epk(zm)]
Require: P1 holds Epk(z) where z is not known to either parties, and 0 ≤ z ≤ 2m
.
The Public and secret keys, pk(N, g) and sk(λ, µ), are known to P2, while only the
public key is known to P1
1: P1:
(a) a ← 2−1
mod N
(b) U ← Epk(z)
2: for i = 1 → m do:
(a) P1:
• L ← U ∗ Epk(rb), where rb is a random bit
• L ← La
• M ← L ∗ Epk(r), where r is a random number in ZN
• Send M to P2
(b) P2:
• Receive M from P1
• M ← Dsk(M)
• Mk ← IP(M , k)
• W ← Epk(Mk)
• Send si to P1
(c) P1:
• Receive W from P2
• rk ← IP(r, k)
• H ← W ∗ Epk(N − rk)
• H ← Hr
where r is a random number in ZN
• Send H to P2
(d) P2:
• Receive H from P1
• τ ← Dsk(H )
• if τ is even, then β ← Epk(0)
else β ← Epk(1)
• Send β to P1
(d) P1:
• Receive β from P2
• τ ← Dsk(H )
• if rb = 0 then Epk(zi) ← β
else Epk(zi) ← Epk(1) ∗ βN−1
• V ← U ∗ Epk(zi)N−1
• U ← V a

This calculation holds for the first iteration, where U is equal to E(z). P2 then
receives M, and receives M after decryption. The IP function, which returns
the integer corresponding to the k-bit prefix of M , is then used. [1] In this
algorithm, k is a randomly generated number between 1 and K − m, where K is
the bit length of N, and m is the bit length of z; the IP function takes the k-most
significant bits of the binary value of M , or the k left-most bits, and converts
them to an integer. This integer is stored in the variable Mk, encrypted, and sent
to P1. P1 receives this value, stored in the variable W, and performs the same
IP function on the previously generated random number r, storing the result in
variable rk. H = W ∗ Epk(N − rk) is then calculated, where, by homomorphic
properties, H = Epk(Mk − rk); H is then masked by the operation H = Hr
(where r is a newly generated random number within ZN ) and sent to P2.
If we give z as z = z + rb, then the previous operations will result in
Mk − rk = 0 if z is even, and Mk − rk = 0 otherwise. Thus, when P2 decrypts
H , if the result is 0, the variable β is set to Epk(0), or Epk(1) if the result is not
equal to zero. In standard binary decomposition, a bit is set to 1 if the current
U is odd, and 0 if even. In this algorithm, P2 calculates either 1 or 0 based on
whether z is odd or even; since z hides the integer z by adding a random bit,
P2 is given no information about the integer z as a result.
When P1 receives β, the encrypted bit, or Epk(zi) is then computed. If the
random bit rb = 0, then z = z, and Epk(zi) = β. However, if rb = 1, then
z = z + 1, meaning the value of β is incorrect; in the latter case, the correct
result is determined by calculating
Epk(zi) = Epk(1) ∗ βN−1
(18)
In this case, Epk(zi) = Epk(1) ∗ βN−1
= Epk(1 − Dpk(β)) = Epk(z mod 2). With
these calculations, Epk(zi) is calculated then stored. U is then updated to the
value of Epk( z
2 ) by calculating
V = U ∗ Epk(zi)N−1
(19)
U = V a
(20)
and the loop repeats with the updated value of U, continuing until each en-
crypted bit of z is calculated and stored. Based on the calculations performed in
the protocol, no information about either z or the binary value of z is revealed
to either P1 or P2.
6 Implementation and Experiments
6.1 Experiment Setup
The programming environment for our implementation of these researched al-
gorithms consists mainly of three separate virtual machines, each with a cur-
rent version of Ubuntu installed. Each virtual machine has a functioning GNU
C/C++ compiler with the GMP library installed as well. Our programs use the

C++ language, using the GMP librarys custom functions for the mathematical
operations on GMP integers. In order to communicate between the three virtual
machines, socket connections are used to connect the machines through an in-
ternal network. Our implementation of socket communication can only send an
array of characters between parties, whereas we require large GMP integers to
be sent; this is remedied by custom functions that first convert a GMP integer
into a character array, send the array to the receiving party, and then convert
the character array back to a GMP integer upon receival on the other side. Three
separate programs are created, one for each machine with their corresponding
role in the algorithm, and distributed to each machine. Each program is then
run in sequence, and the protocols are carried out.
6.2 Secret Sharing
For our implementation of secret sharing, three machines launch applications
with C++ code written to take place between communications in a certain order.
To set up a simulation for multi-party computation to take place, party 3, P3,
generates two random GMP integers and finds the next biggest prime numbers
in order to create a global modulus variable N, as a product of two large primes.
The variable N is then written to a socket, sending it to parties 1 and 2, P1 and
P2. Using N, P1 and P2 randomly generate the original plain text values to be
operated on, A for P1 and B for P2, within the domain of N. These plain text
values are then split into two shares, so that a share of each can be exchanged
between the two parties. P1 splits the value A into two shares, a1 and a2 , and
sends a2 to P2 to be used in calculations. Simultaneously, P2 does the same
with the value B, splitting into two shares, b1 and b2 , and sending b1 to P1
to be used in calculations. This leaves P1 with knowledge of shares a1 and b1,
and P2 with knowledge of shares a2 and b2, setting up the required scenario for
multiplication, secure comparison, and secure bit decomposition to take place.
Secret Sharing - Secure Multiplication The multiplication protocol used
in our implementation takes advantage of the following equation:
x1 ∗ x2 = x2(x1 + r1) + r3 − r1(x2 + r2) + r1 ∗ r2 − r3 (21)
which is very similar to the one proposed in [4], with changes concerning the use
of random numbers to decrease the participation required by a third party.
The equation can be split into two parts to be locally computed by P1 and
P2 in the following way:
x1 ∗ x2 = [x2 ∗ (x1 + r1) + r3]P2
+ [−r1 ∗ (x2 + r2) + c]P1
(22)
where c = r1 ∗ r2 − r3.
In this method for the different parties to perform their local computations
they need only know the one or two of the random values, not all three, in order
to mask their own shares and build the equation in a way that when recombined

eliminates all random values from the product. The steps of cooperation for these
shares to be calculated are made clear in working C/C++ implementation, but
will be explained brieﬂy here.
For the secret shared product of a1 ∗ b2 to be computed cooperation between
P1, P2, and P3 must take place, since neither P1 nor P2 has access to both
shares. The random numbers required for this operation ( r1 , r2 , and r3 )
must be generated by P3 to allow masking of shares to be done without allowing
the parties to unmask them upon receival. After these three random values are
calculated P3 must combine them to calculate the value c = r1 ∗ r2 − r3 . P3 can
then transfer the values of r2 and r3 to P2 and the values of c and r1 to P1.
Now that P1 and P2 hold their respective random values, P3 is no longer
an active participant in calculating the shares of a1 ∗ b2 . The two parties can
now mask their shares to be shared with each other for computations. P1 adds
r1 to a1 and sends the value (a1 + r1) to P2 for local computations, without
compromising the privacy of the share a1. Simultaneously, P2 adds r2 to b2 and
then sends the value (b2 + r2) to P1 for their own local computations.
After all of these data transmissions have taken place P1 and P2 have all of
the data they need to construct their shares of the secret shared product a1 ∗ b2.
The same procedure is repeated for the product a1 ∗ b2, which sets up P1 and
P2 to calculate their shares of the desired product A ∗ B based on the following
equation:
(a1 + a2)(b1 + b2) = a1 ∗ b1 + a1 ∗ b2 + a2 ∗ b1 + a2 ∗ b2 (23)
Here P1 is able to locally compute the product a1 ∗ b1 since it has knowledge of
both shares, while P2 is able to locally compute the product a2 ∗ b2 . With these
products and their secret shared values of the products a1 ∗ b2 and a1 ∗ b2 the
following distributed shares of the equation are established:
A ∗ B = [A ∗ B]P 1 + [A ∗ B]P 2 (24)
[A ∗ B]P 1 = a1 ∗ b1 + [a1 ∗ b2]P 1 + [a2 ∗ b1]P 1 (25)
[A ∗ B]P 2 = a2 ∗ b2 + [a1 ∗ b2]P 2 + [a2 ∗ b1]P 2 (26)
where the notation [a1 ∗ b2]P 1 represents the secret share held by P1 of the
product a1 ∗ b2 .
Secret Sharing - Secure Comparison All communication required for se-
cure comparison to be done on secret shared values takes place in the use of
multiplication. Using multiplication, XOR and OR operations are done on the
secret shared values to result in a ﬁnal true or false value for the functionality of
A < B, with a 1 representing the truth of the functionality and a 0 representing
falsity. The operation of this is shown in the implemented code, but follows the
steps exactly from the protocol proposed in [?] and explained earlier in section
5.5.
Using the GMP library, bitwise shares of each bit in A and B were created
and stored in arrays of GMP integers with length equal to the bit size of the

global modulus value N. The XOR and preOR operations were then calculated
on these arrays of bitwise shares, bit by bit, to reach the ﬁnal shares of a 1 or 0
representing the desired true or false solution.
Secret Sharing - Secure Bit Decomposition Our implementation of secure
bit decomposition using secret sharing utilizes three parties; P3 acts as a trusted
data owner, who generates the secret sharing modulo N as well as the input
integer x, providing P1 and P2 with separate shares of x. This protocol uses both
the above secure comparison protocol and the secure multiplication protocol,
requiring communication between all three parties for much of the algorithms
calculations. As the output, both P1 and P2 are left with a share of the binary
value of x, meaning each party holds an array of shares that, when combined
with the other party, each share corresponds to either 1 or 0, resulting in the
binary value of x.
After P3 generates and distributes N and the shares of x, it generates a
random number r, in binary form, and sends a binary share to each party;
additionally, the variable c is computed by P3 as the value of x + r mod N, and
sent to both parties.The ensuing calculations are the same for P1 and P2, as
they each compute their own binary share of x in tandem.
First, the value c is computed as c + N. A secure comparison between r and
c is then performed between P1 and P2, with each holding a separate share of
the result. Both parties then begin their calculations of the bitwise share of ¯c,
using the equation
[¯ci] = [f] ∗ (ci − ci) + [ci] (27)
where ¯c is the true value of x + r.
Following this, the calculation of each bitwise share of x is started. First,
the value of [x mod 2m
] is set equal to the input share [x]. Then, starting from
m − 1, the comparison of [r mod 2i
]B and [¯c mod 2i
]B is computed, resulting in
the share [ui]. Following this comparison, [x mod 2i
] is calculated like so:
[X mod 2i
] = [¯c mod 2i
] − [r mod 2i
] + 2i
∗ [ui] (28)
where [¯c mod 2i
] and [r mod 2i
] are the integer shares of [r mod 2i
]B and [¯c mod
2i
]B. Next, the calculation
[xi] = ([x mod 2i+1
] − [x mod 2i
]) (29)
is performed. In the initial case of i = m − 1, the previously set value of [x mod
2m
] is used as [x mod 2i+1
]; the loop is then repeated until a share of every bit
of x is calculated.
The resulting bitwise shares [x]B is not yet complete. The algorithm requires
the division of each resulting share by 2i
; however, in this implementation, we
are using GMP integers, and most shares will result in a fraction when divided
by 2i
. While we could use GMP ﬂoating point numbers to represent the result,
we fear the loss of accuracy due to rounding in that implementation. Therefore,
the resulting share is not divided by 2i
initially, but rather at the end; once P1

and P2 compute their shares, they are sent to P3 where the shares are properly
combined and finally divided by 2i
, which results in the correct bit value. Though
an extra step is needed in the combination of the resulting bitwise shares, the
result is accurate.
6.3 Paillier Cryptosystem
In order to test the secure algorithms that utilize an additively homomorphic
asymmetrical encryption scheme, we first had to implement such a scheme prac-
tically in the C++ language. Paillier encryption scheme was chosen, as it is the
scheme that was used in the papers that proposed these algorithms. Using the
GMP library to facilitate sufficiently large numbers, two prime numbers of an
equal bit size (a bit size that is easily adjustable for more secure key generation)
were generated, denoted as variables p and q. The public key and secret key,
denoted as pk(N, g) and sk(λ, µ), were computed thusly:
N = p ∗ q
g = N + 1
λ = (p − 1) ∗ (q − 1)
µ = λ − 1 mod N
The public and secret keys, after being generated by an assumed trusted third
party, were then distributed amongst two parties, with the usual case being one
party holding the public key while the second party held both the public and
the secret key.
Functions for encrypting and decrypting messages were also created in order
to simplify the code. The function for encryption carried out the equation c =
gm
∗ rN
mod N2
where m is the input integer and c is the output result, and
the function for decryption carried out the equation m = cλ
mod N2
−1
N ∗ µ mod
N where c is the input encrypted integer and m is the output result. These
functions, as well as the method of generating the public and secret keys, were
sufficiently tested beforehand, and verified to be correct with a very high degree
of certainty
Although each of the algorithms requiring Paillier encryption scheme required
only two parties in order to carry out the calculations, a third party was used in
each implementation; this third party acted as a uninvolved and trusted third
party, akin to a system administrator, who generates the encryption keys, dis-
tributes them amongst the two parties, and encrypts the initial input integer
(created either by random number generation or direct input from the user) to
be distributed as well. Though the third party is important in setting up the
algorithms, it does not take place in any calculations.
Paillier Cryptosystem - Secure Comparison Our implementation of secure
comparison assumes a setup of three parties: P1, who holds the public key and
the two encrypted inputs, Epk(x) and Epk(y); P2, who holds both the public key

and the private key; and P3, who as previously explained, exists only to generate
the encryption keys, create and encrypt the input integers, distribute the data
amongst the other two parties, and receive and display the result at the end of
the protocol, in order to verify its correctness. Though P3 is vital to the setup of
the protocol, it does not partake in any calculations, and its role could be easily
excluded from our implementation by manually providing P1 and P2 with the
data instead.
After the encryption keys and input values are distributed, P1 begins by first
calculating a as the modular multiplicative inverse of 2 and N, and choosing
the random functionality F, with either F : x ≥ y or F : y ≥ x + 1. This
functionality is decided with a random generation of a 1 or 0, akin to a coin flip,
with 0 representing the former functionality and 1 representing the latter. This
value is then stored in a variable F (known only to P1).
The implementation proceeds to faithfully follow the proposed algorithm
from [2]. P1 disguises the encrypted value of d (set to either x − y or y − x − 1,
depending on the functionality chosen) by homomorphically adding a random
number. This value, denoted by variable τ, is then securely sent to P2 using a
socket function for sending and receiving GMP integers. P2 receives τ, decrypts
it, and computes variable s as the encrypted value of 0 if the decrypted τ is
even, and computes s as the encrypted value of 1 otherwise. s is then sent to
P1. P1 proceeds to, following the proposed algorithm, update d and δ; with the
updated value of δ, P1 begins the loop again, beginning with the computation
of τ. This loop carries on for m iterations, where 0 ≤ x, y, ≤ 2m
. Each iteration
of this loop sees two instances of communication between P1 and P2: once when
P1 sends τ to P2, and once when P2 sends s to P1.
At the final iteration of this loop, P1 computes G by accurately following the
proposed calculations. G is then sent to P2, where it is decrypted and examined.
If the decrypted value is equal to 0, then the variable c is set to 1; otherwise,
c is set to 0. c is then encrypted and sent to P1. If the functionality F is equal
to 0 (F : x ≥ y), then the final result, Epk(c), is set equal to Epk(c ); if F = 1
(F : y ≥ x + 1), then further calculations are taken out to securely convert the
value of c to its opposite (c = 0 if c = 1, and c = 1 if c = 0). This result,
Epk(c), is then sent to P3, where it is decrypted and the result, c, provides the
result of the comparison x > y, where c = 0 denotes false and c = 1 denotes
true. This result is computed in such a way that neither P1 nor P2 may ever
know the values of either integer x or y, nor the true value or meaning of the
result. Overall, the amount of necessary communications that take place can be
given as n = 2 ∗ (m + 1).
Paillier Cryptosystem - Secure Bit Decomposition The protocol for se-
cure bit decomposition follows the same general setup as secure comparison, with
three parties, party 3 generating and distributing the encryption keys and input
integer, and parties 1 and 2 carrying out the actual calculations. P3 is used to
provide this context as well as receive and display the final result to be checked
for accuracy.

P1, after receiving the public key and encrypted integer z to be securely
decomposed, begins by computing a as the modular multiplicative inverse of 2
and N. Within a loop, P1 performs a series of computations to calculate variable
M, which is equal to Epk(a∗(z+rb)+r), and sends M to P2. M is then decrypted
and stored in the variable M , and P2 proceeds to compute Mk as the integer
corresponding to the k-bit prefix of M (where 1 < k < K − m, where K is the
bit length of N, m is the bit length of z, and k is known to both parties) and
sends this value to P1.
While [1] made no specifications as to k other than the range, we found that
simply assigning it to a random number between 1 and K − m would result in
errors in the decomposition, returning incorrect binary values. By setting k to
half of the value of K − m, however, the protocol ran and output as intended.
After calculating the integer corresponding to the k-bit prefix of a previously
generated random number and storing it in the variable rk, the encrypted value
of Mk−rk is then calculated by P1 through homomorphic operations. This result,
masked by a random number and denoted as variable H , is then sent to P2. P2
decrypts this value, left with the value of (Mk − rk) ∗ r . If this value is equal to
0, then the value of z + rb is even, so the variable β is set to the encrypted value
of 0; otherwise, if the decrypted value is not equal to 0, then the value of z + rb
is odd, and β is set to the encrypted value of 1. β is then sent to P1, where it is
either set as the encrypted ith bit of z if the initial rb = 0, or the opposite of β is
computed (Epk(0) if β = Epk(1), or Epk(1) if β = Epk(0)) if rb = 1. Afterwards,
P1 securely computes the value of z
2 with homomorphic operations, and the
loop is repeated.
This loop sees i iterations, from 1 to m, each time computing the encrypted
value of the ith bit of z, known only to P1. Each iteration sees 4 instances of
communication between P1 and P2, with the total instances of communication
being given as n = 4 ∗ m. P1 then sends an array storing each encrypted bit of z
to P3, to be decoded for the sake of verifying the correctness of this algorithm.
6.4 Analysis
With the successful implementation of the above protocols, we were able to
experiment and run tests with both implementations. With two main encryption
methods used for different implementations of the same concept, we were able
to compare the efficiency of the two variations.
As the Table 1 shows, efficiency for all of the implemented protocols was
measured in clock cycles. This represents the amount of resources occupied on
each machine throughout the execution of each implementation. We chose this
method of testing, so the results would apply universally to all machines, since
the resources available may affect the actual (calendar) time in which an imple-
mentation executes.
Tests of the protocols for each implementation were run 20 times, to provide
an accurate average of their CPU usage during execution. Clock usage was mea-
sured for only the execution of the code pertaining to the proposed protocols,

not for the setup of the scenario in which they were used. The generation of ran-
dom values to be compared/decomposed and various other non-essentials were
ignored when testing.
Table 1. Party Clock Cycles
Party Secret Sharing SC Secret Sharing SBD Paillier SC Paillier SBD
P1 114967 458592 10124 24701
P2 121037 433747 9559 23211
P3 144744 527766 - -
Total 380747 1420105 19682 47912
Analysis - Secure Comparison Separate implementations of secure compar-
ison had vastly different CPU usage averages. As seen in Table 1, the imple-
mentation of SC for Pallier encryption required less than a tenth of the CPU
resources as the secret sharing alternative. This was attributed mostly to the
inefficiency of our communications with sockets, which the secret sharing im-
plementation requires much more of than the pallier one. However, since both
implementation were using the same methods for communication, the outcome
is still roughly comparable. If the communication method is improved for one,
it is improved for both.
Another benefit of the Pallier implementation for SC was that it required
participation from one less machine. Party 3 for the implementation of this
protocol was only required for setting up the scenario in which a comparison is
used, and in no way participated in the actual comparison of data.
Future work here would involve first and foremost improving the efficiency
of message sending between sockets. This would vastly improve the overall ef-
ficiency of the entire protocols. This improvement would also greatly improve
the comparability of these implementations when judging their viability in real
world usage.
Analysis - Secure Bit Decomposition Implementations of SBD also had
very different CPU usage averages between the two cryptographic schemes. This
is due heavily to the usage of SC in the secret sharing implementation, which
occurs twice. Pallier encryption did not require reuse of SC for its own imple-
mentation of SBD, and required less than 4
As before, improving the method of communication between machines would
greatly improve the efficiency of both implementations, while also improving the
comparability of them. This is where future contributions to our research should
focus first, before solid comparisons and improvements on the implementations
takes place.

7 Conclusion and Future Work
In terms of future work, there is much that can be done; our work saw us only im-
plementing one proposed algorithm for each of the 5 protocols (SC and SBD with
Paillier encryption, and secure multiplication, SC, and SBD with secret sharing)
we explored. Potential future work could begin with exploring other proposed
algorithms for these protocols, perhaps those that are more efficient; addition-
ally, these same protocols could be researched and implemented for encryption
methods besides secret sharing or Paillier encryption. Our goal in our research
was to explore and experiment the underlying functions and protocols behind
secure range queries; however, we never actually experimented with securely
range querying encrypted data. This is another step we can take in our future
work, exploring different range query protocols and implementing them with a
fabricated database of encrypted information. For any future implementation of
protocols in this area of computer science, we could explore and analyze each
method, learning much about operations on encrypted data and potentially dis-
covering certain improvements, however minor, for making the algorithms more
efficient.
While the secure range querying of encrypted data is undoubtedly important
in the field of cloud computing and storage, our ultimate goal was to implement
and analyze the underlying algorithms necessary for range queries to operate,
such as SC and SBD. We succeeded in this goal, and although no errors nor
potential improvements in the algorithms were discovered, we were able to gain a
deeper understanding of mathematical operations on encrypted integers, as well
as verify the validity and correctness of the algorithms. With these protocols
tested, understood, and implemented, the actual application of secure range
queries can be done with remarkable ease and efficiency.
References
1. B. Samanthula, W.Jiang. Efficient Privacy-Preserving Range Queries over En-
crypted Data in Cloud Computing. 2013 IEEE Sixth International Conference on
Cloud Computing,pages 51-58. IEEE, 2013.
2. B. Samanthula, W.Jiang, E. Bertino. Lightweight and Secure Two-Party Range
Queries over Outsourced Encrypted Databases. 2014.
3. I. Damg˚ard, M. Fitzi, E. Kiltz, J. Nielsen, T. Toft. Unconditionally Secure Constant-
Rounds Multi-Party Comparison, Bits and Exponentiation.
4. D. Bogdanov. How to securely perform computations on secret-shared data. 2007.
5. T. Toft. Constant-Rounds, Almost-Linear Bit-Decomposition of Secret Shared Val-
ues. LNCS 5473, pages 357-371. 2009.
Appendix
sendMPZ Code

void sendMPZ( int socket , mpz t X){
char temp [ 1 0 2 4 ] ;
int n ;
bzero (temp , 1024);
mpz get str (temp , 10 , X) ;
n = write ( socket , temp , s t r l e n (temp ) ) ;
n = read ( socket , temp , 1 0 2 3 ) ;
}
receiveMPZ Code
void receiveMPZ ( int socket , mpz t X){
char temp [ 1 0 2 4 ] ;
int n ;
bzero (temp , 1024);
n = read ( socket , temp , 1 0 2 3 ) ;
mpz set str (X, temp , 10);
n = write ( socket , temp , s t r l e n (temp ) ) ;
}
P1 Secret Multiplication Code
void secretMult ( const int party2sock , const int party3sock ,
const mpz t X, const mpz t N, mpz t & P1xy){
// rec eivi ng random #’s r1 and c1 from party3
receiveMPZ ( party3sock , r1 ) ;
receiveMPZ ( party3sock , c1 ) ;
// Xr1sum = X + r1
mpz add (Xr1sum , X, r1 ) ;
// sending / rece ivi ng masked shares to /from party2
sendMPZ( party2sock , Xr1sum ) ;
receiveMPZ ( party2sock , Yr2sum ) ;
// c a l c u l a t i n g value of P1xy
// P1xy = −r1
mpz neg (P1xy , r1 ) ;
// P1xy = −r1 ( y + r2 )
mpz mul(P1xy , P1xy , Yr2sum ) ;
// P1xy = −r1 ( y + r2 ) + c1
mpz add (P1xy , P1xy , c1 ) ;
// P1xy = (−r1 ( y + r2 ) + c1 ) mod N
mpz mod(P1xy , P1xy , N) ;
}

void secretMult ( const int party1sock , const int party3sock ,
const mpz t Y, const mpz t N, mpz t & P2xy){
// rec eivi ng random #’s r2 and r3 from party3
// Yr2sum = Y + r2
mpz add (Yr2sum , Y, r2 ) ;
// rec eivi ng / sending masked shares from/ to party1
receiveMPZ ( party1sock , Xr1sum ) ;
sendMPZ( party1sock , Yr2sum ) ;
// c a l c u l a t i n g value of P2xy
// P2xy = y ( x + r1 )
mpz mul(P2xy , Y, Xr1sum ) ;
// P2xy = y ( x + r1 ) + r3
mpz add (P2xy , P2xy , r3 ) ;
// P2xy = ( y ( x + r1 ) + r3 ) mod N
mpz mod(P2xy , P2xy , N) ;
}
void secretMult ( const int party1sock , const int party2sock ){
// assignment of three random v a r i a b l e s
mpz urandomb( r1 , state , 7 ) ;
// c1 = r1 ∗ r2 − r3
mpz mul( c1 , r1 , r2 ) ; // c1 = r1 ∗ r2
mpz sub ( c1 , c1 , r3 ) ; // c1 = c1 − r3
// sending random #’s r1 and c1 to party1
sendMPZ( party1sock , r1 ) ;
sendMPZ( party1sock , c1 ) ;
// sending random #’s r2 and r3 to party2
}

P1 Secure Multiplication Code
void secureMult ( const int party2sock , const int party3sock ,
mpz t& P1ab , const mpz t a1 , const mpz t b1 ,
const mpz t N){
// c a l c u l a t i n g shares of a1b2 and a2b1
secretMult ( party2sock , party3sock , a1 , N, P1a1b2 ) ;
secretMult ( party2sock , party3sock , b1 , N, P1a2b1 ) ;
// c a l c u l a t i n g P1ab
// P1ab = a1 ∗ b1
mpz mul(P1ab , a1 , b1 ) ;
// P1ab = ( a1 ∗ b1 ) + P1a1b2
mpz add (P1ab , P1ab , P1a1b2 ) ;
// P1ab = ( a1 ∗ b1 ) + P1a1b2 + P1a2b1
// P1ab = [ ( a1 ∗ b1 ) + P1a1b2 + P1a2b1 ] mod N
mpz mod(P1ab , P1ab , N) ;
}
void secureMult ( const int party1sock , const int party3sock ,
mpz t& P2ab , const mpz t a2 , const mpz t b2 ,
const mpz t N){
// c a l c u l a t i n g shares of a1b2 and a2b1
secretMult ( party1sock , party3sock , b2 , N, P2a1b2 ) ;
secretMult ( party1sock , party3sock , a2 , N, P2a2b1 ) ;
// c a l c u l a t i n g P2ab
// P1ab = a2 ∗ b2
mpz mul(P2ab , a2 , b2 ) ;
// P1ab = ( a2 ∗ b2 ) + P2a1b2
// P1ab = ( a2 ∗ b2 ) + P2a1b2 + P2a2b1
// P1ab = [ ( a2 ∗ b2 ) + P2a1b2 + P2a2b1 ] mod N
mpz mod(P2ab , P2ab , N) ;
}
void secureMult ( const int party1sock , const int party2sock ){

secretMult ( party1sock , party2sock ) ;
secretMult ( party1sock , party2sock ) ;
return ;
}
P1 XOR Code
void sharedXOR( const int party2sock , const int party3sock ,
mpz t& P1aXORb, const mpz t N, const mpz t P1A,
const mpz t P1B){
mpz add (temp1 , P1A, P1B ) ; // temp1 = P1A + P1B
// temp2 = P1ab
secureMult ( party2sock , party3sock , temp2 , P1A, P1B, N) ;
// f i n a l c a l c u l a t i o n of P1aXORb
// P1aXORb = 2(P1ab)
mpz mul ui (P1aXORb, temp2 , 2 ) ;
// P1aXORb = P1A + P1B − 2(P1ab)
mpz sub (P1aXORb, temp1 , P1aXORb) ;
// P1aXORb = [ (P1A + P1B) − 2(P1ab ) ] mod N
mpz mod(P1aXORb, P1aXORb, N) ;
}
P2 XOR Code
void sharedXOR( const int party1sock , const int party3sock ,
mpz t& P2aXORb, const mpz t N, const mpz t P2A,
const mpz t P2B){
// temp2 = P2ab
// f i n a l c a l c u l a t i o n of P2aXORb
// P2aXORb = 2(P2ab)
mpz mul ui (P2aXORb, temp2 , 2 ) ;
// P2aXORb = (P2A + P2B) − 2(P2ab)
mpz sub (P2aXORb, temp1 , P2aXORb) ;
// P2aXORb = [ (P2A + P2B) − 2(P2ab ) ] mod N
mpz mod(P2aXORb, P2aXORb, N) ;
}
P1 OR Code

void sharedOR ( const int party2sock , const int party3sock ,
mpz t& P1aORb, const mpz t N, const mpz t P1A,
const mpz t P1B){
// temp2 = P1ab
// f i n a l c a l c u l a t i o n of P1aORb
// P1aORb = (P1A + P1B) − P1AB
mpz sub (P1aORb, temp1 , temp2 ) ;
// P1aORb = [ (P1A + P1B) − P1AB] mod N
mpz mod(P1aORb, P1aORb, N) ;
}
P2 OR Code
void sharedOR ( const int party1sock , const int party3sock ,
mpz t& P2aORb, const mpz t N, const mpz t P2A,
const mpz t P2B){
// temp2 = P2ab
// f i n a l c a l c u l a t i o n of P2aORb
// P2aORb = (P2A + P2B) − P2ab
mpz sub (P2aORb, temp1 , temp2 ) ;
// P2aORb = [ (P2A + P2B) − P2ab ] mod N
mpz mod(P2aORb, P2aORb, N) ;
}
P1 Secret Sharing SC Code
void bitLT ( const int party2sock , const int party3sock ,
const mpz t N, const int bitLength ,
const mpz t P1Abits , const mpz t P1Bbits ,
mpz t & P1bitLT ){
// computing P1aXORb
for ( int i = 0; i < bitLength ; i ++){
sharedXOR( party2sock , party3sock , P1aXORb[ i ] ,
N, P1Abits [ i ] , P1Bbits [ i ] ) ;
}

mpz set (P1preOR [ 0 ] , P1aXORb [ 0 ] ) ;
// computing P1preOR
sharedOR ( party2sock , party3sock , P1preOR [ i ] ,
N, P1aXORb[ i ] , P1preOR [ i −1]);
}
mpz set ( P 1 d i f f I s o [ 0 ] , P1preOR [ 0 ] ) ;
for ( int i = ( bitLength − 1 ) ; i > 0; i −−){
mpz sub ( P 1 d i f f I s o [ i ] , P1preOR [ i ] , P1preOR [ i −1]);
mpz mod( P 1 d i f f I s o [ i ] , P 1 d i f f I s o [ i ] , N) ;
}
secureMult ( party2sock , party3sock , P1binaryLT [ i ] ,
P1Bbits [ i ] , P 1 d i f f I s o [ i ] , N) ;
}
mpz add ( P1bitLT , P1bitLT , P1binaryLT [ i ] ) ;
}
}
P2 Secret Sharing SC Code
void bitLT ( const int party1sock , const int party3sock ,
const mpz t N, const int bitLength ,
const mpz t P2Abits , const mpz t P2Bbits ,
mpz t & P2bitLT ){
// computing P2aXORb
sharedXOR( party1sock , party3sock , P2aXORb[ i ] ,
N, P2Abits [ i ] , P2Bbits [ i ] ) ;
}
mpz set (P2preOR [ 0 ] , P2aXORb [ 0 ] ) ;
// computing P2preOR
sharedOR ( party1sock , party3sock , P2preOR [ i ] ,
N, P2aXORb[ i ] , P2preOR [ i −1]);
}

mpz set ( P 2 d i f f I s o [ 0 ] , P2preOR [ 0 ] ) ;
for ( int i = ( bitLength − 1 ) ; i > 0; i −−){
mpz sub ( P 2 d i f f I s o [ i ] , P2preOR [ i ] , P2preOR [ i −1]);
mpz mod( P 2 d i f f I s o [ i ] , P 2 d i f f I s o [ i ] , N) ;
}
secureMult ( party1sock , party3sock , P2binaryLT [ i ] ,
P2Bbits [ i ] , P 2 d i f f I s o [ i ] , N) ;
}
mpz add ( P2bitLT , P2bitLT , P2binaryLT [ i ] ) ;
}
}
P1 Secret Sharing SBD Code
int main ( int argc , char ∗argv [ ] ) {
// rec eivi ng value of N from party3
receiveMPZ ( party3sock , N) ;
// s e t s g l o b a l b i t length for binary conversions based on N
int bitLength = reqBitLength (N) ;
receiveMPZ ( party3sock , X1 ) ;
// Receiving b i t w i s e share of R
for ( int i = 0; i <= bitLength ; i ++){
receiveMPZ ( party3sock , P1Rbits [ i ] ) ;
}
// Receiving b i t w i s e share of C
receiveMPZ ( party3sock , Cshare1 [ i ] ) ;
}
// receive binary representation of C
receiveMPZ ( party3sock , Cbin [ i ] ) ;
}
// Receiving binary representation of C’

receiveMPZ ( party3sock , Cprimebin [ i ] ) ;
}
//compare r >? c
bitLT ( party2sock , party3sock , N, bitLength +1, Cshare1 , P1Rbits , F1 ) ;
// c a l c u l a t i n g C˜
mpz t tmp ;
for ( int i = 0; i<=bitLength ; i ++){
mpz init (tmp ) ;
mpz sub (tmp , Cprimebin [ i ] , Cbin [ i ] ) ;
mpz mul(tmp , tmp , F1 ) ;
mpz add ( Ctilde1 [ i ] , tmp , Cshare1 [ i ] ) ;
mpz clear (tmp ) ;
}
//computing f i n a l b i t w i s e share of x
for ( int i=bitLength −2; i >0; i −−){
// creates temperary arrays of r mod 2ˆ i
//and c˜ mod 2ˆ i
for ( int j = i ; j > 0; j −−){
mpz set ( tempCtilde1 [ i−j ] , Ctilde1 [ bitLength+1−j ] ) ;
mpz set (tempR1 [ i−j ] , P1Rbits [ bitLength+1−j ] ) ;
}
//comparison , takes place between a l l 3 p a r t i e s
bitLT ( party2sock , party3sock , N, i , tempCtilde1 , tempR1 , u1 ) ;
// converts the b i t w i s e shares to integer shares
// in order to perform basic operations
binToIntShare (cmod1 , tempCtilde1 , i ) ;
binToIntShare (rmod1 , tempR1 , i ) ;
// c a l c u l a t e s Xmod1[ i ] , the share of the
// i t h b i t of x
mpz sub (xmod1 , cmod1 , rmod1 ) ;
mpz pow ui ( twoi , two , i ) ;
mpz mul(u1 , twoi , u1 ) ;
mpz add (xmod1 , xmod1 , u1 ) ;
mpz set (Xmod1[ i ] , xmod1 ) ;
}
//SENDING RESULT

sendMPZ( party3sock , Xmod1[ i ] ) ;
}
}
// rec eivi ng value of N from party3
// s e t s g l o b a l b i t length for binary conversions based on N
receiveMPZ ( party3sock , X2 ) ;
// Receiving b i t w i s e share of R
receiveMPZ ( party3sock , P2Rbits [ i ] ) ;
}
// Receiving b i t w i s e share of C
receiveMPZ ( party3sock , Cshare2 [ i ] ) ;
}
// receive binary representation of C
receiveMPZ ( party3sock , Cbin [ i ] ) ;
}
// Receiving binary representation of C’
receiveMPZ ( party3sock , Cprimebin [ i ] ) ;
}
//compare r >? c
bitLT ( party1sock , party3sock , N, bitLength +1, Cshare2 , P2Rbits , F2 ) ;
// c a l c u l a t i n g C˜
mpz t tmp ;
for ( int i = 0; i<=bitLength ; i ++){
mpz init (tmp ) ;
mpz sub (tmp , Cprimebin [ i ] , Cbin [ i ] ) ;
mpz mul(tmp , tmp , F2 ) ;
mpz add ( Ctilde2 [ i ] , tmp , Cshare2 [ i ] ) ;

mpz clear (tmp ) ;
}
//computing f i n a l b i t w i s e share of x
for ( int i=bitLength −2; i >0; i −−){
// creates temperary arrays of r mod 2ˆ i
//and c˜ mod 2ˆ i
for ( int j = i ; j > 0; j −−){
mpz set ( tempCtilde2 [ i−j ] , Ctilde2 [ bitLength+1−j ] ) ;
mpz set (tempR2 [ i−j ] , P2Rbits [ bitLength+1−j ] ) ;
}
//comparison , takes place between a l l 3 p a r t i e s
bitLT ( party1sock , party3sock , N, i , tempCtilde2 , tempR2 , u2 ) ;
// converts the b i t w i s e shares to integer shares
// in order to perform basic operations
binToIntShare (cmod2 , tempCtilde2 , i ) ;
binToIntShare (rmod2 , tempR2 , i ) ;
// c a l c u l a t e s Xmod2[ i ] , the share of the
// i t h b i t of x
mpz sub (xmod2 , cmod2 , rmod2 ) ;
mpz pow ui ( twoi , two , i ) ;
mpz mul(u2 , twoi , u2 ) ;
mpz add (xmod2 , xmod2 , u2 ) ;
mpz set (Xmod2[ i ] , xmod2 ) ;
}
//SENDING RESULT
sendMPZ( party3sock , Xmod2[ i ] ) ;
}
}
// generating N
generateN (N) ;
// generating X and R
mpz urandomb(X, state , bitLength −2);

mpz urandomm(R, state , N) ;
// create shares of X
decompose (X, X1, X2, N) ;
// send N and shares of x to party 1 and 2
sendMPZ( party1sock , N) ;
sendMPZ( party1sock , X1 ) ;
sendMPZ( party2sock , X2 ) ;
// convert r to binary , creates shares , sends them
bitConvert (R, Rbits , NbitLength ) ;
bitDecompose ( Rbits , NbitLength , P1Rb, P2Rb, N) ;
for ( int i =0; i < NbitLength ; i ++){
sendMPZ( party1sock , P1Rb[ i ] ) ;
sendMPZ( party2sock , P2Rb[ i ] ) ;
}
// c a l c u l a t e s c as x + r mod N
genC(C, X1, X2, P1Rb, P2Rb, N, NbitLength ) ;
// convert c to binary , create shares , sends them
// sends non−shared binary of c as w e l l
bitConvert (C, Cbin , NbitLength ) ;
bitDecompose ( Cbin , NbitLength , Cshare1 , Cshare2 , N) ;
sendMPZ( party1sock , Cshare1 [ i ] ) ;
sendMPZ( party2sock , Cshare2 [ i ] ) ;
}
sendMPZ( party1sock , Cbin [ i ] ) ;
sendMPZ( party2sock , Cbin [ i ] ) ;
}
// c a l c u l a t e C ’ , convert to binary , send to both p a r t i e s
mpz add ( Cprime , C, N) ;
bitConvert ( Cprime , Cprimebin , NbitLength ) ;
sendMPZ( party1sock , Cprimebin [ i ] ) ;
sendMPZ( party2sock , Cprimebin [ i ] ) ;
}
// R >? C comparison
// XOR c a l l

for ( int i = 0; i < NbitLength ; i ++){
secureMult ( party1sock , party2sock ) ;
}
// preOR c a l l
}
// binaryLT c a l l
}
//comparison of u : rmod2i >? c˜mod2i
for ( int j=bitLength −2; j >0; j −−){
// XOR c a l l
for ( int i = 0; i < j ; i ++){
}
// preOR c a l l
for ( int i = 1; i < j ; i ++){
}
// binaryLT c a l l
for ( int i = 0; i < j ; i ++){
}
}
// r e c e i v e s r e s u l t s from both p a r t i e s
receiveMPZ ( party1sock , Xmod1[ i ] ) ;
}
receiveMPZ ( party2sock , Xmod2[ i ] ) ;
}
// modified recombining both shares
//XRES i s the r e s u l t i n g binary value
for ( int i = 0; i<bitLength −1; i ++){
mpz sub (XRES1[ i ] , Xmod1[ bitLength −1−i ] , Xmod1[ bitLength −2−i ] ) ;
mpz sub ( tempfin , Xmod2[ bitLength −1−i ] , Xmod2[ bitLength −2−i ] ) ;

mpz add (XRES1[ i ] , XRES1[ i ] , tempfin ) ;
mpz mod(XRES1[ i ] , XRES1[ i ] , N) ;
mpz pow ui ( twoii , two , bitLength−2−i ) ;
mpz cdiv q (XRES1[ i ] , XRES1[ i ] , twoii ) ;
}
}
P1 Paillier SC Code
// rec eivi ng necessary v a r i a b l e s from party 3
receiveMPZ ( party3sock , g ) ;
mpz mul( nsq , N, N) ;
receiveMPZ ( party3sock , encX ) ;
receiveMPZ ( party3sock , encY ) ;
// e s t a b l i s h i n g b i t length
receiveMPZ ( party3sock , inpBitLen ) ;
sendMPZ( party2sock , inpBitLen ) ;
int SCinLength = mpz get ui ( inpBitLen ) ;
// creating other e s s e n t i a l v a r i a b l e s
mpz sub ui (nmin , N, 1 ) ;
mpz invert ( l , two , N) ;
// Generate random f u n c t i o n a l i t y F
mpz urandomm(F, state , two ) ;
// i f F: x>=y
i f (( mpz cmp ui (F, 0))==0){
mpz powm(Ed, encY , nmin , nsq ) ;
mpz mul(Ed, Ed, encX ) ;
}
// e l s e i f F: y>=x+1
else {
//computes E( x+1)
mpz mul(encX , encX , Eone ) ;
mpz powm(Ed, encX , nmin , nsq ) ;
mpz mul(Ed, Ed, encY ) ;
}
mpz set ( delta , Ed ) ;
//main for loop

for ( int i =1; i<=SCinLength ; i ++){
// randomizes delta , send i t to party 2
mpz urandomm( ri , state , N) ;
encrypt (Er , r i ) ;
mpz mul( tau , delta , Er ) ;
sendMPZ( party2sock , tau ) ;
receiveMPZ ( party2sock , s ) ;
i f ( mpz odd p ( r i )==0) // i f r i s even
mpz set ( Edi , s ) ;
else {
mpz powm( s , s , nmin , nsq ) ;
mpz mul( Edi , Eone , s ) ;
}
// update E(d ’)
i f ( i ==1)
mpz set ( Edprime , Edi ) ;
else {
//temp1 = 2ˆ i −1
//temp2 = E( di )ˆ(2ˆ i −1)
mpz pow ui (temp1 , two , i −1);
mpz powm(temp2 , Edi , temp1 , nsq ) ;
mpz mul( Edprime , Edprime , temp2 ) ;
}
//temp3 = E( di )ˆN−1
mpz powm(temp3 , Edi , nmin , nsq ) ;
mpz mul( phi , delta , temp3 ) ;
mpz powm( delta , phi , l , nsq ) ;
// c a l c u l a t e G’
i f ( i==SCinLength ){
mpz powm(temp4 , Edprime , nmin , nsq ) ;
mpz mul(G, Ed, temp4 ) ;
mpz urandomm( r , state , N) ;
mpz powm(Gprime , G, r , nsq ) ;
}
}
sendMPZ( party2sock , Gprime ) ;
receiveMPZ ( party2sock , Ecprime ) ;
// c a l c u l a t e encrypted r e s u l t based Ecprime

i f ( mpz cmp ui (F, 0)==0)
mpz set (Ec , Ecprime ) ;
else {
mpz powm(temp5 , Ecprime , nmin , nsq ) ;
mpz mul(Ec , Eone , temp5 ) ;
}
sendMPZ( party3sock , Ec ) ;
}
P2 Paillier SC Code
receiveMPZ ( party3sock , lamda ) ;
receiveMPZ ( party3sock , u ) ;
// e s t a b l i s h i n g b i t length
int SCinLength = mpz get ui ( inpBitLen ) ;
//main for loop
for ( int i =1; i<=SCinLength ; i ++){
receiveMPZ ( party1sock , tau ) ;
decrypt ( tauprime , tau ) ;
i f ( mpz odd p ( tauprime)==0) // i f tau ’ i s even
encrypt ( s , zero ) ;
else
encrypt ( s , one ) ;
sendMPZ( party1sock , s ) ;
}
receiveMPZ ( party1sock , Gprime ) ;
decrypt (Dgp , Gprime ) ;
i f ( mpz cmp ui (Dgp , 0)==0) // i f G’ = 0

mpz set ( cprime , one ) ;
else
mpz set ( cprime , zero ) ;
encrypt ( Ecprime , cprime ) ;
sendMPZ( party1sock , Ecprime ) ;
}
P3 Paillier SC Code
// sending necessary v a r i a b l e s to party 1 and 2
sendMPZ( party1sock , g ) ;
sendMPZ( party2sock , lamda ) ;
sendMPZ( party2sock , u ) ;
//randomly generate X and Y
mpz urandomb(X, state , 16);
mpz urandomb(Y, state , 16);
// encrypt x and y , send to party 1
encrypt (encX , X) ;
encrypt (encY , Y) ;
sendMPZ( party1sock , encX ) ;
sendMPZ( party1sock , encY ) ;
// c a l c u l a t e h i g h e s t b i t length between x and y , send to party 1
mpz t BLen ; m p z i n i t s e t u i (BLen , f s i z e ) ;
sendMPZ( party1sock , BLen ) ;
// receive r e s u l t from party 1
receiveMPZ ( party1sock , res ) ;
// decrypt and d i s p l a y r e s u l t
decrypt ( res , res ) ;
cout << ”nF : x>=y : ” ;
mpz out str ( stdout , 10 , res ) ;
}
P1 Paillier SBD Code

receiveMPZ ( party3sock , SBDINPUT) ;
sendMPZ( party2sock , inpBitLen ) ;
// e s t a b l i s h i n g b i t length for for loop
int SBDinLength = mpz get ui ( inpBitLen ) ;
// generating k
int Nlen = reqBitLength (N) ;
m p z i n i t s e t u i (K, Nlen ) ;
mpz init ( Kminl ) ;
mpz sub ui (Kminl , K, SBDinLength ) ;
mpz init (k ) ;
while ( mpz cmp ui (k , 0)==0 | | mpz cmp ui (k , 1)==0)
mpz urandomm(k , state , Kminl ) ;
sendMPZ( party2sock , k ) ;
mpz set (U, SBDINPUT) ;
mpz invert (a , two , N) ;
//main for loop
for ( int i =0; i<SBDinLength ; i ++){
mpz urandomm( rb , state , two ) ;
encrypt (Erb , rb ) ;
mpz mul(L, U, Erb ) ;
mpz powm(Lp , L, a , nsq ) ;
mpz urandomm( r , state , N) ;
encrypt (Er , r ) ;
mpz mul(M, Lp , Er ) ;
// sends to party 2
sendMPZ( party2sock , M) ;
// r e c e i v e s from party 2
receiveMPZ ( party2sock , W) ;
IP ( rk , r , k ) ;
mpz sub ( nrk , N, rk ) ;
encrypt (Enk , nrk ) ;
mpz mul(H, W, Enk ) ;

mpz urandomm( rp , state , N) ;
mpz powm(Hp, H, rp , nsq ) ;
// sends to party 2
sendMPZ( party2sock , Hp) ;
receiveMPZ ( party2sock , B) ;
i f (( mpz cmp ui ( rb , 0))==0)
mpz set (LSBout , B) ;
else {
mpz powm(B, B, nmin , nsq ) ;
encrypt (Eone , one ) ;
mpz mul(LSBout , B, Eone ) ;
}
mpz set (SBDout [ i ] , LSBout ) ;
mpz powm(tmp2 , LSBout , nmin , nsq ) ;
mpz mul(V, U, tmp2 ) ;
mpz powm(U, V, a , nsq ) ;
}
}
receiveMPZ ( party3sock , lamda ) ;
receiveMPZ ( party3sock , u ) ;
int SBDinLength = mpz get ui ( inpBitLen ) ;
// receive k
receiveMPZ ( party1sock , k ) ;
for ( int i =0; i<SBDinLength ; i ++){
// receive from party 1
receiveMPZ ( party1sock , M) ;
decrypt (Mp, M) ;
IP (Mpk, Mp, k ) ;
encrypt (W, Mpk) ;
// send to party 1

sendMPZ( party1sock , W) ;
// receive from party 1
receiveMPZ ( party1sock , Hp) ;
decrypt ( phi , Hp) ;
i f (( mpz cmp ui ( phi , 0))==0)
encrypt (B, zero ) ;
else
encrypt (B, one ) ;
sendMPZ( party1sock , B) ;
}
}
// sending necessary v a r i a b l e s to party 1 and 2
sendMPZ( party2sock , lamda ) ;
sendMPZ( party2sock , u ) ;
// takes input integer x
cout <<” nPlease input a number to decompose : ” ;
cin >> x ;
m p z i n i t s e t u i (GMPx, x ) ;
// encrypts x , sends to party 1
encrypt (encX , GMPx) ;
sendMPZ( party1sock , encX ) ;
// determines b i t length of x , sends to party 1
int bl = reqBitLength (GMPx) ;
sendMPZ( party1sock , BLen ) ;
}

REU Group 2 - Paper

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (14)

Similar to REU Group 2 - Paper

Similar to REU Group 2 - Paper (20)

REU Group 2 - Paper