A Method for Securely Comparing Integers using Binary Trees

In this paper, we propose a new protocol for secure integer comparison which consists of parties having each a private integer. The goal of the computation is to compare both integers securely and reveal to the parties a single bit that tells which integer is larger. Nothing more should be revealed. To achieve a low communication overhead, this can be done by using homomorphic encryption (HE). Our protocol relies on binary decision trees that is a special case of branching programs and can be implemented using HE. We assume a client-server setting where each party holds one of the integers, the client also holds the private key of a homomorphic encryption scheme and the evaluation is done by the server. In this setting, our protocol outperforms the original DGK protocol of Damgård et al. and reduces the running time by at least 45%. In the case where both inputs are encrypted, our scheme reduces the running time of a variant of DGK by 63%.


INTRODUCTION
Multi-party computation (MPC) is a cryptographic technique that allows several parties to compute a function on their private inputs without revealing any information other than the function's output [5,21,[27][28][29]. A classic example in the literature is the so-called Yao's Millionaire's problem introduced in [53]. Two millionaires are interested in knowing which of them is richer without revealing their actual wealth. Formally, let there be two parties 1 , 2 with private input , respectively. The goal of the computation is to compute and reveal = [ ≥ ] to the parties and nothing else. This is illustrated in Figure 1.
Integer comparison is one of the basic arithmetic operations in computer programming and algorithm design. Secure integer comparison is therefore necessary in many privacy-preserving computations. In machine learning, private integers must be compared securely while evaluating classifiers such as decision trees [42,45,46,51] or neural networks. In secure enterprise benchmarking [48], key performance indicators are securely compared to determine how companies perform compared to their competitors. In secure auction [8,9], bids are privately compared to determine the winner. Secure integer comparison has application in different privacy-preserving analytics. In the following, the party with input is the client and the party with input is the server. The idea of our solution consists of having the server construct a binary tree that represents . Then, the client encrypts using a homomorphic encryption scheme and let the server evaluate on the tree representing . Finally, the client receives the result of the computation and decrypts it. Depending on the use case, the client can send the result to the server or they could both get a share of the final result. Furthermore, there are two variants of the protocol. The first (basic) variant utilizes the input of the server in plaintext, the second variant requires both inputs to be encrypted. We compare our results of the first variant to the original DGK protocol [18] and reduce the running time by 45%. Compared to an optimization of the DGK protocol proposed by Veugen [49], we can reduce the running time by about 10% for the first variant. However, for the second variant in which both inputs are encrypted we achieve a reduction of more than 63%.
In total, our contributions are: We propose a new protocol for secure integer comparison based on binary trees. We present two instantiations of our protocol using FHE and AHE. We extend our protocol to handle shared output bit, encrypted inputs and less than comparison. We give a theoretical analysis including specifications for the two variants and their complexity implications. We implement and evaluate both variants.
The remainder of the paper is structured as follows. We review preliminaries in Section 2 and related work in Section 3. Section 4 defines correctness and security of the functionality. We describe our protocol and its algorithms in Section 5 and present some extensions in Section 6. Section 8 gives details about our implementation and evaluation results.

PRELIMINARIES
Homomorphic encryption (HE) allows computations on ciphertexts by generating an encrypted result whose decryption matches the result of a function on the plaintexts [12,25].
HE Algorithms. An HE scheme consists of the following algorithms: • pk, sk, ek ← KGen( ): This probabilistic algorithm takes a security parameter and outputs public, private, and evaluation keys pk, sk, and ek. • c ← Enc(pk, m): This algorithm takes pk and a message m and outputs a ciphertext c. We will use as a shorthand notation for Enc(pk, m). We require IND-CPA security and the following correctness conditions. Given any set of plaintexts m 1 , . . . , m , it must hold for any pk, sk, ek: • Dec(sk, Enc(pk, m )) = Dec(sk, m ) = m , • Dec(sk, Eval(ek, , m 1 , . . . , m )) = Dec(sk, (m 1 , . . . , m ) ).
In practice, a homomorphic encryption defines two basic operations for addition and multiplication that can then be used to compute larger functionalities. FHE Operations. An FHE scheme defines both operations (addition and multiplication). For all plaintexts m 1 , m 2 , we define the following operations and introduce shorthand notations: Additively HE. If the scheme supports only addition, then it is called additively HE (AHE). Schemes such as Paillier [41] or Elliptic Curve ElGamal [33] are additively homomorphic and have the following properties for all integer plaintexts m 1 , m 2 and bit plaintexts , ∈ {0, 1}: Note that we use the same shorthand notation for FHE and AHE. The actual implementation depends on the underlying scheme.
Somewhat, Leveled and Fully HE. If the scheme supports addition and multiplication, but for a limited number of times, then it is somewhat homomorphic (SHE). When arbitrary computation can be performed on encrypted data, then the encryption scheme is fully homomorphic (FHE). Because FHE requires the so-called bootstrapping that is computationally expensive, it is sometime useful to use leveled FHE for efficiency. Leveled FHE can evaluate only computation up to a given circuit depth that is fixed by the encryption keys. In the following, we will use only the term FHE for fully homomorphic encryption and leveled fully homomorphic encryption.

RELATED WORK
In his seminal paper [53], Yao introduced the millionaires' problem and the first protocol to securely compare two integers. Later, different alternatives of securely comparing integers have been proposed. In [35,36] Kolesnikov et al. proposed schemes that use garbled circuits. In [18], Damgård [49] and Joye and Salehi [31]. Similar protocols to the DGK, that rely on AHE, include Lin and Tzeng [37,48], Fischlin [22], Blake and Kolesnikov [6], Garay et. al. [24]. Other protocols [13,17,38,40,43] and most recent ones [4,20,39] Client Server are based on the arithmetic black-box model which is a powerful tool commonly used in MPC frameworks such as MP-SPDZ [32] or SCALE-MAMBA [1]. In [14,15], Cheon  In summary, all these schemes require access to the bit representation of the integers. Some schemes have a constant number of rounds [6,15,18,22,[35][36][37]. Other schemes have log-logarithmic number of rounds [16,24,26]. In Section 8, we analyze the closely related work in more detail and compare it to our approach. More recent work include [11,30] that reduce to comparison of small integers, using a base > 2 representation instead of the binary representation. Bourse et al. [11] Use a specific AHE construction based on Factoring and cannot support comparison of two encrypted input, and sharing of the output bit. We do require any specific AHE, but can implement our scheme using ECC ElGamal resulting in a faster scheme with smaller communication. Iliashenko and Zucca [30] use specific structure of BGV and BFV to design faster schemes. We do not assume a specific FHE scheme, have a smaller circuit depth and can compare more integers using SIMD.

