Constant-Round Private Decision Tree Evaluation for Secret Shared Data

Decision tree evaluation is extensively used in machine learning to construct accurate classification models. Often in the cloud-assisted communication paradigm cloud servers execute remote evaluations of classification models using clients’ data. In this setting, the need for private decision tree evaluation (PDTE) has emerged to guarantee no leakage of information for the client’s input nor the service provider’s trained model i.e., decision tree. In this paper, we propose a private decision tree evaluation protocol based on the three-party replicated secret sharing (RSS) scheme. This enables us to securely classify inputs without any leakage of the provided input or the trained decision tree model. Our protocol only requires constant rounds of communication among servers, which is useful in a network with longer delays. Ma et al. (NDSS 2021) presented a lightweight PDTE protocol with sublinear communication cost with linear round complexity in the size of the input data. This protocol works well in the low latency network such as LAN while its total execution time is unfavourably increased in the WAN setting. In contrast, Tsuchida et al. (ProvSec 2020) constructed a constant round PDTE protocol at the cost of communication complexity, which works well in the WAN setting. Although their construction still requires 25 rounds, it showed a possible direction on how to make constant round PDTE protocols. Ji et al. (IEEE Transactions on Dependable and Secure Computing) presented a simplified PDTE with constant rounds using the function secret sharing (FSS) at the cost of communication complexity. Ourproposed protocol only requires five rounds among the employed three servers executing secret sharing schemes, which is comparable to previously proposed protocols that are based on gar-bled circuits and homomorphic encryption. To further demonstrate the efficiency of our protocol, we evaluated it using real-world classification datasets. The evaluation results indicate that our protocol provides better concrete performance in the WAN setting that has a large network delay.


INTRODUCTION 1.Background
Privacy-preserving machine learning (PPML) enables us to analyze a large amount of data without revealing any sensitive information.More precisely, PPML allows service providers to compute statistics and learning models using sensitive datasets (e.g., healthcare data or individual DNA information) and perform advanced data analytics while providing high privacy guarantees to the involved clients; making people feel safe and less hesitant to upload sensitive information to access specific services.Thus, PPML can support and allow large-scale data collection and advanced data analytics.PPML mainly focuses on the design of privacy-preserving machine learning models computed via deep neural networks (DNN), linear regression, logistic regression, support vector machine classification, as well as decision tree classification.One of the main challenges in PPML research is execution speed, so it is important to construct a practical and efficient PPML scheme.
Research on PPML has received significant attention employing different cryptographic primitives.Some of the most popular PPML approaches are based on secure multi-party computation (MPC) schemes such as fully homomorphic encryption (FHE) [24], garbled circuits [51], secret sharing, or a combination thereof.Some recent work in PPML includes privacy-preserving DNN such as Chameleon [43], Gazelle [29], and SecureML [38] in the two-party setting, ABY 3  [37], SecureNN [48], FALCON [49], and Adam in Private [4] in the three-party setting, as well as FLASH [13] and Trident [16] in the four-party setting.The main objective in this line of research is secure prediction (evaluation) and their feasibility has been demonstrated using small datasets such as the MNIST dataset.Another line of research has focused on achieving privacypreserving and secure training [4,13,37,38,48].
The main focus of this paper is Private Decision Tree Evaluation (PDTE), which is one of the main tasks of PPML.Decision trees are widely used in machine learning and have many applications in medicine (e.g., remote diagnosis) or finance.In the cloud-assisted communication paradigm, cloud servers allow remote evaluations of classification models.In this setting, remote evaluation requires that the model remains secret and known only to the service provider, while the service provider should not find out the client's input data.Thus, the need for PDTE has emerged to guarantee no information leakage for the client's input and service provider's decision tree.
In this study, we adopt a secret-sharing-based MPC scheme as the underlying system.Secret-sharing-based MPC allows efficient computation of various functions with a small amount of communication.For instance, there have been many privacy-preserving protocols for basic operations such as less-than/equality check [14,18,20,40,41], division [8,26,39], shuffle [15], and database join [34], just to name a few.Among this line of work, [20,40,41] provided a constant-round less-than protocol over a field and [46] provided a constant-round less-than protocol over a ring.These works have shown that MPC can run at practical speeds since the main overhead of secret-sharing-based MPC arises from the communication delay depending on the number of communication rounds in many cases.

Related Work
Existing private decision tree evaluation (PDTE) protocols rely on homomorphic encryption (HE) and garbled circuits (GC) [6,11,44,47,50], secret sharing (SS) schemes [27,36,46] or a combination of these primitives.The best choice depends on the environment because these primitives often have a trade-off regarding the required computation cost, communication cost, the targeted computed circuit size and scalability of the threat models.We mainly consider environments where communication delays are dominant, such as WAN settings.An effective goal in such settings is to reduce the number of communication rounds, preferably regardless of datasize.
Most of the existing PDTE protocols that achieve constant communication rounds are based on HE or GC.However, instead of high round complexity, these schemes often require high computation costs, communication complexity, or the use of limited computation settings.For instance, Wu et al. [50] only considered the two-party client-server setting where the server holds a trained decision tree and the client holds a feature vector as input.The scheme of Wu et al. employs oblivious transfer (OT) and additive HE.Subsequently, Tai et al. [44] have improved Wu et al. [50]'s scheme significantly in the semi-honest setting, but the scheme still involves heavy cryptographic primitives, additive HE and OT.
As opposed to the above approach, another line of research has proposed PDTE protocols [27,28,36,46] based on secret-sharing (SS) schemes.The advantage of SS-based protocols is their low computational cost and low communication volume, compared to HE-based and GC-based protocols, which generally require heavy computations.On the other hand, a general drawback of SS-based protocols is the large number of communication rounds.For instance, the PDTE protocols that were introduced in [27,36] require O () rounds for a decision tree with height .
Recently, several SS-based constant-round PDTE protocols have been proposed.Tsuchida et al. [46] have performed a significant improvement in this line of research by proposing the first constant communication round (25 rounds) PDTE protocol, where the number of rounds is independent of the height of the tree model.Their proposed protocol is defined over a residue ring (contrary to all previous works relying on finite fields) providing important improvements in computation and communication cost while relying on a secret sharing scheme and three-party computation.Ji et al. [28] claimed that their PDTE protocol required only 4 communication rounds using a function secret sharing (FSS) technique.However, the protocol has some drawbacks; (i) its comparison phase allows only one type of comparison operation, (ii) the PDTE protocol cannot be deployed directly as a subprotocol unless it executes an additional share transformation operation since the final output of the servers is not in the same secret sharing format as the input, and (iii) it needs to store a lot of pre-computed randomness for FSS (i.e., FSS keys).We highlight the difference with our proposed protocol in more detail in Appendix B.
In this paper, we investigate the question of whether it is possible to further improve the performance of a constant communication round PDTE protocol that relies on secret sharing and is defined over a residue ring.In particular, we aim to improve the communication complexity and computational cost compared to the SS-based schemes of Tsuchida et al. [46] and Ji et al. [28].

