Constant-Round Client-Aided Secure Comparison Protocol

Abstract

We present an improved constant-round secure two-party protocol for integer comparison functionality, which is one of the most fundamental building blocks in secure computation.

Our protocol is in the so-called client-server model, which is utilized in real-world MPC products such as Sharemind, where any number of clients can create shares of their input and distribute to the servers who then jointly compute over the shares and return the shares of result to the client. In the client-aided client-server model, as mentioned briefly by Mohassel and Zhang (S&P’17), a client further generates and distributes some necessary correlated randomness to servers. Such correlated randomness admits efficient protocols since otherwise servers have to jointly generate randomness by themselves, which can be inefficient.

In this paper, we improve the state-of-the-art constant-round comparison protocols by Damgård et al. (TCC’06) and Nishide and Ohta (PKC’07) in the client-aided model. Our techniques include identifying correlated randomness in these comparison protocols. Along the way, we also use tree-based techniques for a building block, which deviate from the above two works. Our proposed protocol requires only 5 communication rounds, regardless of the bit length of inputs. This is at least 5 times fewer rounds than existing protocols. We implement our secure comparison protocol in C++. Our experimental results show that this low-round complexity benefits in low-latency networks such as WAN.

1 Introduction

Multi-party computation (MPC) is a powerful cryptographic tool often used to achieve privacy-preserving applications such as secure data mining. In general, MPC enables a set of N parties to jointly compute a function, say f, of their private inputs. More precisely, the N parties, each holding private input $x_i$ (for $i = 1,\ldots ,N$), are able to compute the output $F=f(x_1,\ldots ,x_N)$ without having to reveal their private inputs $x_i$. The security of MPC guarantees that a party i will learn nothing about the others’ inputs, namely, $x_j$ for all j not equal to i, except the information that can be derived from the output F and his/her own input $x_i$.

In this paper, we focus on secret-sharing based MPC [13], as opposed to other approaches such as garbled-circuit [24] or (fully) homomorphic encryption. Comparing among these, secret-sharing based MPC normally admits low computational cost and low bandwidth, while it generally requires more round communications. Constructing round-efficient protocols is thus one of the main goals for secret-sharing based MPC.

Secure Comparison Protocols. In this paper, we study integer comparison functionality, which has been considered one of the most fundamental building blocks for MPC since a seminal paper by Yao [24] introduced the Millionaires’ problem, which itself is the starting point for researches on MPC. It has many applications that include auctions, machine learning, data clustering, statistical analysis, applications involving sorting, finding minimum/maximum, to name just a few. Secure comparison protocols have many variants (cf. [2]); in order to be able to flexibly use them as building blocks in larger applications, it is imperative to consider the variant with shared inputs and shared output. More precisely, the inputs to the protocol are shares of x and shares of y, while the output comprises shares of bit b which indicates the result of comparing $x < y$ (note that it is sufficient w.l.o.g. to consider less-than functionality). Throughout the paper, we consider this variant unless stated otherwise.

Despite being such a central functionality, inefficiency of comparison protocols is often a bottleneck for the applications listed above. Such inefficiency inherently stems from the fact that on one hand, applications are arithmetic computations; while, on the other hand, computing integer comparison is a bit string operation by nature, and protocols that compute such bit decompositions often require $\log n$ rounds, where n is the bit length of inputs.

A breakthrough result was proposed by Damgård et al. [7], who came up with the first secret-sharing based comparison protocol that admits constant rounds. Their protocol can be based on any linear secret-sharing based MPC that has multiplication protocol, and require 44 rounds of multiplication protocols (as counted in [15]). When including overall communication such as sharing or revealing phases (see more discussion on this in Sect. 4), in this paper, it can be counted to 79 overall rounds. Nishide and Ohta [15] proposed an improved protocol that has 15 rounds of multiplication protocols, and as counted in this paper, has 28 overall rounds. In this paper, we will improve these constants albeit working in the client-aided client-server model.

MPC in the Client-Server Model. In pushing MPC towards real-world usages, the setting of so-called client-server model for MPC has recently been largely motivated not only by recent researches including Araki et al. [1] but also by commercial-grade MPC products such as Sharemind system by Cybernetica. In such a model, there are N servers and an unbounded number of clients, say t. Each client provides his input $x_i$ by secret-sharing it to the N servers, who will then jointly compute in secure manner over these input shares and return the output $f(x_1,\ldots ,x_t)$ to clients.¹ This setting is suitable in real-world business innovation as the MPC engine run by servers can be thought of “as a service”. In particular, each client only participates at the input phase and simply waits for the output. A program for client can thus contain only a simple and lightweight computation, namely, the secret sharing procedure, and hence makes it possible to be easily employed (e.g., as a tiny script program in web browsers).

Client-Aided Client-Server Model. In the client-aided client-server model, as mentioned briefly by Mohassel and Zhang [14], a client, who distributes shares of its input to servers, further generates and distributes some necessary correlated randomness to servers. Such correlated randomness will be used by the N servers for running a protocol among them. This is for the purpose of better efficiency, since otherwise servers would have to jointly generate randomness by themselves, which can be inefficient. The only downside for this model is the restriction that any server is assumed to not collude with the client who generates such correlated randomness; doing so would break security. But this restriction seems reasonable already in the client-server business model, as a server would normally have no incentive to collude to a client.²