DEFINITIONS
Setting. The protocol consists of a server holding an input , and a client holding an input . We assume that both inputs consist of −bit integers and is public. The ideal functionality F GT takes from the server and from the client. It computes and outputs a bit = [ ≥ ] to the parties such that = 1 if ≥ and = 0 otherwise. The functionality is illustrated in Figure 1. In the following, we build our protocol on the case where only the client gets an output = [ ≥ ]. It can be easily extended to a symmetric scenario if the server chooses a random ∈ {0, 1} and homomorphically computes = ⊕ before sending the result to the client. Then, the client decrypts the result and both parties holding shares , respectively and can reconstruct the result = ⊕ . In some larger settings, it might be required to return only these shares of to the parties, preventing them to learn intermediate result.
Security and Correctness. A protocol correctly implements the GT functionality if after the computation the output is correct, i.e., = 1 if ≥ and = 0 otherwise. Besides correctness parties must learn only what they are allowed to. This is formalized using the ideal/real world paradigm, where for each party there must exist a simulator, that given only the input of that party and the output, can generate a distribution that is computationally indistinguishable to the party's view [27]. To formalize this, we need the following definition [27]. A function : N → R is negligible if for every positive polynomial (·) there exists an such that for all ∈ N with > : ( ) < 1/ ( ). Two probability distribution ensembles { } ∈ {0,1} * , { } ∈ {0,1} * are computational indistinguishable (denoted by ≡) if for every probabilistic polynomial-time (PPT) algorithm D, every positive polynomial (·) and all sufficiently long In other words, there is no algorithm that can distinguish between the distributions. In multi-party protocols the view of a party consists of its input and the sequence of messages that it has received during the protocol execution [27]. The protocol is said to be secure if for each party, one can construct a simulator that, given only the input of that party and the output, can generate a distribution that is computationally indistinguishable to the party's view. We focus on the semi-honest security model in which parties follow the protocol but may try to learn more information from its execution. A protocol securely implements the GT functionality F GT in the semi-honest model if each party learns only its output and nothing else. In particular, there must exists simulators Sim gt C and Sim gt S that simulate the client and the server given only their input and output to the protocol.
Let Π GT denote a protocol that securely implements F GT , and let View Π GT P ( , ) denote the view of party during the protocol, then the following hold: • there exists a PPT algorithm Sim gt S that simulates the server's view View Π GT S given only and [ ≥ ] such that:

OUR PROTOCOL
Our protocol relies on a branching program that is represented as a binary tree. We therefore start by describing the intuition behind our scheme and defining our data structure. Then, we describe how our algorithms use this data structure to implement the functionality.

Intuition
Our key observation is that the comparison problem can be seen as a classification problem using a decision tree, where the tree is built on the server input and evaluated using the client input. That is, given a server's input , a client's input classifies as 1 if ≥ or 0 otherwise. The tree edges are labelled with bits such that the evaluation is done by traversing the tree along the path of . However, we do not know the path representing -since it is encrypted -and therefore have to evaluate all paths and aggregate the results.
In our schemes, we compute the bit equality using XOR or XNOR. This is possible with AHE only if one of the bits is not encrypted and therefore requires the server to know in the clear. Previous work solve this by adding a computation round which allows the parties to reduce the problem to the comparison of two random inputs, which preserve the order relation between the initial and . If , are encrypted, we compute the bit equality using a subtraction, without an extra round. This eventually introduces an error (0-1 = -1) which we correct before aggregating the results on the path.
For (leveled) FHE, computing prefixes by simply multiplying values is inefficient, as the multiplicative depth matters. Our scheme keeps a logarithmic (instead of linear) multiplicative depth at the cost of a low overhead on the number of multiplications. We do this by pre-computing dependency lists for multiplication as in [45]. This pre-computation depends only on the bitlength (and not on the inputs), and its result is unique for a given bitlength. It can be computed once and offline and later used as a constant parameter in the online protocol.

Data Structure
The data structure is a binary tree consisting of inner nodes and terminal nodes. Each inner node has two child nodes and terminal nodes have no child nodes. There is a node with no parent node that is called root node. Let be a node in the tree. We define a node data structure consisting of the following: • .parent: a value representing the pointer to the parent node, • .left: a value representing the pointer to the left child node, • .right: a value representing the pointer to the right child node, • .lEdge: a bit representing the edge label to the left child node, • .rEdge: a bit representing the edge label to the right child node, • .cLabel: a value representing a node label, • .cost: an integer representing the cost on the path from the root.
The pointer to the parent node .parent is initially null and points to the respective parent node, when the child node is created. This pointer remains null for the root node. The pointers to the child nodes .left, .right are initially null, and point to the respective nodes if they are created. The edge labels to the child nodes .lEdge, .rEdge are 0 on the left and 1 on the right. The node label .cLabel is 0 or 1 for terminal nodes and undefined for inner nodes. The cost attribute .cost is computed during evaluation of the tree.

Algorithms
Our scheme works for both AHE and FHE but must be implemented differently. Initialization. The Initialization consists of a one time key generation. The client generates an appropriate triple (pk, sk, ek) of public, private and evaluation key for an HE scheme. Then, the client sends (pk, ek) to the server. For each computation, the client just encrypts its input and sends it to the server.
Creating the Binary Tree. Let be the server input with bitlength . The server starts by creating a binary tree representing . The basic idea consists of creating a binary tree representing all bit strings of length . Then the leaf of the path that represents and the leaves of all paths right to the path of are labelled with 1 (i.e., .cLabel = 1). The leaves of the paths left to are labelled with 0 (i.e., .cLabel = 0). Finally, we can prune all subtrees that are labelled with the same bit. That is, if an inner node has two child nodes labelled with the same bit , we remove the child nodes of from the tree and transform into a leaf node labelled with , (i.e., .cLabel = ). However, we can avoid the pruning by traversing the tree a single time with the bits of . If [ ] = 1, we insert a leaf node on the left with cLabel = 0, and a new node on the right, then we traverse to the right. If [ ] = 0, we insert a leaf node on the right with cLabel = 1 and a new node on the left, then we traverse to the left. Note that inserting a leaf node is only required if we are using FHE. For AHE, the traversal works similarly as above except that no leaf node is inserted left from the traversed path. Therefore, the created tree contains only paths, that can be evaluated to zero, i.e., paths labelled with integers that are larger or equal to . The creation of the binary tree is illustrated in Algorithm 1. For example, assume that = 3, then Figure 2 illustrates the binary trees of 2 and 5 if the scheme is for FHE and Figure 3 illustrates the binary trees of 2, 3, and 5 if the scheme is for AHE. Computing Decision Bits. Let be the input of the client. The client sends bitwise encrypted. That is, the client computes the bit representation¯=     Aggregating Decision Bits. For each leaf node , the server aggregates the comparison bits along the path from the root to . For FHE this is done using homomorphic multiplication of the decision bits. For AHE, it is done using homomorphic addition of the decision bits. To unify the depiction of our algorithms as much as possible, we introduce a new notation for aggregating the decision bits: BitAgg. It refers to the homomorphic multiplication in the FHE case and to the homomorphic addition in the AHE case. The aggregated result is then stored at the leaf node of the corresponding path. We implement it using a queue and traversing the tree in BFS order as illustrated in Algorithm 3. Note that this computation can be improved using path prefixes, i.e. for two paths having the same prefix, the prefix is evaluated once.
Evaluating leaves. The evaluation of the leaves depends on the scheme as well. For FHE, after aggregating the decision bits along the paths to the leaf nodes, each leaf node stores either .cost = 0 or .cost = 1 . Moreover, there is a unique leaf with .cost = 1 and all other leaves have .cost = 0 . Then, the server aggregates the costs at the leaves by computing for each leaf the value .cost .cLabel and summing all the results of all leaves. This