Contribution
In this paper, we present a private decision tree evaluation (PDTE) protocol that admits a five-round online phase.Our scheme works with a 2-out-of-3 replicated secret sharing ((2, 3)-RSS) scheme over a ring, so it does not rely on heavy cryptographic primitives such as OT or HE.In particular, we focus on the outsourced setting, in which the computing servers cannot know or use any sensitive information about the input and output data.The outsourced setting provides stronger security than the client-server setting and enables a wider range of applications such as federated learning.For those who are interested in the PDTE protocols in the non-outsourced setting, please refer [21,36].
Fig. 1 shows a possible scenario of the outsourced setting using (2, 3)-RSS.As shown in Table 1, the round complexity of our scheme is 5 times more efficient than the current state-of-the-art constantround protocol [46].Our proposed PDTE protocol is secure in the presence of semihonest adversaries in the honest majority setting and is composed of three novel sub-protocols: (i) a one-round feature selection protocol, (ii) a two-round comparison protocol, and (iii) a two-round path evaluation protocol.Table 1 shows an overview of our protocol and highlights the difference with previous work.
1.3.1 Feature Selection Protocol.Our feature selection protocol uses a randomize-then-reveal technique for a secret shared vector, more specifically, a roulette-then-reveal technique, instead of using relatively heavy public key cryptographic primitives such as FHE.
Laud [33] presented a feature selection protocol using general MPC, which achieved O () round offline phase and a constant round online phase, where  is an array size.Blanton et al. [7] also introduced a general construction of the feature selection protocol for any number of computing parties under the Shamir secret sharing, which achieved constant online/offline rounds.Our result will be put among these constructions as a special case of the threeparty setting that achieves a constant round online/offline phase.Please see Table 2 for comparison.
Faber et al. [23] use a "data-rotation" operation, which is similar to our roulette operation.However, their binary-tree ORAM approach proceeds a layer by layer in a tree, which takes a logarithmic order of communication rounds for an input size, while our feature selection protocol only requires one (constant) communication round.Bunn et al. [12] improved such an ORAM approach to obtain a constant round 3-party ORAM by using a distributed point function (DPF).However, their construction requires the client to generate input-dependent DPF keys, which we would like to avoid because the input to the feature selection protocol is not always from clients or other entities who know the input value itself.In other words, the input to the feature selection can be a secret shared value that nobody knows its original value.
The key idea to construct it in the RSS setting is to generate appropriate correlated randomness by Rouletteprep.Well-structured randomness helps servers to reduce the number of communications between each other by cancelling out an accumulated term.Both Roulette and its offline sub-protocol Rouletteprep help to construct an efficient feature selection protocol and are of independent interest since they are related to applications such as a secure database search or an oblivious array read.
Note that Araki et al. [3] constructed an efficient secure shuffle protocol, which can be seen as a general case of our roulette protocol.However, our roulette protocol takes the best advantage of its simpler functionality than shuffle protocols and it only requires one communication round while the secure shuffle protocol requires two communication rounds.

Comparison Protocol.
To construct an efficient comparison protocol, we use the existing less-than protocol and equality check protocol constructed in the 2 + 1 server function secret sharing (FSS) setting [9].These protocols cannot be smoothly adopted in our setting because of the difference in a share type, where the FSS setting uses a (2, 2)-secret sharing (SS) scheme, while ours uses a (2, 3)-RSS scheme.SC-AND Thus, we introduce the SC-AND protocol that enables us to execute share conversion from (2, 2)-SS to (2, 3)-RSS and execute the AND protocol at the same time, which only requires 1 round.

Path Evaluation
Protocol.We introduce a new MPC primitive for randomizing tree models, oblivious tree shuffle, to achieve a tworound protocol for path evaluation.Oblivious Tree Shuffle.Oblivious tree shuffling takes a shared tree as input and outputs a shared shuffled tree with node-wise random flip, which preserves the relations between a parent node and its child node.Thus, it allows us to use the shuffle-and-reveal technique for a binary tree to obtain a required leaf value.
Our tree permutation technique is inspired by the "PermuteTree" protocol that has a logarithmic round complexity by Ma et al. [36].We improved it to realize a constant round tree permutation.Now, we highlight the difference between our construction and Ma et al.'s.
First of all, Ma et al.'s PermuteTree protocol prepares ℎ random bits to randomize a decision tree for the tree's height ℎ, where we consider ℎ ≈ log  for a bit length of inputs,  .Using such randomness, their PermuteTree randomizes all nodes in the same layer using the same flip-bit.This technique is essentially the same as the XOR permutation in [5].In contrast, our tree permutation prepares 2 ℎ random bits and every node is randomized independently using a different random bit, which enables the algorithm to execute within constant communication rounds.Although this increases storage for pre-computed randomness, the reduction of round complexity helps to shorten the execution time.
Secondly, a path evaluation protocol in [36] evaluates node labels from a root node to a leaf node one by one.Thus, its communication cost in terms of data amount is small but it requires O (ℎ) rounds.In such an algorithm, using XOR permutation is enough to hide intermediate information.In contrast, our path evaluation protocol executes a randomize-then-reveal for all node labels.In our setting, an XOR permutation will not generate uniformly random labels.Therefore, we invented the tree permutation that helps not to leak any information even after revealing (randomized) labels.
1.3.4Overview.We now give an overview of our results.Constant Round Protocols in Secret Sharing.To the best of our knowledge, Tsuchida et al. [46] introduced the first constantround PDTE protocol using a secret sharing scheme over a residue ring.Our PDTE protocol requires only 5 online rounds, while [46]'s PDTE requires 25 online rounds.Table 5 shows a more detailed comparison of the required round complexity.
Our feature selection protocol requires only 1 online round, the comparison protocol requires 2 online rounds, and the path evaluation protocol requires 2 online rounds.These make the total required rounds to be equal to 5. Since all offline communication can be done at once, the total number of offline rounds is equal to 2.
Compared to the state-of-the-art round-efficient scheme [28], our scheme achieves an asymptotic improvement in terms of online communication complexity.Our protocol does not have to fully rely on functional secret sharing schemes as in Ji et al. [28].Thus we achieved less communication complexity and less storage cost than [28].Use Cases.We highlight the use cases where our protocol fits well.We succeeded in reducing the round complexity at the expense of the larger communication complexity compared to linear-round protocols such as Ma et al. [36].Our protocol is particularly advantageous when used in a network with a significant delay, such as real-world WAN.For BREAST dataset, we have a running time of 0.86 seconds in the WAN setting with 160 ms of network latency while Ma et al. [36] requires approximately 3 seconds in the WAN setting with a smaller network delay, 80 ms.See Sect.4.2.
Our proposed protocol is designed to work well in the offline/online paradigm.Compared to prior work [28], the online phase of our scheme allows us to avoid some random generation operations such as FSS key generation.This reduces online computational complexity and allows larger decision-making models, such as DIABETES-18, in constant round communication, as shown in Table 7. Experiment with Real-World Datasets.We ran experiments on four classical real-world datasets; Wine, Linnerud, Breast cancer, and Digits dataset from the UCI machine learning repository [22].For each dataset, we obtained a decision tree as a trained model in the clear and adjusted the decision tree to be a perfect binary tree by adding a certain amount of dummy nodes.Then, we executed our PDTE protocol for each model and measured the required execution time.As shown in Table 7, our evaluation experiments demonstrate that our secure protocol finishes the evaluation within a reasonably short time.Thus, our PDTE protocol is not only based on a solid theoretical foundation, but it is also very efficient and practical.The bitlength of , i.e.,  ′ = ⌈log ⌉ ℎ The depth of decision tree (idx  ,   , cond  ) The label of decision node  ∈  ℎ−1 val ℓ The label of end node ℓ ∈ Z 2 ℎ

PRELIMINARIES
In this section, we describe the notation and the model we consider.
Frequently referred notation is listed in Table 3.

Notation
Let  be a positive number of power 2. We write Z  := Z/ Z.We use bold symbols (e.g., , ) to represent vectors, and let   denote the -th entry of .Let ⊕ be an operation of XOR of bits.When it is used with vectors, it denotes an element-wise XOR of vectors.Let S  denote the symmetric group on a set of size .We denote by  2 •  1 ∈ S  the composite of  1 and  2 .That is, ( 2 •  1 ) () :=  2 ( 1 ()).For a vector  of length , we write the permutation application action as ( • )  :=   () .In particular, when considering circular shift permutations, we write the result as shift(,  ) if For  ∈ Z  , we let |  denote the -th digit of .Here  starts from the least significant bit as 0. For example, 6| 0 = 0, 6| 1 = 1 and 6| 2 = 1.
Let  ℎ denote the set of nodes in the complete binary tree of height ℎ.Concretely, we write Here, (, ) represents the -th node (from left) of depth .Accordingly, the parent node of (, ) is ( − 1, ⌊  2 ⌋).We define the function anc : {0, . . ., ℎ} × Z 2 ℎ →  ℎ as anc(, ) = (, ⌊  2 ℎ− ⌋), which means that node anc(, ) is the ancestor node at depth  of the -th leaf.Let  ℎ := Z  ℎ 2 .Then  ℎ can be seen as the set of assignments of a boolean label to each node in the complete binary tree with height ℎ.For  ∈  ℎ , we denote by  , the label for node (, ).
Servers are represented by S 1 , S 2 , and S 3 .Note that operations occurring at indices in S indicate modular arithmetic, i.e., S −1 turns to be S 3 for  = 1, and S +1 turns to be S 1 for  = 3.