Table 1. Comparison of LessThan protocols in the number of rounds, total communication, and estimated total online execution time

1.1 Our Contribution

Our main contribution is an efficient secure comparison (LessThan) protocol in the client-aided client-server model with two servers (and with an unbounded number of clients). It improves upon the state-of-the-art secure comparison protocols that achieve a constant round complexity. We show a comparison for the number of communication rounds in Table 1, which also shows the total communication and an estimated total time for executing a protocol in a WAN setting (see below). The number of overall rounds for our protocol is 5, which is considerably much lower than the previous schemes (at least 5 times fewer rounds than Nishide-Ohta [15], which requires 28 overall rounds). We also implement our secure comparison protocol in C++. Our experimental results show that this low-round complexity benefits in low-latency networks such as WAN (also see below).

Our Techniques. Our protocol is based loosely on the previous protocols of [15], which is, in turn, based on [7]. Our techniques for reducing rounds consist of the following strategies (described only in a high-level overview):

• We first note that [15] uses the LSB (least significant bit) protocol as a building block. While [7, 15] can use any linear secret sharing with multiplication protocol, we use a specific secret-sharing scheme, namely, the 2-out-of-2 sharing scheme. Note that such a secret scheme is the base for the original MPC by Goldreich et al. [13], which we denote the GMW scheme. This enables us to construct the LSB protocol based on a comparison protocol with plain inputs and shared output, called $\mathsf {PlainLessThan}$ protocol.

• We then construct a protocol for $\mathsf {PlainLessThan}$ by using a tree-based structure called dyadic range, similarly to [2]. This has two advantages. First, such a structure admits parallel computations (hence, is suitable for constant-round protocols). Second, each computation is multi-fan-in AND, which we can construct a constant-round protocol.

• We finally construct a constant-round multi-fan-in AND protocol using the protocol proposed also in [7]. This is the point where we utilize the client-aided setting so that the correlated randomness generation phase is entirely computed by a client. We identify the necessary correlated randomness by removing redundancy in [7]. Our client-aided protocol is more sophisticated than the one in [14], which considers correlated randomness for only a simple multiplication protocol (such randomness is called Beaver multiplication triple [3] in the literature); ours is for the whole multi-fan-in AND protocol.

More details for intuition on our building blocks can be found in Sect. 3.

Better Total-Time Efficiency in WAN. While achieving less rounds, our protocol requires larger asymptotic complexity in total communication: ours is $O(n^2)$, versus $O(n\log n)$ and O(n) in [7, 15], resp., as shown in Table 1. However, when considering concrete real-world parameters and large-delay networks like WAN (Wide Area Network), this does not matter since the total time for transmitting data of any amount up to its capacity will be roughly the same. More precisely, in WAN, we can set the transmission bandwidth to 9 MB/s and the network delay to 72 ms, as done in [14]. Hence, in one round, we can transmit any amount of data up to 9 MB/s $\times$ 72 ms = 648 KB, in roughly the same amount of time (72 ms). For our protocol, when considering $n=32$ bits, the total transmitted data has about $12n^2+301=12589$ field elements; each element has 32 bits, hence the total data has only 402848 bits (50 KB), which is already less than the capacity of 648 KB. Moreover, the local computation time would contribute only negligible time compared to the network delay (see Sect. 5). Therefore, the total (online) time to run the protocol is indeed simply about the one-round time (72 ms) times the number of rounds, as shown in Table 1. We note also that, thanks to the client-aided method, the offline time is kept small compared to the online time (see Table 2). More details can also be found in Appendix B.

1.2 Related Work

Secure comparison protocols have been widely studied since Yao [24] introduced the Millionaire’s protocol. Research on secure comparison protocols have a vast literature, e.g., [4,5,6,7,8,9, 11, 15, 21, 22, 24], and we would like to point the reader to an excellent survey published relatively recently in 2015 by Veugen et al. [23] for a detailed overview, while we briefly mention some more related ones here. As Veugen et al. [23] pointed out, secret sharing based secure comparisons [6, 11, 15] have an advantage in online phase in comparison with garbled circuit based protocols and homomorphic encryption based protocols. Attrapadung et al. [2] categorized various secure comparison protocols regarding their input/output forms. Damgård et al. [7] proposed a constant-round secure comparison scheme and Nishide-Ohta [15] developed the idea to construct fewer rounds secure comparison protocol, on which our protocol is based. We note that, in this paper, we count the round complexity in a strict sense: the communication rounds of revealing or sharing are also included (while, in most of previous papers, only those of multiplication protocols are counted). See more in Sect. 4. This somewhat leads to more round complexities than those in original papers. In subsequent works to [15], some other optimizations have been introduced based on the assumption that the compared values are restricted to be less than $\frac{p-1}{2}$ [16,17,18]. (To free up this restriction, the number of rounds would increase.) Reistad [16] claims that the online round complexity is 2; however, the actual round complexity (in our strict counting) seems to be much greater since similar sub-protocols to those in [15] are used. Their main advantage is, nevertheless, the total linear communication. While our focus is on reducing communication rounds to sufficiently small constant, there exist also logarithmic-round secure comparison protocols in literature (e.g., [10, 20]); our sub-protocols in Sect. 3 might be applicable to reduce the communication rounds in these cases too.