Algorithm 3 EvalPaths
Require: root 1: let be a queue 2: let leaves be a queue 3: .enqueue(root) 4: while .empty() = false do 5: ← .dequeue() 6: if .left ≠ null then 7: .left.cost ← BitAgg( .left.cost , .cost ), 8: if .left.IsLeaf() then 9: leaves.enqueue( .left) .enqueue( .left) 12: end if 13: end if 14: if .right ≠ null then 15: .right.cost ← BitAgg( .right.cost , .cost ), 16: if .right.IsLeaf() then 17: leaves.enqueue( .right) 24: return leaves computation is illustrated in Algorithm 4. For AHE, after aggregating the decision bits along the paths to the leaves nodes, each leaf node stores a cost which is either .cost = 0 or .cost = , where is the number of 1s on a path. Moreover, there is at most one leaf with .cost = 0 and all other leaves have .cost = , for an unknown ∈ {1, . . . , }. Note that for ≠ 0 the number of paths is smaller or equal to (See Figure 3a, 3c). The server randomizes the encrypted costs at the leaves, chooses other random ciphertexts not encrypting zero, permutes the list and sends it to the client. These operations are implemented to guarantee the server's privacy. Randomization and permutation of ciphertexts prevents leakage of any information about that is not intended. The generation of additional ciphertexts prevents leakage of the tree structure and therefore, potential information about as well. Note that we exclude the case of randomly generating a ciphertext which decrypts to zero. The computation is illustrated in Algorithm 5.
Decrypting the Result. The client decrypts the result of the evaluation. For FHE, it is a single encrypted bit indicating the comparison result. For AHE, the evaluation result consists of ciphertexts among which at most one encrypts 0 and the remaining ones encrypt random plaintexts. The comparison result is true iff there is an encryption of 0. The client uses Algorithm 6 to decrypt and learn the final result.

Algorithm 4 EvalLeaves (FHE)
Require: leaves return 0 17: end if Putting It All Together. As illustrated in Protocol 4, the whole computation is performed by the server. The server first creates a tree representation of its input as illustrated in Algorithm 1. Then, the client sends the encrypted bit representation ¯ of its input and the server sequentially runs the Algorithms 2, 3 and 4/5 described above. The server sends an encrypted result, which the client can decrypt to learn the final comparison bit = [ ≥ ].
Lemma 5.1. Let and be integers of length . If the encryption scheme is correct, then the comparison protocol is correct.
Proof. In the tree of , there is a single path that is labeled with a prefix of . Evaluating the nodes on this path and aggregating Client Server Input: x Input: y x EvalNodes(root, x ) Protocol 4: The Basic Protocol the results produces a bit 1 (if FHE), resp. 0 (if AHE). On all other paths, at least one edge is labelled with a bit that is different to the bit of at the same position such that the evaluation of the path produces a bit 0 (if FHE), resp. an integer ≠ 0 (if AHE). □ Theorem 5.2. Let and be integers of length . If the encryption scheme is IND-CPA secure, then the comparison protocol is secure in the semi-honest model.
Proof (sketch). The client only encrypts its own input and decrypts the final result which for FHE is a single bit, and for AHE a randomly ordered list of ciphertexts among which at most one encrypts 0 and the remaining ones encrypt each a random plaintext. The server, on the other hand, computes on IND-CPA ciphertexts. Constructing the simulators therefore consists of on simply generating corresponding random strings for each protocol message except for the actual results (Appendix A). □

EXTENSION
In the previous section, we discuss the basic idea of our scheme. Now we want to discuss how the basic scheme can be extended to different use cases.

Handling Comparison to Zero for AHE in the Constant Case
Recall that if the encryption is AHE, then Algorithm 1 creates a tree containing only paths, that can be evaluated to zero, i.e., paths labeled with integers that are larger or equal to . If = 0 then the created tree has + 1 leaves, since everything is larger or equal to zero. But the server is supposed to send back ciphertexts to the client. That is, we still want the parties to perform the computation such that nothing more than the comparison bit is revealed. We notice that for all values smaller than 2 −1 (i.e., the most significant bit is 0), traverses the tree of = 0 to the left. To handle the case = 0, the server, therefore, replaces the first encrypted bit of by a ciphertext of 0 and omits the rightmost path of the tree in the evaluation.

Shared Output Bit
In 2-party comparison like DGK [18], it is usual to share the comparison bit between the client and server. That is, if is the comparison bit, then the server gets and the client gets such that = ⊕ . In our scheme, the server can randomly choose between computing GT (e.g., [ ≥ ]) or LT (e.g., [ ≤ ]) functionality. The server, therefore, chooses a bit and computes GT if = 0, otherwise it computes LT (See Section 6.5). Note that in both cases (GT vs. LT) the tree of has the same structure, such that the server performs the same computation which is independent of [ ≥ ] and [ ≤ ] and hence does not leak which operation was evaluated. After this computation, the server returns ciphertexts to the client, among which at most one encrypts 0 (due to sum of zeros on the corresponding path). The remaining ciphertexts encrypt each a random plaintext (since there is at least a 1 on the corresponding path). The client can then extract its share of the comparison bit. For further computation, the client can send back the ciphertext , from which the server can easily get the ciphertext = Xor( , ) of the actual comparison bit. Note that this is not specific to our scheme, but it also works with other AHE-based comparison protocols.