Replicated Secret Sharing
Throughout this paper, we use three types of secret sharing schemes.
Reconstruct Servers can communicate with each other to reconstruct the secret value  from a share of .A naive reconstruction algorithm in the semi-honest setting is that each S  sends   to S +1 simultaneously and obtains the sum of the received value and the values in    .We write Reconst for this algorithm.
We would like to note that we define a boolean share   in a similar manner by using randomness  1 ,  2 ,  3 such that  =  1 ⊕  2 ⊕  3 [2].When considering two different domains, Z  and Z  , of arithmetic shares, we will explicitly write •  and •  for shares over each domain.Also note that for any vector , we simply write  for a vector consisting of shares of all the entries in .

⟨ ⟨•⟩ ⟩-Sharing
As an adjunct to the RSS scheme, we also use the 2-out-of-2 additive secret sharing scheme.We will write ⟨ ⟨⟩ ⟩ for an additive share (between S  and S  ) of  ∈ Z  , which consists of two random values (  ,   ) ∈ Z 2  satisfying  =   +   .Here, S  and S  hold ⟨ ⟨⟩ ⟩  =   and ⟨ ⟨⟩ ⟩  =   , respectively.
When considering sharing a permutation, we use the RSS scheme for permutations.For  ∈ S  , we will write ⟨⟩ for a RSS share of .Here, S  's share is defined as In these secret sharing schemes, we assume the following operations.Note that this paper counts the number of communication rounds assuming a duplex network, so it does not necessarily mean a "round trip".If two-way communication is possible simultaneously, we count it as 1 round.If one is performed depending on the other, we count it as two rounds, even if the directions differ.
Local operations Given   ,   , and a public value  ∈ Z  , the servers can compute shares of secure addition  +   , multiplication with a public value  •   , and an addition with a public value  +   locally without any communication among the servers [2].< ⟩ ⟩  by using precomputed correlated randomness.We write Equal and LessThan for these functionalities.Each requires one communication round [9].

Share Conversion
Given   , any two of the three servers can obtain ⟨ ⟨⟩ ⟩ by local computation without communication [19].We write ShareConv for the conversion.We assume that the output of ShareConv is uniformly random when viewed from the third server.Conversely, the servers can also convert ⟨ ⟨⟩ ⟩ given by any two servers to   , with one communication round.We will write ShareConv −1 for this inversion.Detailed definitions of our protocols for these operations can be found in Appendix.
Oblivious Shuffle Given a share   of an -degree vector and a share ⟨⟩ of  ∈ S  , the servers can compute a share  (or a revealed vector ), where  is the vector obtained by applying  to .We write Shuffle (resp.ShuffleReveal) for the oblivious shuffling operation.Both of these operations require two communication rounds [17].
Random Share Generation When given a parameter  , the servers can generate a share  , where  ∈ Z  is picked uniformly at random.We will denote by RndGen( ) the functionality for generating random shares.
For the (2, 3)-RSS, there are two RndGen protocols depending on the security requirements proposed in [2].In the informationtheoretic security setting, RndGen is achieved with one-round communication if each party S  picks a random value and sends it to S +1 .In the computational security setting, RndGen can be achieved without communication, assuming that S  and S +1 hold a common secret key about which S +2 knows nothing.

Security
In this paper, we consider security for three-party computation (3PC) protocols in the presence of a static semi-honest corruption of at most one server with no collusion.Semi-honest security is sufficient when the computing parties (servers) somewhat trust each other or when all secure operations are embedded in each server and are not tampered.We focus on semi-honest security and leave the development of a malicious secure PDTE protocol for future work.
Definition 2 (Semi-honest Security).We say that a protocol Π perfectly realizes a functionality F in the presence of a static semihonest corruption if there exists a polynomial time simulator Sim such that for any  ∈ {1, 2, 3} and any ì Our proposed protocols are proven to be secure by using the hybrid model, where servers execute a protocol with messages and have access to a trusted party that computes a sub-functionality for them.

Decision Tree
There are two aspects in a decision tree classification; one is a training phase that creates a classification model and another is an evaluation (inference) phase that predicts the class of input data by using the model.Throughout this paper, we focus on the evaluation phase and we assume that we already have a model in shared form.
To facilitate comprehension, we now introduce the model in the plain setting and not in the secret shared setting.Let {attr  } −1 =0 be an attribute vector that represents an input to be evaluated, where  is the size of the attribute vector that is determined by a trained model.We assume that the trained model is a complete binary tree with height ℎ, size of an attribute vector , an index vector idx   ∈ ℎ−1 , a threshold vector    ∈ ℎ−1 , a condition vector cond   ∈ ℎ−1 , and a leaf value vector {val ℓ } 2 ℎ −1 ℓ=0 .A decision tree model T is defined as follows: By abuse of notation, given an attribute vector , T () represents the result of the decision tree on .Fig 2 shows an example of a decision tree with height ℎ = 3 and  = 4, in which each inner node (, ) contains an index idx , , a threshold  , and a conditional value cond , .Given an attribute vector {attr 0 , attr 1 , attr 2 , attr 3 } as input, the evaluation algorithm starts at node (0, 0).
If a comparison operation outputs 0 (resp.a comparison operation outputs 1), then the algorithm indicates us to move onto the left child node (1, 0) (resp.right child node (1, 1)).The above steps are iterated until the algorithm reaches a leaf node.Once it reaches

PathEvalPrep
FSS key and corr.rand.generation r q p L x q J H T 8 + 2 j c 2 Y 5 I z I p q s w w p p 8 2 3 S S + + X j a n o m 1 k 6 b K J 6 B t S W K Z 8 j j a P I f I 4 k j f k / P T L 2 W N 7 Y s c r Q n V B y 2 s i z s o w n D C q P s 6 V 2 o O w p S O d i 1 K y 7 y V 7 5 k i q + k I + e P A Z u B x 7 X j v 6 U N h v P h 3 3 n q / 6 X z + C V P b B W 3 1 3 r Y + t T 6 z P L s b 6 2 H l r f W W P r 2 M L W G + s X 6 1 f r t 6 0 / t / 7 Z v r 1 9 Z 0 W 9 e W M 9 5 g N r 4 9 u + 9 x + o 9 5 a R < / l a t e x i t >

3
< l a t e x i t s h a 1 _ b a s e 6 4 = " q w 2 n c E q q a z S S e 3 m J i  + / 3 q m X 3 P + s L 6 y v r G s q 0 n 1 r 7 1 o z W w z i x i / W n 9 b f 1 j / d v e b j 9 p f 9 / e X 1 L v 3 q n G f G 6 t f e 2 f / g M o I q e 6 < / l a t e x i t > A J a N 0 7 a D l 7 X a L V a 7 z b a n 6 6 0 T o J G P A B P w y 2 8 C U / A a 3 C 0 X m f X k j P M N D v j s c 6 n T 9 8 5 O j r 6 8 X M W c z E Y / H P j 5 l t v v / P u e 7 f e 7 2 x t 3 / 7 g w 5 0 7 H z 3 j W o o g y q q u l A o c r M I e C u a i g 3 R X E S Q T E j s e Y D w t z C r P S 4 S C v K G o b w h u q l 7 K 7 q 8 C D 4 R p r 3 6 7 2 3 f M Y T u e M e l / U j Z X M C l 0 2 e h 0 I V / d I J R + r T X q p m g z f S B C i r C W N G k q u q 5 r Y g f q X E 2 / m s 6 c 6 H o s b 8 n 5 9 p e y x t 7 F h p q E 5 8 e t H I s 7 S 0 J w w u j r O t c q A c S U j l E t y s u / l R 8 Z L K v s m f P H s K 3 B 4 8 r k 3 1 K a 0 3 X k 5 G 5 r e j R y 8 e D R 6 P y 2 f 2 f e N z 4 0 v j K 8 M 0 v j M e G z 8 a M + P c I M b W + M P 4 0 / i r / 3 f / 3 3 1 j f 2 9 H 3 b t X j v n M a H 3 7 / f 8 A 1 q 2 Q j Q = = < / l a t e x i t > x N h j e W P H K k N 3 Q s l 5 I 8 / K M p 4 w q D z O 5 t q B c q A g n Y t R s + 5 G B + V L q r g v H z 9 9 A t w W P K 4 d / S l t N l 7 0 u 8 4 3 3 a + f w y t 7 1 1 p + d 6 z P r S + s X c u / H j 9 8 5 P D y 8 e C m j X P R 6 / 9 y 6 / c 6 7 7 7 3 / w Z 0 P W 1 v t j z 7 the leaf node, it outputs the corresponding leaf value as a decision (classification result).