2 Preliminaries and Settings

In this section, we introduce notation and terminology. The general notion for a multi-party protocol to compute a function f and to privately compute a function f in the semi-honest model follows from the standard definition (e.g., [12]).

As a basic terminology throughout the paper, we let p be an odd prime and n be the bit length of p. We represent elements in the prime field $\mathbb {F}_p$ as $\{0, \dots , p-1\}$.

Syntax for Secret Sharing. An N-out-of-N secret sharing scheme over $\mathbb {F}_p$ consists of two algorithms: $\mathsf {Share}$ and $\mathsf {Reveal}$. $\mathsf {Share}$ takes as input $x \in \mathbb {F}_p$, and outputs , where the bracket notation denotes the share of the i-th party. We denote as their shorthand. $\mathsf {Reveal}$ takes as input , and outputs x.

Client-Server Model. We describe the setting for secret-sharing based MPC in the client-server model (similarly to e.g., [1]) as follows. We assume that there exists N servers and an unbounded number of clients, say t. We assume that there exists a secure channel between any client and any server, and among any two servers (Note that a secure channel among clients are not needed).

Let S be an N-out-of-N secret sharing scheme over $\mathbb {F}_p$. We say that a protocol $\varPi$ computes a function $f:\mathbb {A}^t \rightarrow \mathbb {B}$ in the client-server model with a secret sharing scheme S if $\varPi$ proceeds as follows.

• 1. In the first pass, each client j (for $j\in [1,t]$) creates shares of its input $a_j \in \mathbb {A}$ as . It then distributes to the server i (for $i\in [1,N]$).

• 2. All the N servers jointly compute f over their shares. More precisely, in this joint protocol, the input from the server i is . Let $b=f(a_1,\ldots ,a_t)$. The output for the server i in this joint protocol is the share . We abuse the notation of f and write this protocol as

  

• 3. In the final pass, each server i (for $i\in [1,N]$) returns to all the clients. Each client can recover b by .

Note that such a protocol setting is a specific case of $(N+t)$-party protocols, where N parties among these do not have input, and t parties among these participate only the first pass (for sending) and the final pass (for receiving). Therefore, the security notion in the semi-honest model follows from the standard notion of private computation (e.g., [12]).

Client-Aided Client-Server Model. The client-aided setting (similarly to [14]) further specializes the above setting by allowing the following:

• A fixed client, w.l.o.g. say client number 1 (but could be any), will additionally send an auxiliary input $\mathsf {aux}_i$ to the server i (for all $i\in [1,N]$). The distribution of auxiliary inputs can be done offline or at the same time as the first pass in the client-server model described above. We denote $\mathsf {aux}=(\mathsf {aux}_1,\ldots ,\mathsf {aux}_N)$.

• In the joint computation for f, each server i can input its auxiliary input $\mathsf {aux}_i$. We write this protocol as , where we also often omit explicitly writing $\mathsf {aux}$ when the context is clear.

We assume that the client that generates auxiliary inputs is honest and does not collude with any servers. As a remark, this setting can be considered as the trusted initializer model [19] where the “trusted initializer” in our case is one of the t clients.

In this paper, we consider two servers, that is, $N=2$. Hence, in particular, we only allow the adversary to corrupt only one server. We use the standard 2-out-of-2 secret sharing scheme defined by

• $\mathsf {Share}(x)$: randomly choose $r\in \mathbb {F}_p$ and let and .

• : output .

We note that this is the secret sharing scheme used in the original MPC by Goldreich, Micali, and Widgerson [13], hence we often call it the GMW-style two-party secret sharing scheme. In this scheme, we have protocols for fundamental operations: $\mathsf {ADD}(x,y):=x+y$ and $\mathsf {MULT}(x,y):=xy$ as follows:

• can be done locally by simply adding its own share on x and on y.

• can be done in various ways. We will use the standard method based on Beaver multiplication triples [3]. Such a triple consists of $\mathsf {aux}_1=(a_1,b_1,c_1)$ and $\mathsf {aux}_2=(a_2,b_2,c_2)$ such that $(a_1 + a_2)(b_1 + b_2)=c_1 + c_2$. In particular, we can use the client-aided method to let a client generate and distribute $\mathsf {aux}_1$ and $\mathsf {aux}_2$ to the two servers, respectively.

We abuse notations and write the $\mathsf {ADD}$ protocol simply as , and $\mathsf {MULT}$ protocols simply as . Note that multiplication with constant c can use the $\mathsf {ADD}$ protocol, and we write .

3 Our Secure Comparison Protocol

In this section, we present our protocol for computing the less-than comparison functionality, $\mathsf {LessThan}$. It consists of various sub-protocols, which might be of independent interest in their own right, that we also present in this section. These consist of the following.

• $\mathsf {MULT}^*$: multi-input multiplication functionality.

• $\mathsf {AND}^*$: multi-fan-in AND functionality.

• $\mathsf {PlainEqual}$: equality test functionality with plain inputs.

• $\mathsf {PlainLessThan}$: less-than comparison functionality with plain inputs.