Handling Encrypted Inputs
So far we assume that only is encrypted. In this section, we consider the case where both inputs are encrypted. In this scenario, the server has to run the comparison of two encrypted inputs with the help of the client (or another server) which has the decryption key. It is assumed that the inputs and do not belong to any party and must remain private. After the computation, the server learns the encrypted comparison bit. If the encryption is FHE, the server can perform the computation on its own. However, in the AHE case, the client must help the server to learn the encrypted result.
To guarantee the privacy of both inputs, the protocol has to be evaluated on ciphertexts only. However, the tree structure reveals a lot of information about why we have to use a general representation of the tree to avoid any leakage. We start with a few formal definitions. Definition 6.1 (Comparison Tree). A comparison tree or cmptree for an integer is a binary tree where edges and leaves are labelled with 0 or 1 such that for every integer , traversing the tree along a path labelled with the bits of (starting with the most significant bit of ) reaches a leaf labelled with 1 if ≥ and 0 otherwise.
Note that for secure comparison the bits are encrypted such that we do not actually traverse the tree , but evaluate it on as explained in the previous section. Therefore, when we say traverses the tree of , we mean that there is a single path where evaluates to 1 (if FHE), resp. 0 (if AHE), and on all other paths evaluates to 0 (if FHE), resp. to an ≠ 0 (if AHE).
While Definition 6.1 describes a cmp-tree, it can be built as follows. Let be the input bit-length of . First build a binary tree representing all bit strings of length , i.e. left edges are labelled with 0 and right edges are labelled with 1. Then, there is a path representing , label the leaf of and the leaves of all paths right to with 1. Finally, label the leaves of all paths left of with 0. Such a tree construction is illustrated in Figure 5 for = 2. Note  that the tree from Figure 5 is unnecessarily large as there are inner nodes whose child nodes are both leaves labelled with the same value. Such resulting sub-trees can be pruned without changing the semantic of the cmp-tree. We next formally define pruned cmp-tree.
We first recall the depth of a binary tree. Definition 6.2 (Depth of a Tree). For a binary tree, we define the depth of the tree as the length (i.e., number of edges) of the longest path. The depth of a node is the number of edges between this node and the root node. Let be the depth of the binary tree, a deepest inner node is a node whose child nodes are both leaves with depth . Definition 6.3 (Pruned Cmp-tree). A comparison tree for an integer is full-pruned if there is no inner node whose children are both leaves with the same label. A cmp-tree for an integer is halfpruned if its depth is the bit-length of and for each non deepest inner node exactly one child node is a leaf.
Note that a half-pruned cmp-tree is not necessarily full-pruned. For example if the bit-length is = 3, then half-pruned tree of 4 is not full-pruned. In this case, the full-pruned tree is only the root with 2 leaves. In the following, we will rather consider half-pruned tree since the structure is similar for every input. The half-pruned tree for integer can be built as follows. Traverse the non-pruned cmp-tree from Definition 6.1 along the path of . At each level, replace the non-traversed subtree by a leaf node. Let be the path representing . Label the leaf of and the leaves of all paths right to with 1. Label the leaves of all path left to with 0. By using Algorithm 1 with = 1, this can be done without first generating the full cmp-tree. Now, we want to introduce a structure of the tree based on the input size but independent of the actual inputs. We first define further notation. Recall that we use the symbol = 1 if the encryption scheme is FHE and = 0 if the encryption scheme is AHE. For a bit ∈ {0, 1}, we now define the function ( ) = + (−1) · . Note that the function does not have to be evaluated homomorphically, as its only purpose is to simplify the notation. For an encrypted bit , we have ( ) = if the encryption is AHE and ( ) = 1 − if the encryption is FHE with arithmetic encoding or ( ) = 1 + for binary encoding, as the addition is modulo two. Definition 6.4 (Normal Cmp-Tree). Let be an integer of length . A normal Cmp-tree of is a binary tree with the following structure: • there is a leftmost path of length which is labelled with the bits of , • the deepest inner node of path has a left leaf node labelled with , • each inner node of path has a right child leaf node, • for each inner node, let be the label on the left edge, then the label on the right edge is 1 − and the label on the right child leaf node is ( ).
While Algorithm 1 generates a half-pruned cmp-tree for assuming the bits are given in plaintext, the normal cmp-tree can be built even if the input bits are homomorphically encrypted. For each encrypted bit of the input string, one can homomorphically compute the encrypted inverse bit 1 − and build the cmp-tree. The generation of the normal cmp-tree is described in Algorithm 7. Note that in contrast to Algorithm 1, left and right edges are not per default labeled with 0 and 1, but they are assigned according to the definition of the normal cmp-tree. This makes the normal cmp-tree a general structure which is independent of the actual input . The input only influences the labels of the edges but not the tree structure itself.
Although both algorithms have the same complexity, Algorithm 7 is shorter and simpler. An example of normal cmp-trees is illustrated in Figure 6. Before using the normal form defined above, we need to prove that it is indeed a cmp-tree, by showing that the normal cmp-tree has the same number of nodes (inner nodes and leaves) as the half-pruned cmp-tree and that they can be transferred into each other. Lemma 6.5. Let be an integer of length . The half-pruned tree of has + 1 leaves and inner nodes.
Note that among the + 1 leaves, at most leaves are labelled with 1 (if FHE), resp. 0 (if AHE). For the AHE case, if is the number of these leaves, then exactly the paths corresponding to them are created in Algorithm 1, evaluated and sent back (with − random ciphertexts) to the client. Definition 6.6. Two cmp-trees are equivalent if they represent the same value, have the same depth and the same number of leaf nodes and inner nodes.
Lemma 6.7. The normal cmp-tree of and a half-pruned cmp-tree of are equivalent. Theorem 6.8. Let and be integers of length . If the encryption scheme is correct, then the comparison protocol is correct.
With the normal cmp-tree we have a structure independent of the actual tree which allows the server to compute on ciphertexts without learning anything of input . This structure is also equivalent to the structure we used for our basic protocol and yields correct results such that we can apply nearly the same routines. The only difference is in the computation of decision bits since the server does not know the edge labels in plaintext. Therefore, we have to apply an inequality/equality test on ciphertexts. For FHE we need an inequality test which can be implemented using an FHE Xnor gate. For AHE we must perform an equality test which can be implemented using an AHE Xor gate.

Handling Encrypted Inputs under AHE
The handling of encrypted inputs described above works only for FHE. The reason is that the Xor-operation for AHE encrypted bits  16: return root requires one bit to be in the clear. In this section, we describe how to extend the previous section to handle the case for AHE. We assume the client sends two encrypted inputs and to the server. The server creates the normal cmp-tree of using Algorithm 7, evaluates the encrypted input on the tree and sends back a result that only the client can decrypt. However, the encrypted result is not an encrypted bit, but a set of ciphertexts.
The computation needs two basic bit-operations, namely Not and Xor, that have to be simulated under AHE. Let and be two encrypted bits. We compute the Not-operation as ¬ = 1 − = Add ( 1 , MulCons( , −1)). Then, we compute the Xor-operation as ⊕ = − . While the Not-operation is correct, this is not always the case for the Xor-operation, namely we have 0 ⊕ 1 = −1 . We will handle this before aggregating the paths.
Recall that we have encrypted bits of and and we want to compute a comparison bit. First, using the encrypted input , we can build the normal cmp-tree as explained in Algorithm 7. This requires only the Not-operation. Then we can evaluate the bits of on the built tree. For that, we first have to apply the Xoroperations on the bits of along the paths of the tree and then sum the result along the paths. Our goal is that, if ≥ , then exactly one path will have all Xor-results equal 0 such that the sum along the path is also 0. The remaining paths will have at least one Xor-result that is different to 0 resulting in a sum different to 0. Now we have the following problem: If the Xor-results of a path contain 1 and −1 then this path too may sum to 0. To get rid of the problem, we multiply the Xor-result at level (i.e., edges starting at a node with depth ) by 2 before aggregating the results along the paths. Since 2 is constant, the multiplication can be applied on an AHE ciphertext. The following lemma ensures that the sum on such a path is then always different to 0. Lemma 6.9. Let ( 0 , · · · , ) ∈ {−1, 0, 1} +1 such that there exist at least one ≠ 0 then it holds =0 · 2 = 0 · 2 0 + · · · + · 2 ≠ 0.
That is, on encrypted input we get ( 2 , −2 , 1 , −1 ). The server will then homomorphically randomize the plaintexts and send a permuted vector, from which the client can deduce the comparison bit = 0, since no ciphertext decrypts to zero.

Less Than (LT) Comparison
The computation of the Less-Than (LT) function is similar by using the following definition that is the inverse of the normal cmp-tree. Definition 6.10 (Inverse Normal Cmp-Tree). Let be an integer of length . An inverse normal Cmp-tree of is a binary tree with the following structure: • there is a rightmost path of length which is labelled with the bits of , • the deepest inner node of path has a left leaf node labelled with , • each inner node of path has a left child leaf node, • for each inner node, let be the label on the right edge, then the label on the left edge is 1 − and the label on the left child leaf node is 1 − ( ).
While the inverse normal cmp-tree is defined with a right oriented structure (contrary to the left oriented structure of Definition 6.4), the inverse normal cmp-tree can be represented with a left oriented structure as well. The only difference is that all leaves except the leftmost one must be labelled with 1 − ( ) as in Definition 6.10 instead of ( ) as in Definition 6.4.

ANALYSIS
In the sections above, we proved already that the computation correctly returns 1 if ≥ and 0 otherwise. The computation is also secure as the server evaluates input encrypted under the client's public key. In this section, we therefore focus on the complexity analysis and count the number of homomorphic operations (addition and multiplication). Cheon et al.