CONSTRUCTION
We construct a three-party scheme for private decision tree evaluation (PDTE).Our main focus is the outsourced setting: three outsourced computing servers, a service provider (or tree owner) with a trained decision tree model, and clients with an attribute vector as input.The service provider generates shares of the decision tree model and distributes them to three computing servers.Similarly, each client does the same with its own input attribute vector.Since the computing servers only receive values in a shared form, none of the servers can obtain any information about the input data other than the data size.The computing servers cooperatively execute a PDTE protocol and return the shares of a decision result to the client.Finally, the client can reconstruct the evaluation result from the received shares.Formally, we consider the ideal functionality of PDTE shown in Functionality 1.All inputs and outputs of the scheme are given as shares in the 2-out-of-3 replicated secret sharing scheme.Note that the scheme only allows at most one corruption, i.e., the honest majority setting.PDTE takes as input a shared attribute vector, and a shared decision tree model consisting of an index vector, a threshold value vector and a conditional value vector with size 2 ℎ − 1 which corresponds to the inner nodes, and a shared leaf value vector with size 2 ℎ .PDTE outputs shares of the result of the (plaintext) decision tree evaluation procedure on the input private values.
Fig. 3 shows the overview of our protocol.Our protocol design follows the framework proposed in [31].In this framework, the PDTE procedure is divided into three phases; feature selection phase, comparison phase, and path evaluation phase.The feature selection phase securely chooses a designated attribute from the attribute vector for each inner node (2 ℎ − 1 nodes in total).In the comparison phase, the resulting attributes are securely compared against thresholds for all the inner nodes at the same time.The path evaluation phase securely computes the certain leaf value as the final result using all the comparison results.We will give a detailed definition of the ideal functionalities of the three phases in Functionality 2-4.

Feature Selection Phase
In this section, we introduce our feature selection protocol FeatSelect (Protocol 4).Functionality 2 shows the ideal functionality of the feature selection phase.The functionality takes a share of an index and a shared attribute vector as input, and outputs a share of an attribute that corresponds to the index.Upon receiving a share of an index idx  and an attribute vector ( attr 0  , attr 1  , . . ., attr −1  ), F featselect reconstructs idx and  = (attr 0 , attr 1 , . . ., attr −1 ), selects attr idx , generates shares attr idx  , and sends attr idx   to S  .
To achieve round-optimal feature selection, we first propose a three-party variant of the two-party oblivious selection protocol in [5].This protocol requires preprocessing to generate correlated randomness, which optimizes the round complexity of the online phase.We construct a protocol Roulette (Protocol 3) and its offline protocols PlainRoulette, Rouletteprep (Protocols 1 and 2).

Preprocessing for
Roulette.We describe a preprocessing protocol for Roulette, which we call Rouletteprep.It aims to generate correlated randomness that enables online-round-optimal execution of Roulette.More specifically, the protocol functionality takes no input, and outputs a shared vector   , a shared shifting value   , and random vectors  and  only given to S 1 and S 2 , respectively.Here   holds a correlation such as  = −shift(,  3 ) − shift(,  1 ) for    = (  ,  +1 ).We write F rouletteprep for the functionality.PlainRoulette The main challenge of Rouletteprep is to securely compute the two shifted values, shift(,  3 )  and shift(,  1 )  .We propose PlainRoulette protocol for oblivious circular shifting in Protocol 1.The input of PlainRoulette protocol is a vector  in the plain form (not the shared form) from the server S  and a shifting value  from the server S  and S  that is also the plain form, where , ,  ∈ {1, 2, 3} are all different.The protocol returns the circular-shifted value in the shared form; shift(, )  .
PlainRoulette requires 2 communication rounds.The first round (Steps 1, 2 and 3) is a variant of the 3-party oblivious transfer protocol proposed in [37].As in the OT protocol, S  and S  first sample a random masking vector  using RndGen.The difference from the OT protocol is that S  sends the entire circular-shifted vector of  to S  , rather than a single element in .After that, the servers execute a share conversion in the second round to obtain a replicated share of shift(, ).

Protocol 1 Plain Circular Shift (PlainRoulette)
Functionality:   ← PlainRoulette( (, S  ), (, S  ), (, S  )) Input: A vector  from S  and a shifting value  from S  and S  for mutually different , ,  ∈ {1, 2, 3} Output: Arithmetic-shared circular-shifted vector   , where  = shift(, ) Proof Sketch (Protocol 1 and 2).We first show the correctness and semi-honest security of PlainRoulette.By definition,   is a share of + ′ , which coincides with shift(−, )+shift(, ) = shift(, ).The security of the protocol is satisfied because the communication is done with masking by a random vector  and  chosen by the sender servers.
By the definition of Rouletteprep, it holds that  = shift(,  3 ) and  = shift(,  1 ), so  is the desired output and correctness is satisfied.Since , ,  1 and  3 are independent randomness known only to the input servers of each PlainRoulette, the parallel two calls to PlainRoulette leak no information.
3.1.2Roulette Protocol.We next present an online protocol for secure roulette (Protocol 3), which works with the RSS setting.Intuitively, the protocol randomly circular-shifts a given shared vector like a roulette machine, while keeping the given vector and shifting values secret from the servers.More precisely, Roulette takes as input a shared vector   , uses a shared shifting value   from the output of Rouletteprep and outputs a share of circular-shifted value   that satisfies  = shift(, ).
Here is an overview of the protocol: S 1 (resp.S 2 ) first locally computes  1 (resp. 2 ) by circular shifting by a random amount and masking with a random vector, then sends it to the other servers.The randomness consumed in computing  1 and  2 is provided as the output of Rouletteprep.In the next step, the servers locally circularly shift the received messages so that every message is shifted by .The final step uses the randomness   to cancel mask vectors  and , resulting in a share   of the circularshifted value.
Our Roulette protocol only requires one communication round.Note that Rouletteprep can be done in an offline phase since correlated randomness is independent of input values.We write it as an auxiliary input.In the online protocol, steps 1 and 2 can be done at the same time, and the other steps require no communication.
This protocol is based on a variant of the shuffle-and-reveal technique for circular shifting.First, the servers pick a share of the random value by using RndGen, which is done offline since it is independent of the protocol's input.Second, using such a share of randomness and given a shared attribute vector, the servers cooperatively execute Roulette to output a share of circular-shifted vector   .Third, the servers locally compute an addition and reveal the value .Lastly, the servers output a share by using the revealed value  and securely obtain the circular-shifted vector   .The protocol takes 1 online communication round.This is because Steps 1 and 3 can be done in parallel.The offline computation is only required for Step 1, and needs 2 communication rounds.Proof Sketch.By construction,  = shift({attr  } −1 =0 , ), i.e.,   = attr ( − mod ) for all  ∈ {0, . . .,  − 1}.On the other hand, we have  = (idx +  mod ).Thus,   =  (idx+ mod ) = attr (idx+− mod ) = attr idx , which shows the correctness of FeatSelect.
The semi-honest security of FeatSelect is derived from the shuffleand-reveal technique.We omit the details since it is similar to the proof for the two-party oblivious selection protocol [5].