• $\mathsf {WrapAround}$: a functionality for testing if the addition of the two shares (in the integers, without modulo p) is more than p or not (wrap** around p or not).

• $\mathsf {LSB}$: least-significant-bit functionality.

• $\mathsf {HalfTest}$: a functionality for testing if a (shared) input is less than p/2 or not.

We remark that all of these functionality except two have shared inputs and shared output. (Definitions for each functionality will be provided below.) The only two exceptions are $\mathsf {PlainEqual}$ and $\mathsf {PlainLessThan}$, where inputs consist of plain values that are private to each party.

Outline of Our Protocol for $\mathsf {LessThan}$. We will use the functionality for $\mathsf {HalfTest}$ to construct $\mathsf {LessThan}$, and $\mathsf {LSB}$ to construct $\mathsf {HalfTest}$ in exactly the same manner as in [15]. To construct a protocol for $\mathsf {LSB}$, we will use $\mathsf {WrapAround}$, which is then constructed based on $\mathsf {PlainLessThan}$. This is different to the construction of $\mathsf {LSB}$ in [15]. Our protocol for $\mathsf {PlainLessThan}$ is based on binary tree structure, which admits parallel computation (and hence use small constant rounds of communication). This is somewhat related to the protocol in [2], with the difference that here our protocol uses secret sharing, while [2] uses homomorphic encryption. $\mathsf {PlainLessThan}$ uses $\mathsf {PlainEqual}$ as a subroutine. $\mathsf {PlainEqual}$ then uses the multi-fan-in AND, namely, $\mathsf {AND}^*$, as a subroutine. $\mathsf {AND}^*$ is then based on the multi-input multiplication, namely, $\mathsf {MULT}^*$, in a similar manner to [7]. Finally, $\mathsf {MULT}^*$ is constructed based on using correlated randomness produced by the aiding party.

3.1 Multi-input Multiplication Protocol ($\mathsf {MULT}^*$)

We first describe the smallest building block (besides $\mathsf {ADD}$, $\mathsf {MULT}$), namely, the multi-input multiplication functionality, $\mathsf {MULT}^*$. Its definition is the computation protocol as follows.

where we define $c_i := x_1 x_2 \cdots x_i$ for all $i\in [1,\ell ]$.

Intuition/Approach. Our protocol follows the basic mechanism of the protocol for $\mathsf {MULT}^*$ in [7]. The protocol of [7] lets parties collaborate and produce shares of random elements, say $t_j$, and its inverse, namely, $t_j^{-1}$. Such procedures are somewhat costly. Our idea is to gather and optimize all these correlated randomness elements in one place and let it be generated by an aiding party. For example, the “chaining” like $q_j:=t_{j-1} t_j^{-1}$ will be pre-computed. Moreover, the protocol of [7] can be used for any linear secret sharing scheme with $\mathsf {MULT}$ protocol. When using a $\mathsf {MULT}$ protocol that uses multiplication triples, the correlated randomness for $\mathsf {MULT}$ will become redundant with those $t_j,t_j^{-1}$. We eliminate these redundancy by generating multiplication triples directly over $q_j$ defined as above, and not an independent randomness.

Correlated Randomness for $\mathsf {MULT}^*$. The aiding party locally pre-computes the following:

• 1. For all $j\in [0,\ell ]$, pick , and also compute its inverse, $t_j^{-1}$.

• 2. For all $j\in [1,\ell ]$, define $q_j:= t_{j-1} t_j^{-1}$, $z_j:= t_0^{-1} t_j$, and also pick $a_j \in \mathbb {F}_p^\times$.

• 3. Set the correlated randomness for $P_1$ and $P_2$ to be the following random shares:

  

  (1)

Our Protocol for $\mathsf {MULT}^*$. We show our protocol for $\mathsf {MULT}^*$ in Algorithm 1.

Correctness/Security. The protocol correctness can be shown by verifying Eq. (2), which is indeed correct since $d_1\cdots d_j \cdot {z_j}= (x_1 q_1) \cdots (x_j q_j) \cdot t_0^{-1} t_j = x_1 \cdots x_j \cdot (t_0 t_1^{-1}) \cdot (t_1 t_2^{-1}) \cdots (t_{j-1} t_j^{-1}) \cdot t_0^{-1} t_j x_1 \cdots x_j = c_j$. We sketch an argument for security as follows. We observe that the only points where potential information leak may occur are the revealing of $x_j-a_j$ and of $x_j q_j$. However, $a_j$ and $q_j$ are used only once, and hence they act as one-time pad to $x_j$ (additively and multiplicatively, respectively). More precisely, in $x_j q_j$, the value $x_j$ is multiplicatively blinded by $t_j^{-1}$. Note also that $a_j$ and $q_j$ are available to the parties as shares, hence no information on $a_j$ and $q_j$ leaks either. To prove more formally from this argument in the standard simulator-based notion (e.g., [12]), we just define a simulator that simply simulates the view in the step 1 and 2 of the protocol by random elements. This simulated view is indistinguishable from the real protocol view exactly by the one-time use of $a_j$ and $q_j$.

A Special Case: $\mathsf {Power}$. For further use, we also define a special case of $\mathsf {MULT}^*$ where all the inputs $x_j$ are the same, say x. It thus computes powers of an element x. For formality, we write