Number of Operations
We start by counting the number of operations depending on the main steps of the algorithm, namely: node evaluation, path evaluation, leaves aggregation. In the following, we use A 1 , A 2 , A 3 (resp. M 1 , M 2 , M 3 ) to denote the number of addition (resp. multiplication) operation in node evaluation, path evaluation, leaves aggregation and A (resp. M ) for the total.
Node Evaluation. For node evaluation at each inner node, the algorithm performs exactly one Not gate due to the fact that the left and right edges of an inner node are always labelled with opposite bits. For the encrypted case (Section 6.3), we need one Not and one Xor. Hence, we have in total Not-operations.
Path Evaluation. For path aggregation, the algorithm performs − 1 multiplications on the leftmost path and 2 multiplications on each right path except the rightmost path that requires only 1 multiplication. This result in total of − 1 + 2 · ( − 1) + 1 = 3 − 2.
Leaves Aggregation. In the case of FHE, the algorithm finally aggregates the + 1 paths requiring additions.

Complexity for FHE
For FHE, we need to distinguish between binary and arithmetic circuit or encoding. An overview can be found in Table 1. For some FHE schemes, it might come with performance improvements if we reduce the multiplicative depth. In our scheme, this only affects the path evaluation. The previous approach yields a depth of but we can reduce the depth to log by using an optimized implementation. For implementation details, we refer to Section 8 and Appendix B. The reduction of the multiplicative depth comes with an increasing number of multiplications. For the leftmost path, we need a multiplication for every pair, for every quadruple and so on. By the geometric sum formula, this is − 1 multiplications. The splitting of the leftmost path creates a structure that divides the path into sections of powers of two. Therefore, the connection of right children of one section needs one additional multiplication for every child in that section. This results in a total number of multiplications of + log 2 for right children nodes. We provide a more detailed analysis in Appendix C. Comparison to Previous Work. Cheon et al. [15] also use a comparison protocol based on FHE and present a variant with logarithmic multiplicative depth. Their critical part is the iterative computation of a product with depth −1, i.e., given integers 1 , . . . , , we want to compute products = =1 , for = 2, . . . , while keeping the multiplicative depth logarithmic. They propose to compute the products using a recursive algorithm that builds a binary tree of products yielding sub products for positions which are power of 2. In the next step, they compute the missing products, i.e., for positions that are not power 2, based on a multiplication of the results for the power of two cases. We implemented this computation using an iterative algorithm described in Appendix D. For more details, we refer to the original work [15]. In total, the scheme of Cheon et al. requires 2 − 2 additions and 2 − 3 + ( −1) ( −1) 2 multiplications using binary encoding. Using arithmetic encoding, the 2 − 2 additions require an additional − 1 homomorphic multiplications. As a result, the total number of multiplications in their scheme is 3 −4+ ( −1) ( −1) 2 . As our approach, they also achieve a logarithmic depth but need less additions and slightly less multiplications. However, our optimized implementation uses a precomputation which is an advantage for the actual running time of the protocol, see further in Section 8.

Complexity for AHE
For AHE, we need to distinguish between the encrypted case where both inputs are encrypted and the the constant case where only one input is encrypted. An overview can be found in Table 2. In both cases, Xor and Not operations are realized using homomorphic addition. As a result, there are A 1 = homomorphic operations for node evaluation. In the encrypted case, we have A 1 = 2 homomorphic operations.   Figure 3). This results in A 2 = 2 − 2 operations for paths evaluations, i.e., − 1 operations for evaluating the leftmost path and one operation for each of the − 1 deepest right oriented paths. In total, our scheme requires A = +2 −2 = 3 −2 operations. As a comparison, in [18], the DGK scheme performs 5 additions, constant multiplications which is equivalent to 2 additions. In total, DGK has 7 additions plus additional encryption operation and modular inverse operations. Veugen [49] improved the DGK scheme by requiring only 4 operations.
Encrypted Case. We now have A 1 = 2 homomorphic operations for node evaluation, but A 2 = 3 −1 operations for paths evaluation, as we have to consider the leaves. Additionally, we need 2 constant multiplications to prevent the problem explained in Section 6.4. A constant multiplication m requires in worst case 2 log homomorphic additions. For each level , we perform in Section 6.4 two multiplications by 2 resulting in 2 −1 =2 = O 2 operations which dominates the number of operations for nodes and paths evaluation.
Comparison to Previous Work. As a comparison Veugen also proposed two extensions of the DGK scheme in the encrypted case: a statistical and perfect secure scheme. Both have 2 rounds, i.e., 4 moves between the parties (while our scheme still has one round as the initial DGK). Both schemes require efficient decryption of a random plaintext and cannot be efficiently implemented using ECC ElGamal (see section on ElGamal). The scheme works as follows. The server holds and encrypted under Paillier with modulus = , where and are large primes. The server chooses a random number , such 0 ≤ < , computes ← − + 2 + = · −1 · 2 + mod 2 and sends it to client, which the client decrypts to get . For the statistical security case, the server with = mod 2 and the client with For the perfect security case, Veugen proposed a modified DGK protocol that is very complex and requires two times the same constant multiplication by 2 as our scheme and additional operations, such as encryption, decryption and modular inversion, to get the final result. Since the scheme is very complex and the number of operations depends on the actual values, we use a complexity lower bound for a comparison with our scheme. Table 2 shows that our scheme is a significant improvement even to the lower bound of the optimized DGK protocol. As in [49], we assume a homomorphic multiplicative inversion to need 2 3 multiplications where is the bit-length of the number which is a ciphertext in this case. For the inversions used by the modified DGK protocol, this is on average 3 multiplications.
Another optimization of the DGK protocol has been published by Joye and Salehi [31]. Their scheme achieves about the same overhead as Veugen but prevents timing attacks. To this end, they use the hamming weight of one input and can furthermore half the number of ciphertexts being sent. However, to keep the security, they introduce another round to mask the input. Our protocol only needs one round but still transmits instead of /2 ciphertexts.

EVALUATION AND IMPLEMENTATION
In this section, we describe some implementation details and report on the experimental results of our implementations.

Optimized Implementation
Instead of implementing our scheme using a binary tree, we can rely on a simpler data structure by using a two dimensional array [(1, . . . , + 1), (1, 2, 3)] with + 1 rows and three columns. The idea is illustrated in Figure 7 for = 1, = 3, = 3, = 1. The array is initialized with the cmp-tree of = 3, where the first column stores the labels on the leftmost path. Column 2 and 3 store the right oriented paths from the first row to the last one. That is, the last row and the last column store leaf labels, where on the last row, only the first cell is filled.
The evaluation itself is illustrated in Algorithm 8 and Figure 7. On each row, we store [ ] == [ ] in cell 1, its negation in cell 2, and ( [ ]) in cell 3. This corresponds to the computation of decision bits(cell 1 and 2) and the leaf node labels (cell 3). In Figure  7, the arrows illustrate paths evaluation, where → means that cells and are aggregated and the result is stored in cell .
For the FHE case, the multiplicative depth of the procedure is of relevance if the encryption scheme is leveled FHE. This is because a leveled FHE has a fixed parameter such that circuits with depth at most can be evaluated without bootstrapping. Therefore, we first evaluate the inner nodes as before by evaluating Xor operations, but use the multiplication with a direct acyclic graph described in [45]. This is illustrated in Figure 8 and consists of first computing a dependency list (DL) table for each element of the matrix (the middle table in Figure 8). The DL is a queue, represented as [) with back [ and front ) that contains cells' numbers along a multiplication path, i.e., the set of cells that must be multiplied together. In Figure 8, we have the following multiplication paths: (1,4,7,10), (1,4,8,9), (1,5,6), (2,3). For each path, we start with a , there is nothing to do for nodes and since their DLs are empty. For node , we compute ← · . For node , we first compute ← · and then ← · . For a path of length , this reduces the multiplicative depth from to log .