Comparison Phase
In this section, we introduce our protocol Compare (Protocol 6) for the comparison phase.The comparison phase aims to identify if the designated attribute at each node satisfies a certain relation with a threshold, where either less-than or equality is computed.Assigned condition values at each node decide which operation should be used.The comparison is performed for each of the 2 ℎ − 1 inner nodes.The ideal functionality of the comparison phase is shown in Functionality 3. The functionality takes as input shares of a decision tree model and an input attribute vector and outputs the comparison results in the shared form at all inner nodes.We focus on the less than comparison and the equality check as comparison operations in this paper and we leave other functionalities for future work.to S  for  ∈  ℎ−1 .
3.2.1One Round Protocols for LessThan and Equal.We use the LessThan and Equal protocols introduced in [9].These protocols execute 2 + 1 party computations constructed in the scheme 'MPC with preprocessing via function secret sharing (FSS)' [10].In this scheme, only two servers join in the online computation.In contrast, the third server needs to pre-generate and distribute FSS keys in the offline phase to be consumed in the online computation.An advantage of these protocols is the optimal online communication complexity.In addition, recent studies have achieved an O (ℓ)-bit FSS key assuming PSG.Here,  is a security parameter.For more details, see [9].

Comparison
Protocol.Our Compare protocol is described in Protocol 6.We provide an overview of the protocol here.In the first step, the servers perform share conversion and two out of the three servers obtain the corresponding 2-out-of-2 additive shares.Then the protocol computes both LessThan and Equal in parallel.Since these conditional values cond , are given in the shared form, the protocol should be data-oblivious with respect to the shared condition values cond , , and must compute both LessThan and Equal.The final step obliviously selects one of the results according to the shared condition value cond , .Note that the oblivious selection can be achieved with a secure AND gate.
We also propose a round-efficient protocol SC-AND for the final step, as shown in Protocol 5.The purpose of the SC-AND protocol is to evaluate an AND gate and share conversion at the same time.1 round as in Protocol 5.The protocol is based on the (3-party) beaver triple technique.Due to the parallelism, the protocol only requires 1 online communication round.Proof Sketch.By the composability of secure protocols, it is sufficient to show that the SC-AND protocol is secure against semihonest adversaries.The security proof of the SC-AND protocol is the same as for the standard Beaver-triple-based secure multiplication protocol except for the case where the third server is corrupted.When S 3 is the corrupted third server, the view of the third server consists of the messages from S 1 and S 2 at Step 2. Since ShareConv guarantees that the outputs a and b are uniformly random, these are uniformly random from S 3 .

Path Evaluation Phase
The final phase of PDTE is the path evaluation phase using the comparison results at every inner node as input.We provide a path evaluation protocol PathEval (Protocol 8) with just 2 rounds.
Let PathEval be the path evaluation functionality defined in Functionality 4. PathEval takes, as input, shares of leaf values and shares of comparison results at every inner node, and outputs the corresponding leaf node that is indicated by the comparison results.Here the tracing step chooses one of the leaf values, whose position ℎ({comp  }  ∈ ℎ−1 ) is given as the unique integer  ∈ Upon receiving a share of a leaf value vector { val ℓ  } To grasp the intuition of the tracing step in PathEval, let us describe how (the plain-text version of) the algorithm will work in the clear.Consider the decision tree in Fig. 2. Suppose that the comparison result at node (0, 0) is 1, that is, comp 0,0 = 1.Then, you move to node (1, 1) (a child node on the right) and see comp 1,1 .When comp 1,1 = 0, you move to node (2, 2) (a child node on the left) and see comp 2,2 .Let us suppose comp 2,2 = 1.Then, you reach the leaf node 5, and finally, you take val 5 as output.

Overview of our PathEval Protocol.
To compute the tracing step in a few communication rounds, we construct an oblivious tree shuffle technique in this section.The purpose of this technique is to shuffle a shared tree obliviously while sustaining the tree structure.The technique lets us detect the right trace path in constant communication rounds by revealing the shuffled node values while leaking no information on the input tree.
The high-level algorithm of our PathEval protocol can be viewed as a tree-structured variant of the shuffle-and-reveal technique [25].Our proposed tree shuffle aims to directly randomize node values while preserving the tree structure, which can improve communication costs.To clarify this advantage, we highlight the difference from the state-of-the-art protocol [46], which uses the original shuffle-and-reveal technique as follows: The servers first convert the binary tree values to a vector, reorder the obtained vector and the leaf label vector using the same random permutation, and reveal the node label vector to choose the desired leaf value.Note that the vector obtained after the first conversion must require 2 ℎ ℎ bits.Our technique avoids such conversion and reduces the data size to 2 ℎ − 1 bits.
We note that the tree permutation we will define is inspired by the technique proposed by Ma et al. [36], but our definition is different from theirs as explained in Sect.1.3.3.Our tree permutation takes a shared tree as input and outputs a shared shuffled tree with node-wise random flip.In our protocol, to make the roundcomplexity constant, every random flip is executed independently of the others, rather than using ℎ random bits as in [36].

Tree Permutation.
We first define permutations based on node swapping on a complete binary tree, which we call tree permutation.Tree permutation is defined for the permutation group derived from  ℎ−1 .Each node value specifies whether or not the two sub-trees under the node are swapped.Tree permutation consists of two operations; a permutation of leaf values and a transformation of inner node values.Definition.Let  ∈  ℎ−1 and  be a vector of length 2 ℎ .The tree permutation of (, ) defined by  ∈  ℎ−1 is given as follows: First, we define the permutation derived from a tree label.For  ∈  ℎ−1 , we define a function for 0 ≤  < ℎ.By definition,   is bijective, so it is a permutation, i.e.,   ∈ S 2 ℎ .For instance, assume that ℎ = 3 and  is as follows, then values from Z 2 3 would be operated by   as follows: (0 1 2 3 4 5 6 7) Next, we define a binary operation (•) on  ℎ−1 .For  ∈  ℎ−1 , we define the tree extension of   as   : where  ↾ −1 ∈  −1 is restricted to be taken from a complete binary tree with depth  − 1.Note that the extended   is also a permutation on  ℎ−1 , which consists of permutations on vectors at each depth, and preserves the relations between a parent node and its child nodes.The binary operation (•) : where ( •   ) is given as ( •   ) , :=    (,) and ⊕ denotes an element-wise XOR of  ℎ−1 .The following is an example of a tree permutation.When  ∈  2 and a vector  of length 8 are given as on the left-hand side, (, ) •  corresponds to the label on the right tree.
Another Formulation.To assist in finding the intuition of tree permutations, we also provide an operational definition of tree permutations.Given (, ) and  ∈  ℎ−1 as input, the calculation of ( • ,  •   ) can proceed as follows: 1: Set (, ) := (, ) 2: for  = 0, . . ., ℎ − 1 do Under the operational definition, the above example of tree permutation is calculated as in Fig. 4.This formulation shows that a tree permutation can be viewed as a composite of node swapping at every inner node.Properties.We remark on important properties of tree permutations: • This means that  =   ( ), thus   =    (  ) = ( •   )  .Oblivious Tree Shuffle.Now we explain our oblivious tree shuffle algorithm.It is defined as a secure computation of tree permutation using random inner node values: Let  ∈  ℎ−1 and  ∈ Z 2 ℎ  , let {   ,   } be input tree values, and let  ∈  ℎ−1 be a random inner node value unknown to any party.Then, the procedure randomizes {   ,   } with , by computing {  •   ,  •    }.Note that this randomization technique satisfies two important properties as follows: (1) If  ∈  ℎ−1 is chosen uniformly at random, then  •  is also uniformly distributed, regardless of what  is.This follows from the fact that ( ℎ−1 , •) is a finite group.(2) The path evaluation algorithm returns the same result for (, ) and ( •,  •  ), as shown above.These properties ensure that oblivious tree shuffling can be used with the shuffle-and-reveal technique.