3.2 Multi-fan-in AND ($\mathsf {AND}^*$)

We next describe the multi-fan-in AND functionality and a protocol for it below. This is defined by .

Intuition/Approach. We construct this protocol based on $\mathsf {MULT}^*$ (or more precisely, $\mathsf {Power}$) using exactly the approach for symmetric function evaluation in [7]. In such a function, the output depends only on the number of 1’s in its input. Hence, it can be interpreted as a function with input $\sum _{j=1}^m y_j$. (To exclude it being 0 which is problematic, we will add 1 to it, similarly to [7, 15].) This function can be constructed via Lagrange interpolation. In the case of the multi-fan-in AND functionality, its corresponding interpolated function (with coefficient $c_k \in \mathbb {F}_p$) is defined by

$$\begin{aligned} p_m(x) = \frac{1}{m!}\prod _{j=1}^m (x-j) \bmod p =: \sum _{k=0}^m c_k x^k. \end{aligned}$$

(3)

Our Protocol for $\mathsf {AND}^*$. We show our protocol for $\mathsf {AND}^*$ in Algorithm 2.

Correctness/Security. We can verify that $v = y_1 \wedge \cdots \wedge y_m$ as follows: First, the AND function is a symmetric function and thus the output depends only on the value $x:=1+ \sum _{j=1}^m y_j$. In particular, we have that