Setup Environment
For AHE, we implemented DGK [18], the optimized DGK by Veugen [49], the scheme of Joye and Salehi [31] and our scheme in Java. We instantiated AHE with ElGamal on elliptic curve as described in Appendix E using curve secp256r1. We implemented  our scheme in three variants: the naive implementation using tree representation (Section 5), the optimized implementation using array representation (Algorithm 8) and the encrypted case (Section 6). For the scheme of Joye and Salehi, we only implemented the basic comparison protocol without the additional masking round which would be required to achieve full security. We note that Veugen [49] also proposed a protocol for the encrypted case, which is computationally more complex and no longer one round. For this reason, we did not implement it as it no longer fits with our basic protocol (Protocol 4) and our encrypted case is already theoretically better. It is one round and requires only a constant multiplication (by 2 as explained above) per bit.
We evaluated our implementation according to our basic protocol which is a one round protocol. That is, the client encrypts its input and sends it to the server. The server evaluates and sends back encrypted result to the client. The client finally decrypts to learn the result. The evaluation of the AHE implementations is done on a single Laptop with a 6-core Intel(R) Xeon(R) E-2176M CPU @ 2.70GHz and 32GB of RAM running Windows 10 Enterprise. Due to the higher running time and memory requirements of FHE schemes, the evaluation of FHE implementations is done on an AWS instance with a 24-core Intel(R) Xeon(R) Scalable processor (Skylake 8151) with up to 4.0 GHz and 192GB of RAM running Ubuntu 20.04 LTS.

Results
We present the result of our evaluation and compare our scheme to the related work. Since there are several schemes in the literature, we focus on schemes closely related to ours and discuss some recent work in Appendix F. That is the comparison uses the binary decomposition, performs computation on homomorphically encrypted inputs but does not assume a specific AHE or FHE scheme. AHE. For DGK, Veugen constant case and our scheme, the communication is the same, i.e., number of ciphertexts ( ciphertexts from client and ciphertexts from server) sent times the length of a ciphertext. However, for the encrypted case, Veugen additionally requires Paillier encryption to encrypt large randomized plaintexts. This cannot be done with additive ElGamal, as decryption requires computing the discrete logarithm over a large domain. Veugen's scheme additionally sends few Paillier ciphertexts and requires two rounds instead of one in the encrypted case. Joye and Salehi have different communication because the server sends only half the number of ciphertexts as the other schemes. For the encrypted case, one might apply the same procedure as Veugen resulting in more expensive Paillier operations as well. The above is also true for the client computation effort. In DGK, constant case Veugen and our scheme, the client encrypts plaintext bits and decrypts ciphertexts. In Joye and Salehi, the decryption of the client is reduced by factor 2. Nevertheless, we focus our evaluation on the server computation but compare only to the basic scheme of Joye and Salehi without the additional round.
To evaluate the running time, we generated random inputs and and compare them using each protocols at security level 128. We repeated the experiment 100 times and computed the average running time which is illustrated in Table 3, for input bit-length = 8, 16, 32, 64, 96, 128. While Veugen scheme and Joye and Salehi scheme clearly perform better than the original DGK scheme, Joye and Salehi performs slightly better for small bit-lengths ( ≤ 32), while Veugen performs better for large bit-lengths ( ≥ 64). Our naive implementation is only better than the both for large bitlengths ( ≥ 64) and our optimized implementation is always better. Although our encrypted case requires additional constant multiplications per bits, it still performs better than the original DGK scheme. In the encrypted case of Veugen's scheme and Joye and Salehi's scheme client and server both require additional Paillier ciphertext operations.
We implemented and evaluated the Paillier operations in Veugen's scheme at security level 128 (i.e., bit-length of the modulus is 3072) on a single laptop as described above. These extra Paillier operations require on average 600 milliseconds which almost double our running time for = 128. Note that the network cost for the extra protocol round is not included.   First, our optimized implementation only needs memory for the two-dimensional array, i.e. 3 ciphertexts, since the multiplication procedure is based on a pre-computed plan and applied within the array. Cheon et al. also need 3 times ciphertexts but additional memory to compute products [15]. Second, the implementation of our protocol (Algorithm 8) by another party is much easier since the construction of the multiplication plan does not have to be implemented but the pre-computed results can be taken from a public source. Our FHE evaluation in Algorithm 12 is given as parameter the dependency list precomputed by Algorithm 11. Cheon et al. and our scheme have three main steps. In the first step, we fill the array as explained in Figure 7 and Cheon et al. compute three arrays = + 1, = · , = + , 1 ≤ ≤ . In the second step, we aggregate the array elements as in Figure 8 using a precomputed dependency list and Cheon et al. compute products = = +1 efficiently (i.e., reusing prefix results) while keeping the multiplicative depth logarithmic. This computation is illustrated in Appendix D and Algorithm 13. In the last step, we sum up all results in the third column and Cheon et al. compute = · and finally =1 . In both cases the second step is the most complicated. However, the pre-computation of the dependency list makes our second step easy to implement and to evaluate, as it is done once and offline, such that for the online computation it is enough to implement and evaluate Algorithm 12. The product computation (Algorithm 13) in Cheon et al. 's scheme requires constructing a binary tree of product and process it recursively. This cannot be precomputed, must be implemented with the entire algorithm itself and requires extra memory for storing log ciphertexts during evaluation.

APPLICATIONS
Integer comparison is a fundamental building block in many MPC protocols. In this section, we describe few applications where our scheme can improve the performance. We estimate this improvement to be proportional to the number of comparison operations required in the respective application. The following is of course not exhaustive and gives only an overview of applications. Machine Learning (ML). ML classifiers are valuable tools in many areas such as healthcare, finance, spam filtering, intrusion detection, remote diagnosis, etc [50]. They usually require access to privacy-sensitive user's data such as medical records, financial situation, location information, etc. On the one hand, the model itself may contain sensitive data. On the other hand, it may have been built on sensitive data. White-box and sometimes even black-box access to an ML model allows so-called model inversion attacks [23,44,52], which can compromise the privacy of the training data. Privacy-preserving techniques are therefore critically needed to protect the privacy of the model and user's data. Many applications in ML require integer comparison. For example, a decision tree (DT) is a common and very popular classifier that requires integer comparison to classify inputs. Some private DT schemes rely on DGK [42,51] or on FHE [45]. In Appendix G, we evaluate the private DT scheme of Tai et al. [42] using our scheme and compared it to [18,49]. In [46], Tueno et al. proposed an application for range queries that uses search tree structure to implement order-preserving encryption (OPE). They overcame the limitation of private-key OPE by using garbled circuit or DGK comparison to traverse the search tree.
Benchmarking and Auction. In this case, the goal is to securely compute the th -ranked element in a distributed setting. That is, given parties each holding a private integer, the problem is to securely compute the element ranked (for a given such that 1 ≤ ≤ ) among these integers. The computation should reveal to the parties only the th -ranked element (or the index of party holding it) and nothing else. The computation of the th -ranked element has applications in benchmarking, where a company is interested in knowing how well it is doing compared to others, or in auctions where bidders are interested in knowing the highest bid. In fact, the DGK protocol were proposed with online auction as application [18]. Privacy-preserving online auction was the world's first large scale application and commercial use of MPC. A team around the DGK authors developed, in 2008, a double auction solution for the Danish industry, which allowed farmers (sugar beets producers) and Danisco (the only sugar beets processor) to compute a so-called market clearing price (price per unit of the commodity that is traded) in a privacy-preserving way [2,10]. The main building block in this solution was integer comparison. Other work, including [9], [8], [48], have proposed protocols for computing the th -ranked element using the DGK comparison protocol. In [48], Tueno et al. also proposed a variant of their protocol based on SHE/FHE and using the comparison scheme of Cheon et al. [15]. Biometrics. Biometrics are used to authenticate or identify users. In an enrollment phase, biometric features are scanned and stored. During the authentication or identification phase, the same features are scanned again and compared with the stored ones. On the one hand, biometric images are never perfect, and therefore a match is determined by computing a proximity to the stored images. This implies that threshold comparisons are required in biometric systems [35]. On the other hand, biometric information is highly sensitive and subject to privacy issues due to to possible misuse, lost or theft of biometric data. This gives rise to privacy-preserving biometric matching, that compute on biometric data without revealing sensitive information. Blanton and Gasti [7] proposed such a protocol for iris and fingerprint identification using the DGK protocol.