Path Evaluation Protocol
. We now describe a protocol for the path evaluation phase.The protocol is intended to perform an oblivious tree shuffle, using the (ordinary) oblivious shuffle protocol.Note that Here, the application of   consists of parallel vector permutations at each depth, so we can securely compute it using an oblivious shuffle at each depth.Accordingly, the task of the offline phase is to generate ⟨  ⟩ for some random  ∈  ℎ−1 as an auxiliary input of Shuffle and ShuffleReveal, and the input-independent shared-value  •  −1   .
Offline Phase.We construct an offline phase protocol PathEvalPrep to generate correlated randomness as shown in Protocol 7. The protocol takes 2 rounds.First, ⟨  ⟩ is generated locally by using the random generation algorithm RndGen.This step is well-defined because ( ↦ →   ) is injective.Then, S 1 and S 2 pick a random , and S 2 uses it for masking the value of .After all,  is canceled when considering to reveal inner node labels.As a result, each S  holds a new decision tree (,    ).In step 5, S  locally computes the (plain-text) trace step for input (,    ) to get the resulting position  ′ = ℎ(), and obtains the desired output   ′  .Note that in ShuffleReveal, shuffling   with ⟨⟩ requires a permutation of nodes at each depth.Since Shuffle and ShuffleReveal can run in parallel, the protocol only requires two online communication rounds when we use a known 2-round private shuffling protocols (OptShuffle and ShuffleReveal in [17]) for each depth in parallel.Proof Sketch.The correctness of the protocol directly comes from property (2) of oblivious tree shuffle.The security proof is similar to the proof for protocols using the shuffle-and-reveal technique (for example, [25]).Remark that property (1) of oblivious tree shuffle guarantees that the revealed values  do not leak any information about the input values.

Private Decision Tree Evaluation
We now propose our PDTE protocol in Protocol 9. Remark that the ideal functionality PDTE is given in Functionality 1.The protocol performs FeatSelect, Compare, and PathEval sequentially, so the total number of online communication rounds is 5. Theorem 6.The protocol PDTE for F pdte is perfectly semi-honest secure in the (F featselect , F compare , F patheval )-hybrid model.

EXPERIMENT
In this section, we provide detailed evaluation results of our PDTE protocol.

Setting
As mentioned in Sect.2.4, we assume that the servers obtain a shared decision tree as a (shared) trained model.First, we show our target dataset and then we show how to prepare such trained models from the available dataset.
4.1.1Dataset and model.We select datasets from the UCI machine learning repository [22], which are Wine, Linnerud, Breast cancer, Digits and Diabetes.All of these datasets are also used in [36] to evaluate the performance of their protocols.
The decision tree for each dataset is trained using the scikitlearn [42] toolkit, which enables to set up of the maximum possible height of the desired final evaluation tree.Dummy nodes are then added to this decision tree as in [31] and used for MPC evaluation.Note that comparison with an experiment with sparse trees in [36] and our experiment with a complete tree by adding dummy nodes imply that computation and storage cost in a complete tree is not a big deal, while the bandwidth of the network will affect the total execution time.
From the dataset above, we trained seven different decision tree models ranging from a depth of 5 to 18. See Table 4 and the Appendix C for more details.
4.1.2Implementation Setup.We implemented the online phase of FeatSelect, Compare, and PathEval, in which three parties execute the protocols with respective secret sharings as input and interact with each other.For the offline phase, we evaluate the protocol construction by estimating the actual network communication cost theoretically.For a prototype implementation [1], we implemented our PDTE protocol using Python 3.10.4.We use the sycret Python wrapper [45] to implement the F Equal function.This wrapper efficiently handles both the Distributed Point Function (DPF) and Distributed Comparison Function (DCF) using Rust.Based on DPF, we can realize F Equal within the pre-processing model.However, the sycret wrapper does not offer an implementation for F LessThan .To address this, we follow the approach for creating an interval containment gate, as described in Fig. 3 of [9], to implement F LessThan .
To test the performance of our protocols in a genuine heterogeneous network setting, we used a test bed composed of three droplets provided by DigitalOcean, referred to as S 1 , S 2 , and S 3 .Each of these droplets shares identical configurations, possessing a relatively low specification of 8GB memory and 4-core CPUs, and operating on Ubuntu 22.04 LTS.The geographical locations of the droplets vary, with S 1 situated in San Francisco, S 2 in Singapore, and S 3 in Frankfurt.The RTT latency and bandwidth measured between these servers were, on average, 180ms with 62Mbps between S 1 and S 2 , 160ms with 135Mbps for S 1 and S 3 , and 170ms with 115Mbps for S 2 and S 3 .
To prepare the RSS shares of the trained decision tree models, we first execute the training via non-MPC machine learning algorithms.Then we expand the decision tree to a full binary tree by padding multiple dummy nodes and obtain RSS shares of the tree.
To test the real performance of our protocol, we run our implementations on the above WAN test bed.Here, we execute our protocol with the RSS shares of the test vectors from the UCI dataset and the extended complete binary decision tree.This process allows us to learn the real-world performance of our protocol such as actual computation time and the amount of communication volume.
Both run-time cost and communication volume are measured in the online phase, while we measured only communication volume in the offline phase.More detailed settings are described in Appendix C.

Evaluation
We first estimate the bits sent among the servers and the communication rounds required for our PDTE protocol by definition.We counted them in an online/offline paradigm to focus on the actual execution time after obtaining the PDTE input, and we distinguished offline pre-computations from the online execution.We compare our protocol with the state-of-the-art PDTE protocol [46] theoretically.Since [46] does not distinguish between online and offline rounds, we re-counted rounds to separate them into online/offline in Table 5 and have a fair comparison.
The evaluation results in Table 5 show that our protocol requires almost the same offline rounds as [46] but requires much fewer online rounds.More precisely, our PDTE protocol only requires 5 online-rounds in total while [46] requires 25 online rounds.
Next, we compare our work with the most recent work by Ji et al. [28] that claimed it constructed a 4-round PDTE protocol.Although the functionality of PDTE protocol in [28] is simplified as pointed out in Appendix B, their PDTE protocol requires more communication bits than that of our proposed protocol, i.e., [28] requires approximately 235 MB to execute PDTE on the DIGITS-15 decision tree model, while ours requires approximately 135 MB of communication in total.See the estimation of Ji et al. and ours in Table 5.Note that, in Table 5, the estimation is naively calculated by using the approximated equations of Tsuchida et al. [46] and Ji et al. [28], which only give a rough estimation, and by our exact equation, which gives an estimated minimum cost.
In Table 6, we record the actual online communication cost for each of our subprotocols, while we list the estimated offline communication cost.It shows that the communication costs rise exponentially with the depth of the tree.More specifically, across all phases of our protocols, the communication cost demonstrates a linear relationship with 2 ℎ .In Table 7, we measure the running time of each online subprotocol by calculating the elapsed time from the beginning to the end of the respective subprotocol.We then calculate the average of these measurements across all three droplets.Note that the reported running time includes both the time for sending/receiving message packets on network and the processing of the received messages.To further reduce the execution time, we parallelized data processing during the online FeatSelect and Compare phases.We segmented the collected message from all tree nodes into smaller batches for processing.Each batch, comprising messages from 1400 nodes, was processed in individual threads.Additionally, our design ensures that the sending, receiving, and processing of these messages occur asynchronously.As indicated by Table 7, the online phase executes swiftly for a decision tree of depth less than or equal to 12.However, for trees of depth greater than 15, the vast communication volume and associated computation cost become constraining, even though our protocol maintains a constant round.Factors such as bandwidth constraints, network delays, and processing extensive messages form bottlenecks in execution time.It's worth mentioning that our evaluations ran using Python on modest servers (8GB Memory, 4-core CPUs).Implementing our protocol in a high-performance programming language and deploying it on superior servers will surely expedite the evaluation of deeper decision trees significantly.
The outsourced PDTE protocol by Ma et al. [36] reported in Fig. 15 of Ji et al. [28] has a running time of approximately 3 seconds for BREAST and 10 seconds for DIGITS-15 in the WAN setting with 80 ms of network latency, while our construction takes 0.86 seconds and 9.73 seconds, respectively, in the WAN with two times larger network latency (160-180 ms).This fact convinces us to claim that our protocol works well even in networks with larger delays because of its small constant round complexity.

Figure 1 :
Figure 1: Possible scenario: The tree owner has a binary decision tree as a trained model, while each client has an attribute vector as input to the service.The computing servers only obtain shares of all values from the clients and the tree (model) owner.The classification result obtained via the decision tree can be seen only by the client who sent a query.