$$\begin{aligned} y_1 \wedge \cdots \wedge y_m = {\left\{ \begin{array}{ll} 0 &{} \text { if } x \in [1,m] \\ 1 &{} \text { if } x=m+1 \end{array}\right. }. \end{aligned}$$

The Lagrange interpolation of the polynomial defined on these $m+1$ points are indeed the polynomial in Eq. (3). That is, $y_1 \wedge \cdots \wedge y_m = \sum _{k=0}^m c_k x^k$, and hence $v = y_1 \wedge \cdots \wedge y_m$, as required. As for security, it holds straightforwardly since we only call $\mathsf {Power}$ as a subroutine.

3.3 Equality Test with Plain Inputs ($\mathsf {PlainEqual}$)

We next describe the equality test functionality with plain inputs (and shared output). This is defined by where $\delta = 1$ if $x = y$, and $\delta = 0$ otherwise.

Intuition/Approach. We construct this protocol in straightforward way. To confirm equality of x and y, we check if the i-th bit of x, namely $x_i$, equals the i-th bit of y, namely $y_i$. Instead of sharing each bit, we let the share of the other party be 0 so as to save communication.³

Our Protocol for $\mathsf {PlainEqual}$. We show our protocol for $\mathsf {PlainEqual}$ in Algorithm 3.

Correctness/Security. If $x = y$, the i-th bit of x matches the i-th bit of y, that is, $x_i = y_i$ for $i \in [0, n-1]$, where $x=x_{n-1}\,\Vert \,x_{n-2}\,\Vert \,\dots \,\Vert \,x_0$ and $y=y_{n-1}\,\Vert \,y_{n-2}\,\Vert \,\dots \,\Vert \,y_0$ for $x_i, y_i \in \mathbb {Z}_2$. We set for $i \in [0, n-1]$. This value is 1 if $x_i = y_1$, and 0 otherwise. Now, we obtain that $x = y$ if and only if $v_i = 1$ for all $i \in [0, n-1]$.

As for security, it holds straightforwardly since we only call $\mathsf {AND}^*$ as a subroutine.

3.4 Less-Than Comparison with Plain Inputs ($\mathsf {PlainLessThan}$)

We describe the less-than comparison with plain inputs and a protocol for it below. This is defined by where the inputs are $x, y\in [0,p-1]$, and the output bit is $\delta =(x < y)$.⁴

Intuition/Approach. We construct a protocol for $\mathsf {PlainLessThan}$ based on binary-tree-based approach called dyadic range in a similar manner to [2]. The main idea of this tree-based approach is that when the inputs are plain, we can directly “encode” them to a data structure that is suitable for comparison in parallel. This encoding method is called range and point encoding in [2]. At the core of this approach is the equality test functionality over plain inputs. For this equality test, [2] uses additive homomorphic encryption. On the other hand, we construct this functionality by secret sharing, which is more computationally efficient; this is the main difference to [2]. As described above, our equality test essentially uses multi-fan-in AND as a building block.

Range/Point Encoding. We use a similar terminology from [2], which we recall here. Recall first that n is the bit length of p, that is, $n=\lceil \log _2 p \rceil$. Hence, in particular, $x,y \le p-1 < 2^n-1$. Let $\mathbb {T}_{2^n}$ be a complete binary tree whose leaves correspond to integers from 0 to $2^n-1$. Let $\mathbb {S}_{2^n}$ be the set of all nodes in the tree $\mathbb {T}_{2^n}$ and a node $w_{i, j}$ represents a pair of its layer and its index: (i, j) for $i \in [0, n]$ and $j\in [0, 2^{n-i}-1]$. We identify a value $x\in \mathbb {Z}_{p}$ with a node (0, x). Consider a range $R = [u, v]$ for $0\le u \le v \le 2^n-1$. For any range R, a node $w_{i, j} \in \mathbb {S}_{2^n}$ is called a cover node of R if all the descendant leaves of $w_{i, j}$ are in R. We write the set of such nodes as $\textsf {cover}(R)$. For $w_{i, j}\in \mathbb {S}_{2^n}$ with $(i, j)\ne (n, 0)$, let $\textsf {parent}(w_{i, j})$ be the parent node of $w_{i,j}$. The range and point encodings are then defined as follows. For a range $R = [u, v]$ with $0\le u \le v \le 2^n-1$, we let

$$\begin{aligned} \textsf {rangeEnc}(R) := \{(i, a_i )\in \mathbb {S}_{2^n}\mid (i, a_i ) \in \textsf {cover}(R), \textsf {parent}(i, a_i)\not \in \textsf {cover}(R)\}. \end{aligned}$$

For a point $x \in [0, p-1]$, we let $\textsf {pointEnc}(x)$ be the set of all ancestors of a node (0, x) in $\mathbb {T}_{2^n}$ including the node (0, x) itself. An example for point and range encoding is illustrated in Figs. 1 and 2, respectively. The main property is as follows: if for any range R, and any point $x \in [0, p-1]$, we have $|\textsf {rangeEnc}(R) \cap \textsf {pointEnc}(x)|$ equals to 1 if $x\in R$, and equals to 0 if $x \not \in R$.

Note that we set the range R to reach the furthest to the right, i.e., $v=2^{n}-1$, in our setting, which leads that $\textsf {rangeEnc}(R)$ has no more than one node in each layer.

Fig. 1.

Example of point encoding for $x=5$. Here, $\mathsf {pointEnc}(5) = \{ (0,5), (1,2), (2,1), (3,0)\}$.

Fig. 2.

Example of range encoding for $x = 2$, which defines the range $R=[3,7]$. Here, $\mathsf {rangeEnc}([3,7])= \{ (0,3),(2,1) \}$.

Our Protocol for $\mathsf {PlainLessThan}$. We show our protocol for $\mathsf {PlainLessThan}$ in Algorithm 4.

Correctness/Security. Suppose $x < y$. Hence, we have $y \in R=[x+1, 2^n-1]$. Therefore, by the property of encodings, we have that exactly one element in $\textsf {pointEnc}(y)$ equals to an element in $\textsf {rangeEnc}(y)$. To perform OR over these equality tests for each layer, we simply sum their results up (as in Step 6). Note that, similarly to [2], Step 3 is for creating a dummy for all layers that are not contained in the range encoding of R. We can use the unused value $2^n-1$ since $x,y < 2^n-1$. Consequently, the equality tests corresponding to these layers always return false; we need them so that the number of layers to perform equality test will always be the same, namely, $n+1$ layers (so as to ensure that there will be no additional information on the range R). As for security, it holds straightforwardly since we only call $\mathsf {PlainEqual}$ as a subroutine protocol (and note that $\textsf {rangeEnc}$ and $\textsf {pointEnc}$ are local algorithms).

3.5 WrapAround

We now describe a functionality that represents whether a reconstructed share wrap-arounds p. Its definition is as follows:

where $y = 1$ if computed over $\mathbb {Z}$, and $y =0$ otherwise.

Intuition/Approach. In this protocol, $P_1$ inputs , while $P_2$ inputs , and the output is a share where

where the sum is over the integers (i.e., not modulo p).

Our Protocol for $\mathsf {WrapAround}$. A protocol for the wrap-around functionality can be done by simply computing .

Correctness/Security. The correctness holds since . As for security, it holds straightforwardly since we only call $\mathsf {PlainLessThan}$ as a subroutine.

3.6 Least Significant Bit

We describe the least significant bit functionality. This is defined by where $(x)_0 := x \bmod 2$ is the LSB of x.

Intuition/Approach. The least significant bit can be evaluated by using LSB of shares and a flag representing a bit flip.

Our Protocol for $\mathsf {LSB}$. Algorithm 5 presents our $\mathsf {LSB}$ protocol.

Correctness/Security. We can verify that

As for security, it holds straightforwardly since we only call $\mathsf {WrapAround}$ and $\mathbf {XOR}$ as subroutines.

Note that this protocol can be run in 4 rounds. Step 1–2 takes 2 rounds, and can be run in parallel with Step 3 (3 rounds). Step 4 takes 1 round. Thus, it is 4 rounds in total, and its total communication is $4n^2 +5$.

3.7 HalfTest

We describe a functionality that checks if the input is less than half of p as in [15]. This is defined by where $z=(x < \frac{p}{2})$.

Our Protocol for $\mathsf {HalfTest}$. As in Nishide-Ohta [15], this can be done by

(4)

Correctness/Security. Security holds straightforwardly since we only call $\mathsf {LSB}$ as a subroutine.

3.8 Less-Than Comparison

Finally, we describe our less-than comparison functionality and a protocol for it. This is defined by where $z=(x < y)$.

Intuition/Approach. As shown in [15], we construct the $\mathsf {LessThan}$ protocol using $\mathsf {HalfTest}$ as a subroutine.

Our Protocol for $\mathsf {LessThan}$. As shown in Nishide-Ohta [15], when we set $h_x := (x < \frac{p}{2})$, $h_y := (y < \frac{p}{2})$ and $h := (x-y \bmod p < \frac{p}{2})$, the required output can be computed as in the following equality relation:

$$\begin{aligned} z=h_x(1-h_y) + (1-h_x)(1-h_y)(1-h) + h_x h_y (1-h). \end{aligned}$$

(5)

For formality, we capture this protocol in Algorithm 6.

Correctness/Security. As for security, it holds straightforwardly since we only call $\mathsf {HalfTest}$ as a subroutine.

4 Theoretical Efficiency

The efficiency of our protocol is measured in two aspects: round complexity and total communications. In literature, the round complexity is examined by the chain of multiplication protocols, and the total communication is examined by total invocations of multiplication protocols. However, any procedure that needs communication with other parties are crucial for execution time. Therefore, we count any communication such as “reveal”, “send”, or “share” as one round, which have been ignored in previous work. Thus, our rigid measurement counts up more rounds than that of previous work. In Table 1, we analyze previous constant-rounds secure comparison protocols from Damgård et al. [7] and Nishide-Ohta [15]. Moreover, we reconsider their protocols in the client-aided model and show that the rounds will be fewer in the model. We also show the result of our 6 rounds secure comparison protocol and its reduced round version.

Damgård et al.’s original secure comparison protocol [7] needs 79 rounds and total communication of $272n\log {n} + 138n + 22 \log {n}+24(\log {n})^2 + 24n\log {\log {n}}+12$ field elements, since the protocol consists of two Bits protocols (69 rounds and ${136n\log {n} + 56n +8 \log {n}+ 12(\log {n})^2 +12n\log {\log {n}}+6}$ total communications per Bits) and Bit-LT protocol (13 rounds including 3 rounds for random generation and ${26 n + 6 \log {n}}$ total communications). Similarly, Nishide-Ohta’s original secure comparison protocol [15] needs 28 rounds and total communication of $168n + 36\log {n} + 16$, since the protocol consists of 3 $\mathsf {LSB}$ protocols (in parallel) and 2 $\mathsf {MULT}$ protocols, where $\mathsf {LSB}$ is 26 rounds and $32n + 40\log {n}$ total communications and $\mathsf {MULT}$ is 1 round and 2 total communications.

In the client-aided model, we can omit procedures of generating randomness so that Bits will be 60 rounds and total communications will be ${52 n\log {n}+16n + 5\log {n} + 10(\log {n})^2 + 10n\log {\log {n}}}$, while Bit-LT will be 10 rounds and ${12n + 5\log {n}}$ total communications. This let Damgård et al.’s protocol be 70 rounds and ${144n\log {n} + 52n + 64\log {n} + 64(\log {n})^2 + 64 n \log {\log {n}} -6}$ total communications. Similarly, $\mathsf {LSB}$ will be 12 rounds and ${12n + 5\log {n}+3}$ total communications in the client-aided model, which makes Nishide-Ohta’s secure comparison protocol 14 rounds and $36n + 15\log {n} + 13$ total communications.

Our secure comparison protocol $\mathsf {LessThan}$ consists of three $\mathsf {HalfTest}$ (more precisely, $\mathsf {LSB}$ that is 4 rounds and ${4n^2 + 5}$ total communications as explained in Sect. 3.6) protocols and a degree-3 polynomial (more precisely, 5 $\mathsf {MULT}$, which has 10 total communications). Naïvely computing the polynomial (without merging the same computations), our protocol has 6 rounds and at most $12n^2 + 25$ total communications.

Further Reducing Rounds. We can combine the step 4 of the LSB protocol and Eqs. (4) to (5) to a degree-6 polynomial. Since each variable is 0 or 1 shared in $\mathbb {Z}_p$, multiplications can be done by $\mathsf {AND}^*$ protocol in 2 rounds. This results in a LessThan protocol with 5 rounds. The maximum transmitting data amount in one round is within the limitation assumed in our WAN setting. See Appendix A for more details.

Table 2. Execution times of protocols

5 Experimental Efficiency

In this section, we give performance evaluation of our secure comparison protocol $\mathsf {LessThan}$ based on our experiments. For the evaluation, we implement the protocol in C++ programming language using a desktop PC (Xeon E5-2699 v4, 2.20 GHz), Linux Ubuntu 16.04.3 LTS, and a compiler GCC version 5.4.0. Throughout the experiments, we set the prime number $p = 4294967291 = 2^{32} - 5$. Note that our proposed algorithms are independent from the choice of the prime number. Also note that the architecture we used supports 64 bits instruction set, and as shown above, the bit length of p is 32; thus it is unnecessary to use multi-precision arithmetic. To implement our protocol, we do not use assembler, any optimization technique by hand, and any optimized arithmetic software library. We use a special file “/dev/urandom” to implement cryptographically secure pseudorandom number generator, and optimizations by the compiler with an option “-O3.” From this implementation, we evaluate computational time of our protocols, the number of communication rounds, and communication sizes. Based on them, we further estimate the total execution time assuming that the two servers are connected via Wide Area Network (WAN) whose bandwidth and network delay are the same as those in [14] (Namely, we set the bandwidth to be 9 MB/s and the network delay to be 72 ms).

Table 2 shows the execution times of our $\mathsf {LessThan}$ protocol and its subroutines. The column of “Offline” represents time for a client to generate multiplication triples and correlated randomness, and the column “Online Comp.” represents the computation time of each protocol without communication. The column “Estimated Online Comm.” represents the estimated communication time of each protocol by using the assumption described above. Namely, it takes 72 ms per a round. The column “Estimated Online Total” represents the estimated total execution time which is the sum of “Online Comp.” and “Estimated Online Comm”. For taking the execution times, we set the numbers of inputs of protocols $\mathsf {MULT}^*$, $\mathsf {Power}$, and $\mathsf {AND}^*$ as 32 (i.e., in Algorithm 1, $\ell = 32$, and in Algorithm 2, $m = 32$). We note that in the total execution time, network delay is the dominant factor, and compared to this, influence of computational time and communication size is almost ignorable. Therefore, it is important that the number of communication rounds should be reduced as much as possible when combining a secure comparison protocol to construct concrete applications. For reducing the round complexity, our proposed algorithms can be adopted to the vectorization (i.e., operating on vectors) same as in [14] and batch execution techniques.

Appendices

A Further Round-Reduced LessThan Protocol

As we mentioned in Sect. 4, our $\mathsf {LessThan}$ protocol can be executed in 5 rounds as follows: We can combine the step 4 of the $\mathsf {LSB}$ protocol and Eqs. (4) to (5) to a degree-6 polynomial. In particular, this technique breaks down our $\mathsf {LessThan}$ to three $\mathsf {LSBish}$ protocols (3 rounds and $4n^2 +3$ total communications) and a degree-6 polynomial F defined below: $F = w + v - w_xw - w_xv - wv_x -v_xv+ w_y - w_yw -w_yv- w_xw_y - w_yv_x + v_y - wv_y - v_yv - w_xv_y - v_xv_y +2(- wv + w_xwv + w_ywv + w_xw_yw+w_xw_yv + w_ywv_x + w_yv_xv +wv_xv +w_xwv_x + w_xv_xv + w_xw_yv_x + wv_yv + w_xwv_y + w_xv_yv + wv_xv_y + v_xv_yv + w_xv_xv_y- w_yv_y + w_ywv_y + w_yv_yv+ w_xw_yv_y + w_yv_xv_y) + 4(- w_xwv_xv - w_xw_ywv - w_ywv_xv - w_xw_ywv_x - w_xw_yv_xv - wv_xv_yv - w_xwv_xv_y - w_xv_xv_yv -w_ywv_yv - w_xw_ywv_y - w_yv_xv_yv - w_ywv_xv_y - w_xw_yv_yv - w_xw_yv_xv_y -v_yw_xwv) + 8( w_xw_ywv_xv + w_xwv_xv_yv + w_xw_ywv_yv + w_ywv_xv_yv+ w_xw_ywv_xv_y + w_xw_yv_xv_yv)- 16w_xw_ywv_xv_yv.$

The function F contains 13 degree-2, 26 degree-3, 15 degree-4, 6 degree-5, and 1 degree-6 terms, which can be computed in 2 rounds and 292 total communications. Since each variable is 0 or 1 shared in $\mathbb {Z}_p$, multiplications of the function F can be done by $\mathsf {AND}^*$ protocol in 2 rounds. This results in a LessThan protocol with 5 rounds and the total communication is $3(4n^2 + 3)+292 = 12n^2 + 301$.

B Round Complexity and Communication Complexity

In Table 3, we put round complexity and total communications of each protocol from [7, 15]. In Table 4, we show round complexity and total communication of our $\mathsf {LessThan}$ protocol and its subroutines. These are used for calculating rounds and total communication in Table 1. We note that a more detailed value for total communication of the Damgård et al. [7] protocol is $176n\log {n} + 70n + 84 \log {n}+80(\log {n})^2 + 80n\log {\log {n}}-6$ (which is reduced to $144 n \log {n} + 52n +64\log {n} + 64(\log {n})^2+ 64n\log {\log {n}}-6$ for the client-aided version).

Table 3. Number of rounds and total communication of each protocol from [7, 15]

One might wonder if the amount of transmitting field elements during any round exceeds the limitation, i.e., 9 MB/s $\times$ 72 ms = 648 KB. If the amount of transmitting data (elements of $\mathbb {F}_p$) exceeded the limitation, the protocol would need extra rounds to send all the data. In our $\mathsf {LessThan}$ protocol, a larger amount of data is needed during executing $\mathsf {PlainLessThan}$ protocol, more specifically n $\mathsf {PlainEqual}$ protocols in parallel. This protocol sends at most $2n^2$ field elements at one round. This leads to that our $\mathsf {LessThan}$ sends at most $6n^2$ field elements, since it run three $\mathsf {HalfTest}$ (constructed by $\mathsf {WrapAround}$ that has $\mathsf {PlainLessThan}$ as subroutine) protocols at once. When p is 32-bit prime, i.e., $n = 32$, our $\mathsf {LessThan}$ protocol sends at most $6144 = 6\times {32}^2$ field elements (196608 bits) in one round, which is less than the limitation; 648 KB.

Table 4. Number of rounds and total communication of our $\mathsf {LessThan}$ protocol and its subroutines