CONCLUSION
We proposed a new protocol for secure integer comparison of two parties using the evaluation of binary trees. Our approach is based on HE and is a non-interactive solution which can be used for a broad range of applications or as a subroutine for larger protocols. We theoretically presented an FHE and an AHE mode with several extensions and optimizations and implemented both variants using improved data representations and evaluations to reduce the computational overhead.

A POSTPONED PROOFS
This section provides missing proofs for theorems and lemmas. Proof. For our scheme, we can consider settings where the comparison result is either revealed only to the client, or to both client and server, or secret-shared to both. Additionally, the server can see its own input or it can be encrypted as well. For simplicity, we consider the setting where the comparison result is revealed only to the client and the server input is not encrypted. In this case, security means that the client learns only the comparison bit and the server learns nothing. We then construct simulators Sim gt C ( , = [ ≥ ]), Sim gt S ( , ∅), for the client and the server. The goal of the simulator is to generate a view that is indistinguishable from the party's view in the real protocol. That is, for each message that a party sees, the simulator should be able to generate an indistinguishable message ′ using only the information available to that party, e.g., input, output, public and private key.
Client Simulator FHE: In the real protocol, the client sees encryptions of its input bits¯= [1], . . . , [ ] and encryption of the comparison bit. The simulator Sim gt C ( , = [ ≥ ]) has access to input and output of the client and knows the public key. The simulation is trivial.
Server Simulator FHE: In the real protocol, the server sees encryptions of the client input bits¯= [1], . . . , [ ] and ciphertexts generated during the evaluation of the tree. The simulator Sim gt S ( , ∅) has access to the server input and knows the public key, but not the private key. Hence, it can encrypt its own input bits. By assumption, the encryption scheme is IND-CPA secure, which means that each ciphertext is indistinguishable from a random value with the same length as the ciphertext. For all ciphertexts (either received from the client or resulting from the tree evaluation), the simulator just chooses a random element in the ciphertext space, i.e., encryption of a random plaintext.
Client Simulator AHE: The difference to the FHE case is that the client does not get an encrypted bit from the server, but a set of ciphertexts c [1], . . . , c[ ] where either all ciphertexts encrypt random plaintexts, or exactly one (at a random position) encrypts 0 while the remaining ones encrypt random plaintexts. That is, the simulation of the encrypted client bits¯= Proof. The depth of the tree is obviously . A complete tree with depth has 2 + 2 − 1 nodes. While constructing the half-pruned cmp-tree as explained above, we start from the root with depth 0 and stop at a node with depth −2, since node with depth −1 have only leaves as child nodes. In each step at depth ℎ ∈ {0, . . . , − 2}, we replace a subtree, that has 2 −ℎ − 1 nodes, with a leaf. That is, at depth ℎ ∈ {0, . . . , − 2}, we remove 2 −ℎ − 2 nodes. Then the numbers of nodes remaining in the tree is: We also have −2 Therefore we can compute = 2 + 2 − 1 − (2 +1 − 4 − 2 + 2) = −1 + 2 + 2 = 2 + 1. By construction, there are inner nodes and hence + 1 leaves. □ Lemma 6.7. The normal cmp-tree of and a half-pruned cmp-tree of are equivalent.
Proof. Given an arbitrary of length . By construction, the normal cmp-tree has depth since the leftmost path is the longest one. The same holds for the definition of a half-pruned cmp-tree.
For the normal cmp-tree, there are inner nodes on the leftmost path (including the root node). Since every node's right child is a leaf node, there are exactly inner nodes. Moreover, we have + 1 leaf nodes because every inner node has exactly one child leaf node (the right child) except the deepest inner node where both children are leaf nodes. Lemma 6.5 shows that a half-pruned tree has the same number of nodes and therefore they are equivalent. □ Theorem 6.8. Let and be integers of length . If the encryption scheme is correct, then the comparison protocol is correct.
Proof. By Lemma 6.7, we already know that the normal-cmp tree and a half-pruned cmp-tree are equivalent. Moreover, we can transfer one representation into another without changing the result.
By definition, a normal cmp-tree is half-pruned. It remains to show that it is also a cmp-tree. We assume that the encryption scheme is FHE. The case for AHE is similar. If and are equal, then traverses the normal cmp-tree of on the path as itself.
Otherwise, and have a common prefix that labels a path from the root to a node with depth ℎ such that traverses the tree to the left of while traverses to the right of . By construction of the normal cmp-tree, the left edge from is labelled with the bit [ℎ], while the right edge is labelled with the bit 1 − [ℎ]. Moreover, the right child node of is a leaf labelled with 1 − [ℎ]. If [ℎ] = 0 (resp. [ℎ] = 1), then is labelled with 1 (resp. 0) and the path to evaluates to 1 (resp. 0). On all other paths at least one edge label differs from the bit of at the same position such that the path evaluates to 0. This is sufficient to conclude whether ≥ or not.
For the other direction, we have to transfer a half-pruned cmptree into a normal cmp-tree. We start at the root node. If the left child node is not a leaf, we proceed with the left child. If not, we switch the below sub-trees and proceed with the left child which is now a leaf node. We repeat this procedure until we reach the tree's depth. The resulting structure fulfills all the requirements of a normal cmp-tree and still represents the same value . □ Lemma 6.9. Let ( 0 , · · · , ) ∈ {−1, 0, 1} +1 such that there exist at least one ≠ 0 then it holds =0 · 2 = 0 · 2 0 + · · · + · 2 ≠ 0.

B ALGORITHMS FOR FHE INSTANTIATION
In this section, we describe in detail our leveled FHE instantiation that uses the pre-computation of the dependency lists for the multiplication to keep a logarithmic multiplicative depth. We recall that this pre-computation depends only on the input length and can be computed a single time and stored for future evaluations of integer comparison. The pre-computation consists of the following three basic steps: • Computation of the paths. Using the Illustration in Figure 8, we use a table representation of the tree as explained above and compute the paths: (1,4,7,10), (1,4,8,9), (1,5,6), (2,3). This computation is illustrated in Algorithm 9. • Computation of the dependency lists for each single path. We compute the dependency lists for each path using Algorithm 10. • Computation of the dependency lists for the whole tree. This is done using Algorithm 11.
To evaluate the integer comparison of two encrypted inputs, we use Algorithm 12. A detailed analysis of the number of multiplications needed is provided in the next section.