Figure 2 :
Figure 2: Example of a Decision Tree with Height 3.
4 m Y h U 1 e d / f s f H P o 5 P 3 J A S I T u d P 2 v r 9 + 4 / 2 G h s P m w + e v z k 6 b O t 7 e d n g s c R w q e I U x 5 d u F B g S h g + l U R S f B F G G A Y u x e f u 5 a H 2 n y 9 x J A h n I 3 k T 4 m k A 5 4 z 4 B E G p 4 p n 2 e + K W e H l K g 1 M 1 a 6 A v j L j 7 r T U i l r d S i 8 y 9 n 8 8 q t y x 2 L i x 2 r C T E H x l 1 F l b F q H b i e 5 e S 6 u h H G o p b a r PU N f + 6 F Q H Z 7 v t 7 n 5 7 7 2 S v d d D L P 0 i b 4 C V 4 D d 6 A L n g L D s B n 0 A e n A A E O f o J f 4 P f G 3 8 a r R q u x c 4 u u r + U x L 0 D p a b T / A Y 8 t 0 W E = < / l a t e x i t >FeatSelect< l a t e x i t s h a 1 _ b a s e 6 4 = " 3 r n P d / y D 8 R / M P 4 k U S J b h K D B 5 l V E = " > A A A H c X i c h Z X d b t M w F M e 9 A e s o X x t c I W 6 i V U h I S F M 7 T c D l 6 B h w A V r X d h + i r S r H c V p r j h 1 i p 9 u I + h L c w o v x H L w A x 2 m r O k 4 n I l X 1 + Z / f 8 b G P 4 x M / 5 k z p e v 3 P 2 v q d u / c 2 K p v 3 q w 8 e P n r 8 I o I 4 + o l + o d 8 b f y v P K 1 5 l Z 4 a u r 8 1 j n q H C U 3 n 9 D 2 4 u 0 A o = < / l a t e x i t > Compare < l a t e x i t s h a 1 _ b a s e 6 4 = " g e l 6 o Q 7 0 J F e n C J I

r a 4 U
M Y 9 B 5 W m 8 + g e g w N C C < / l a t e x i t > PathEval < l a t e x i t s h a 1 _ b a s e 6 4 = " 3 I U I a s O v f L 5 2 P U T 4 T o 3 n U T y 1 M d E = " > A A A H d n i c h Z X d b t M w F M e 9 A e s o H 9 v g E g l F V B N c T e 0 0 A Z e j Y 8 A F a N 3 a f Y i 2 q h z H a a 0 5 d h Y 7 2 U b U 5 + A W H o s 3 4 R I 7 y x T X z k S k q j 7 / 8 z s + z r F 9 4 s e U C N l u / 1 l a v n f / w U p j 9 W H z 0 e M n T 9 f W N 5 6 d C J 4 m C B 8 j T n l y 5 k O B K W H 4 W B J J 8 V m c Y B j 5 F J / 6 5 3 v a f 5 r h R B D O B v I 6 x u M I T h k J C Y J S S e N R w l O K p c Q q K J 6 s t 9 p b 7 e L x 3 E r o e x p a d 5 U n 6 G O / d F x B y f b W 5 2 3 W z u H O 6 3 d b v l B W g U v w C v w B n T A O 7 A L v o A e O A Y I X I C f 4 B f 4 v f K 3 8 b K x 2 X h 9 g y 4 v l T H P w c L T a P 8 D Q t n S g A = = < / l a t e x i t > Rouletteprep < l a t e x i t s h a 1 _ b a s e 6 4 = " 9 O J B o J T E O l c a l 5 p c n m u R V p e f i b U j Y h h c u I p y d Z 5 7 s d J y Y n p I k i n D s F U 5 I Z e E I e g a Z L 8 I + 7 T 9 A U m 4 y 6 K J m 0 P 5 i x e i h D Q 7 x a w 7 x + y 0 s s b y x Y 5 W h O w n p a S P P y j K e M L g 8 z p b a g b K n I J 1 L c L P u J n v l S 6 r 4 Q j 5 6 8 h i 4 H X h c 2 / p T 2 m w 8 H / b t r / p f P o N X 9 s B a f X e t j 6 1 P r c 8 s 2 / r a e m h 9 Z 4 2 t Y 4 t Y b 6 x f r F + t 3 7 b + 3 P p n + / b 2 n R X 1 5 o 3 1 m A + s j W / 7 3 n / A s Z a T < / l a t e x i t > JattridxK N z s o w n D C 6 P s 7 l 2 o B w q S O c S 3 K y 7 4 W H 5 k i o e y q c n z 4 D b g s e 1 r T + l z c b L 3 Z 7 9 u P f o x a P O f r 9 6 Z t + z v r C + s r 6 x b O u J t W / 9 a A 2 s M 4 t Y f 1 p / W / 9 Y / 7 a 3 2 0 / a 3 7 f 3 l 9 S 7 d 6 o x n 1 t r X / u n / w D 4 B 6 e 2 < / l a t e x i t > B b p n y O N I 4 i 8 z m S N O b / f G T s s b y x Y 5 W h O w n p R S P P y j K e M L g 8 z u b a g X K o I J 1 L c L P u h o f l S 6 p 4 K J + e P A N u C x 7 X t v 6 U N h s v d 3 v 2 4 9 6 j F 4 8 6

2 5 I
J b 7 H c Z g 8 1 a i 0 b D l e k 1 6 j + X 3 / O M D w D z 4 T f r t q h B t e X b h 6 I V m K H T 4 7 2 r c 2 Y l Y y K N u t w i a z z b d M r 7 5 e N W d J X s 3 T Y R s 0 M 6 C 1 T P U d a R 5 H 9 H M l a 8 3 9 2 Z O 2 x s r V j t W E 6 i e l p K 8 / a s p 4 w u D r O 5 s a B s q c h k 0 t w u + 5 G e 9 V L S t 5 X j 5 8 + A W 4 H H t e u + Z S 2 G y + 2 + + 7 D / o P n D 7 q P B v U z + 7 b z u f O V 8 4 3 j O t 8 5 j 5 w f n a F z 7 B D n D + d P 5 y / n 7 4 1 / N + 9 s f r r 5 2 Y J 6 8 0 Y 9 5 h N n 5 d v 8 4 j + 2 S J f 3 < / l a t e x i t >

}j2T h 1 <
S d b 5 t e e b 9 s z J K + m q X D N m p m Q G + Z 6 j n S O o r s 5 0 j W m v + z I 2 u P l a 0 d q w 3 T C S W n r T x r y 3 r C o O o 4 m x s H y p 6 G T C 5 G 7 b o b 7 V U v K X l f P X 7 6 B L g d e F x 7 5 l P a b r z Y 7 n s P + w + e P + g + G t T P 7 N v O 5 8 5 X z j e O 5 3 z n P H J + d I b O s Y O d P 5 w / n b + c v z f + 3 b y z + e n m Z w v q z R v 1 m E + c l W / z i / 8 A z i S X + Q = = < / l a t e x i t > {Jcomp j K B 3 l a t e x i t s h a 1 _ b a s e 6 4 = " 8 x o s x p D F 9 i 4 h x I P / S z + P F R f F w P E = " > A A A M Y 3 i c p V b d b t s 2 F F a 7 v 8 7 x t r T b 3 T B A q 2 F g A 1 r D c o p t N w N a p 8 l 2 s b V u n L T F L M e j K M p S Q / 1 U p J x 4 B H e 9 p 9 n t 9 i p 7 g L 3 H D m U 5 k k k H A x I B h n k + f v z O 4 e H h j 5 f R i P F + / 5 9 b t 9 9 5 9 7 3 3 P 7 j z Y W u n / d H H n + z e v f e S p U W

2 t e a e m 1 y b y a 8 P
N 4 q P d T w h g P U S O D P w F y r B B 9 U d 8 W 6 o a 4 n F 5 p 6 t 4 K y j M P N T w C

w 3 8 1 } 2 h 1 j=0< l a t e x i t s h a 1 _
q w s 4 w m D y u N s o R 0 o + w r S u R g 1 6 2 6 8 X 7 6 k x E P 5 5 N l T 4 L b g c e 3 o T 2 m z 8 X L Q c 7 7 p P X r x q P O 4 X z 2 z 7 1 i f W / e t r y z H + t Z 6 b P 1 o j a w T C 1 t / W H 9 a f 1 l / 7 / z b 3 m n f a 3+ 2 o t 6 + V Y 3 5 1 N r 4 2 l / 8 B 0 A 7 l s s = < / l a t e x i t > {JvaljK N b a s e 6 4 = " O x J t D e i 5 E n B E h 9 A X o 2 V N S F 0 X 0 3 U = " > A A A M Y 3 i c p V b d b t s 2 F F a 7 v 8 7 x t r T b 3 T B A q 2 F g A 1 r D c o p t N w N a p 8 l 2 s b V u n L T F L M e j K M p S Q / 1 U p J x 4B H e 9 p 9 n t 9 i p 7 g L 3 H D m U 5 k k k H A x I B h n k + f v z O 4 e H h j 5 f R i P F + / 5 9 b t 9 9 5 9 7 3 3 P 7 j z Y W u n / d H H n + z e v f e S p U W O y Q l O a Z q / 9 h A j N E r I C Y 8 4 J a + z n K D Y o + S V d 7 a v + l 8 t S M 6 i N D n m y 4 x M Y z R P o i D C i A M 0 2 7 3 v C h e x M B H u A t H Z G y k G 0 p U z 8 e b 7 v j w V g 9 P w o S N n u 5 1 + r 1 9 y y b O n w G 3 B 4 9 r R n 9 J m 4 + W g 5 3 z T e / T i U e d x v 3 p m 3 7 E + t + 5 b X 1 m O 9 a 3 1 2 P r R G l k n F r b + s P 6 0 / r L + 3 v m 3 v d O + 1 / 5 s R b 1 9 q x r z q b X x t b / 4 D 0 w o l s w = < / l a t e x i t > s h a 1 _ b a s e 6 4 = " 7 L t r w l 4 1 6 d 5 k H / Z 5 4 w J D s L 6 g X r E = " > A A A M U X i c p V Z b b 9 s 2 F F a z W 2 d n W 7 o 9 7 o W b Y W A D O s N y i m 2 P r d N k e 9 h a N 0 7 a Y p b r U R R l C a Y u F S k n m a D 9 k r 1 u f 2 h P + y l 7 2 6 E s R R K p Y E A i w D D P x 4 / f O T w 8 v N g x 8 7 k Y j / + 5 t / f O u + + 9 / 8 H 9 D 3 v 9 / Y 8 + / u T g w a

2 <
H j 1 4 8 G j w e l 8 / s + 8 b n x pf G V 4 Z l f G c 8 N n 4 0 Z s a 5 g Y 2 t 8 Y f x p / F X / + / + v / v G / t 6 O u n e v H P O Z 0 f r 2 + / 8 B 4 o q Q j g = = < / l a t e x i t > JvalkK N l a t e x i t s h a 1 _ b a s e 6 4 = " o 1 s / j c z 7 C X p e L t Z m n A m 0 P / V f 9 n 4 = " > A A A M U X i c p V Z b b 9 s 2 F F a z W 2 d n W 7 o 9 7 k W b Y W A D O s N y i m 2 P r d N k e 9 h a N 0 7 a Y p b r U R R l E a Y u F S k n m a D 9 k r 1 u f 2 h P + y l 7 2 6 E s R R K p Y E A i w D D P x 4 / f O T w 8 v D g x o 1 y M x / / c 2 3 v n 3 f f e / + D + h 7 3 + / k c f f 3 L w 4 N O X P E o T T M 5 x x K L k t Y M 4 Y T Q k 5 4 I K R l 7 H C U G B w 8 g r Z 3 M k + 1 9 t S c J p F J 6 J q 5 g s A 7 Q O q U cx E g C t D g 5 s x P 0 w s 7 e I r T Z 5 d p i v D g b j 0 b

3 <
8 u w p c H v w u L b U p 7 T e e D k Z W d + O H r 1 4 N H g 8 L p / Z 9 4 3 P j S + N r w z L + M 5 4 b P x o z I x z A x t b 4 w / j T + O v / t / 9 f / e N / b 0 d d e 9 e O e Y z o / X t 9 / 8 D 7 m e Q j w = = < / l a t e x i t > JvalkK N l a t e x i t s h a 1 _ b a s e 6 4 = " D G 6 0 A n K / r c c K / E b n o 1 d Y H D 9 7 p L N b q + N o 9 5 g p a e y u 4 / h p j U C A = = < / l a t e x i t > Shu✏e < l a t e x i t s h a 1 _ b a s e 6 4 = " t 8 U K H L t v i 3 S z 5 7A O i J U Z 6 V i 1 Z P g = " > A A A M e X i c p V Z b b 9 s 2 F F a 7 W + d 4 W 7 o 9 7 k V d Y C A b U s N y s K 0 v B V q n yf a w t W 6 c t M U s 1 6 M o y i J C X S p S T j y B / R N 7 3 8 8 Y s P e 9 b u / 7 L X v Z o W x F M u l g Q C L A M M / H j 9 8 5 P D y 8 e C m j X P R 6 / 9 y 6 / c 6 7 7 7 3 / w Z 0 P W 1 v t j z 7 + Z P v u p y 9 4 k m e Y n O K

Figure 3 :
Figure 3: Overview of our PDTE protocol: Protocols in the dotted box can be executed in the offline phase.The LessThan and Equal protocols are executed by any two servers, while other sub-protocols are executed by the three servers.

Table 1 :
Comparison of Outsourced PDTE Protocols

1 :
S  and S  generate a random vector  using RndGen 2: S  computes  =  −  and sends it to S  3: S  samples , locally computes  ′ = shift(, ) −  and sends it to S  4: S  computes  ′ = shift(, ) +  ′ 5: Servers invoke   ← ShareConv −1 (,  ′ ) Output: A random vector  only for S 1 , a random vector  only for S 2 , an arithmetic shared random value   , and an arithmetic shared vector   for  = −shift(,  3 ) − shift(,  1 ) where    = (  ,  +1 ) 1: Servers collaboratively pick a random value   ← RndGen() 2: S 1 picks a random vector  and S 2 picks a random vector  (, S 1 ), ( 3 , S 2 ), ( 3 , S 3 )) (, S 2 ), ( 1 , S 3 ), ( 1 , S 1 )) 5:   = −   −   6: S 1 returns (,   1 ,   1 ), S 2 returns (,   2 ,   2 ), and S 3 returns (   3 ,   3 ) Rouletteprep Protocol 2 shows our Rouletteprep protocol.The protocol consists of two parallel calls to PlainRoulette, so it takes 2 communication rounds in total.In the protocol, the shared random value   is obtained by using the random generation algorithm RndGen shown in Sect.2.2.The random vector  is picked by S 1 locally and the random vector  is picked by S 2 locally as well.  is computed by secure negation done locally and by PlainRoulette.Therefore, as long as PlainRoulette works properly, the value  satisfies the required relation.Such a well-prepared randomness   is later used in Roulette together with another masking value and random vectors.Theorem 1.The protocol Rouletteprep for F rouletteprep is perfectly semi-honest secure in the F rndgen -hybrid model.
Protocol 4 Feature Selection (FeatSelect) Servers compute   = idx  +   3: Servers reveal  4: Each server S  sets out   =     Theorem 3. The protocol FeatSelect for F featselect is perfectly semi-honest secure in the (F rouletteprep , F roulette )-hybrid model.

Table 4 :
Tree Parameters in Our Experiments

Table 5 :
Round and Communication Cost of PDTE Protocols KBThe estimated communication cost for DIGITS-15 is written after the "⊲"symbol by calculating with  = 32,  = 37,  = 48, ℎ = 15,  = 128.Here,  is the size of feature vector,  = ⌈log  ⌉,  is the smallest prime number greater than ,  ′ = ⌈log ⌉, and  is security parameter for FSS.Note that this estimation is naively calculated using the equations of approximated communication cost in this table so that the numbers only give a rough estimation.

Table 7 :
Running Time of Our PDTE Protocol [s]