C ANALYSIS NUMBER OF MULTIPLICATIONS
In this section, we analyse in detailed the number of multiplications for our leveled FHE Instantiation. To ease the understanding of the derivation of the number of multiplications, we present an example of bit-length 8 and apply the optimized implementation described in Section 8. The starting point is the array representation depicted in Figure 9.
Leftmost Path. The number of multiplications on the leftmost path are illustrated in Figure 10a. Our algorithm divides each path at half and repeats this procedure with the sub-paths until every node is connected. Going the other way around, this leads to one multiplication for each pair (In the example: 1 to 4, 7 to 10, 13 to 16 and 19 to 22), one multiplication for each quadruple (In the example:  Right Children. For the representation of the multiplications on the paths to the right leaves, we refer to Figure 10b. Note that we removed some of the numbers and arrows to ease the understanding of the analysis. We split the analysis for the right children into two parts.
For each row we have exactly one edge connecting the second with third column, that is multiplications.
The multiplications from the first with the third column are more complicated. To analyze their total number, we consider the labels on the leftmost path and make use of the following observation. A label has at least one arrow to the right because it is on the paths to right leaves which have their last edge label in the second column and their leaf label in the third column. If it is multiplied with the following label on the leftmost path (first column), we do not have to consider it further since it is in the multiplication chain for any right child (third column) below. Therefore, such a label has only one multiplication with right children, for example 1, 7 or 19 in the example (marked with solid arrows). Based on the analysis of the leftmost path, there are /2 such labels. For every second label, we have at least two multiplications to the right because its information is lost in the following row since we do not multiply with it. In the example, it holds for 4 and is marked with a dashed line. The next step is 10 which is needed for the following 4 rows and marked with a dash-dotted arrow. Following this procedure, we need 2 −1 multiplications of a label with "order" . Order refers to the procedure of 2 -tuples from the leftmost path. Now, we can count the number of multiplications analogously to the leftmost path and obtain Adding the multiplications from second to third column, this amounts to

D ITERATIVE PRODUCTS COMPUTATION
In this section, we describe our implementation of the product computation for Cheon et al. 's scheme. We start by recalling the task to be computed. Given integers 1 , . . . , , we want to compute products = =1 , for = 2, . . . , with logarithmic multiplicative depth. Cheon et al. [15] propose to compute the products using a recursive algorithm that builds a binary tree of products. That is, we start with 1 , . . . , , compute products ′ 1 = 1 · 2 , ′ 2 = 3 · 4 , . . . for the first level and continue this recursively until there is a single element left in the last level. At each level, if the number of elements is odd, then the last element is left alone. This yields products for positions which are a power of 2. In the next step, we compute the missing products, i.e., for positions that are not a power of 2, based on a multiplication of the results for the power of two cases and the power of 2 decomposition of .
Our implementation described in Algorithm 13 stores the binary tree of products in a matrix [] [] with log( ) − 1 rows and /2 columns, where row contains /2 non null elements, for = 1, . . . , log( ) − 1. Then, the first column contains the products for a power of 2.
For the remaining positions not a power of 2, we decompose in its power of 2: 1 , . . . , such that = 2 , = 1 + . . . + and 1 > . . . > . Then, we use each to select a corresponding product from the matrix computed above. We observe that if = 1 then = [ ]. Otherwise, we compute the row and column of the product corresponding to , i.e., = [ ] [ ] as follows: • we remark that if = 2 , then the corresponding product lies in the row = of the matrix. • for the column, if = 1, then it is the first column, i.e., = 1 otherwise we compute the column as = ⌈ / ⌉ − 1 where = 1 + . . . + .
Finally, we collect all the products ( 1 , . . . , ) and apply again a multiplication with logarithmic depth to compute 1 · . . . · using the binary tree of products as above.

E CHOICE OF AHE SCHEME
For AHE, we choose ElGamal encryption [19] that we implement as elliptic curve ElGamal (ECE) [33,34]. We briefly describe it in the following and refer to the literature for more details. Let G be an elliptic curve group over F( ) generated by a point of prime order . ECE consists of the following algorithms: • Key Generation pk, sk ← KGen( ): This algorithm randomly chooses ∈ Z and outputs sk = and pk = · as private and public key. • Encryption c ← Enc(pk, m): This algorithm takes pk and a message m, then it chooses a random ∈ Z and outputs the ciphertext c = ( · , m · + · pk). • Decryption m ← Dec(sk, c): This algorithm takes sk and a ciphertext c = ( 1 , 2 ), compute = 2 − 1 · sk and returns the discrete logarithm of on G.

39: return
While the decryption requires the computation of the discrete logarithm, we stress that in our comparison protocol, computing the discrete logarithm is not necessary since we are looking for a ciphertext of zero. A ciphertext of zero has the form c = ( · , · pk). Hence, checking if the random ciphertext c = ( 1 , 2 ) is encrypting 0, is efficiently done by computing = 2 − 1 · sk and then checking if is the neutral element of G that for an elliptic curve is the point at infinity.

F MOST RECENT WORK
Most recent work include protocols [4,20,39] based on the arithmetic black-box (ABB) model. The ABB model allows addition on encrypted inputs and constant multiplication. It can be implemented using secret sharing or AHE. Some ABB-based protocols ( [17] and the improved version [39]) have some resemblance with our scheme as they rely on the bit decomposition of the inputs, and compute equality of bits and aggregate them. Other schemes rely on the extraction of the most significant bit of the difference of both inputs [4,20].
When implemented with secret sharing, ABB-schemes have a very fast local computation and allow unconditional security. They support several parties (more than 2), where parties have symmetric role in the protocol, i.e. each party perform the same computation on secret-shared inputs. However, they also require an offline phase to generate so-called Beaver triples; they require secure channel to avoid share reconstruction by an eavesdropper; they usually run in asymptotically multiple rounds, which can affect the overall performance.
Our scheme is secure as long as the underlying encryption scheme is secure. We support only 2 parties, where each has a specific role: one party (server or evaluator) evaluates the tree and the other one (client or decryptor) decrypts the result. We do not need an offline phase, but only a one-time setup phase, where the decryptor generates a pair of private and public key and publishes the public key. We do not require a secure channel as each message is already encrypted. We have exactly a single round, where the client sends its encrypted input to the server and gets an encrypted result. An overview comparison is summarized in Table 5. [4,20,39] Ours

G EVALUATION OF DECISION TREES
A decision tree (DT) is a common and very popular classifier that consists of decision nodes, each marked with a test condition, and leaf nodes, each marked with a classification label. Each test condition is actually a GT or LT comparison between a threshold value and an attribute of the input to be classified. In a private DT setting, a server holds a private tree model and a client holds a private attribute or feature vector. The goal is to classify the client's input using the server's model such that the result of the classification is revealed only to the client and nothing else is revealed neither to the client nor the server. Wu et al. [51] and Tai et al. [42] proposed a private DT protocol, that uses the DGK comparison and AHE. We implemented the private decision tree protocol of Tai et al. [42] in Java. Our implementation is not optimized and focuses on the main computation (GT comparison of features and thresholds, and paths aggregation), i.e., we ignored e.g. zero-knowledge proof, compression of elliptic curve points or network communication. We then evaluated the decision tree protocol instantiating the GT comparison with DGK [18], Veugen [49] and our scheme and observed a performance result comparable to Table 3. Basically, one can expect an improvement proportional to the number of comparisons. The result averaged over 100 runs is shown in Table 6 for a decision tree with depth = 17, number of decision nodes = 58 and number of features = 57, which corresponds to the parameters of the Spambase dataset as in [42,45,47,51]. We used bitlength = 8, 16, 32, 64, 128 for the features and thresholds.