NFGen Automatic Non-linear Function Evaluation Code Generator for General-purpose MPC Platforms

2025-05-02 0 0 2.65MB 20 页 10玖币

侵权投诉

NFGen: Automatic Non-linear Function Evaluation Code

Generator for General-purpose MPC Platforms

Xiaoyu Fan

fanxy20@mails.tsinghua.edu.cn

IIIS, Tsinghua University

Kun Chen

chenkun@tsingj.com

Tsingjiao Information Technology Co.

Ltd.

Guosai Wang

guosai.wang@tsingj.com

Tsingjiao Information Technology Co.

Ltd.

Mingchun Zhuang

mczhuang@bupt.edu.cn

Beijing University of Posts and

Telecommunications

Yi Li

xiaolixiaoyi@tsingj.com

Tsingjiao Information Technology Co.

Ltd.

Wei Xu

weixu@tsinghua.edu.cn

IIIS, Tsinghua University

ABSTRACT

Due to the absence of a library for non-linear function evaluation,

so-called general-purpose secure multi-party computation (MPC)

are not as “general” as MPC programmers expect. Prior arts either

naively reuse plaintext methods, resulting in suboptimal perfor-

mance and even incorrect results, or handcraft ad hoc approxima-

tions for specic functions or platforms. We propose a general tech-

nique, NFGen

, that utilizes pre-computed discrete piecewise polyno-

mials to accurately approximate generic functions using xed-point

numbers. We implement it using a performance-prediction-based

code generator to support dierent platforms. Conducting extensive

evaluations of 23 non-linear functions against six MPC protocols on

two platforms, we demonstrate signicant performance, accuracy,

and generality improvements over existing methods.

CCS CONCEPTS

•Security and privacy →Security services.

KEYWORDS

Secure Multi-Party Computation (MPC), Non-linear Function Eval-

uation, Automatic Code Generation

ACM Reference Format:

Xiaoyu Fan, Kun Chen, Guosai Wang, Mingchun Zhuang, Yi Li, and Wei Xu.

2022. NFGen: Automatic Non-linear Function Evaluation Code Generator

for General-purpose MPC Platforms. In Proceedings of Proceedings of the 2022

ACM SIGSAC Conference on Computer and Communications Security (CCS

’22). ACM, New York, NY, USA, 20 pages. https://doi.org/10.1145/3548606.

3560565

1 INTRODUCTION

Privacy-preserving computation, especially secure multi-party com-

putation (MPC), has attracted a lot of attention in both academia

and industry. They provide a promising trade-o between min-

ing the data and privacy protection. People have proposed many

general-purpose MPC platforms [

] that provide

high-level abstractions and practical performance, allowing people

to develop secure data processing applications without understand-

ing the details of underlying MPC protocols.

Most platforms use a version of secret sharing (SS) protocols to

build basic secure operations like

, and comparison (e.g.,

1The source code is released in https://github.com/Fannxy/NFGen

and then construct complex functions by composing them, just like

writing plaintext expressions. The security of compound opera-

tions/functions is guaranteed by the universal composability [

] of

these protocols. These platforms usually provide built-in support

for common non-linear functions such as reciprocal (

𝑥

, for real

number divisions), exponential (

𝑒𝑥

), logarithm (

ln 𝑥

), and square

root (

√𝑥

). They implement these functions either using generic

numerical methods (e.g. the Newton method) or adopting protocol-

specic algorithms like in [15, 39].

It remains a big challenge, however, to support the large variety

non-linear functions in scientic computing and machine learning,

such as

𝜒2𝑡𝑒𝑠𝑡

and sigmoid. The naive approach is to compose them

with built-in functions. E.g., we can compute

𝑡𝑎𝑛ℎ(𝑥)=𝑒𝑥−𝑒−𝑥

𝑒𝑥+𝑒−𝑥

composing two

𝑒𝑥

, one

𝑥

and two

. We refer to this approach as

direct evaluation. Unfortunately, there are four pitfalls.

Pitfall 1: Correctness and precision.

Most practical MPC plat-

forms use xed-point (FXP) numbers instead of the common oating-

point (FLP) ones for eciency. Although there are attempts to sup-

port FLP in MPC [

], the low performance for

prevents peo-

ple from adopting it. FXP still dominates the practical MPC plat-

forms [

]. Unfortunately, ignoring the dierences

between FXP and FLP leads to two severe issues:

First, FXP supports a much smaller range and resolution than

FLP, leading to more overow/underow as well as precision loss.

Even worse, FXP cannot represent

𝑁𝑎𝑁

and

𝐼𝑛𝑓

like FLP. Also,

the inputs/outputs on MPC are in ciphertext, so there is no way to

detect overows. Using

𝑡𝑎𝑛ℎ

as an example, even if the function has

a range of

[−1, 1]

, the intermediate results,

𝑒𝑥

and

𝑒−𝑥

, can easily

overow when

|𝑥|

is large. In plaintext, people use a scaling conver-

sion to enlarge the range of FXP, but in MPC, the encrypted

𝑥

makes

scaling costly. In fact, the built-in

𝑡𝑎𝑛ℎ

function in MP-SPDZ [

]

gives wrong results if

|𝑥|>44

, even if we increase FXP width to

128 bits. Second, each non-linear function has a precision loss that

accumulates if we compose them with multiple steps. Section 7.3

shows more examples of both issues.

Pitfall 2: Performance.

Even with aggressive optimizations, non-

linear function evaluation takes signicant time using MPC. De-

pending on the platform, they can be orders of magnitude slower

than the plaintext version. We measure the relative performance

between non-linear functions vs. basic operations in 6 MPC pro-

tocols and observe dramatic dierences (Table 1 in Section 7.1).

Composing these functions sequentially makes things even slower.

arXiv:2210.09802v1 [cs.CR] 18 Oct 2022

CCS ’22, November 7–11, 2022, Los Angeles, CA, USA. Xiaoyu Fan et al.

Pitfall 3: Generality.

Although we can write many non-linear

functions using the built-ins, some functions are hard to implement.

For example, functions

𝛾(𝑥,𝑧)

Γ(𝑥,𝑧)

and

Φ(𝑥)

are dened as

integrals. It is very tedious, if not impossible, to implement them in

MPC using numerical methods and built-in operations.

Pitfall 4: Portability.

Even if we can aord the engineering eort

to build a complete scientic computation library, there are too

many performance trade-os to make it portable to dierent MPC

systems and applications. MPC systems use a variety of protocols

(to support dierent security assumptions), number representations

and sizes, as well as custom programming languages. Also, they are

deployed in dierent hardware/software/network environments.

We want the computation library to maintain eciency in all cases

with minimal porting eorts.

In this paper, we oer a new scheme, non-linear function code

generator (NFGen), to evaluate non-linear functions on general-

purpose MPC platforms. We approximate each non-linear function

using an

𝑚

-piece piecewise polynomial with max order

𝑘

(we auto-

matically determine

𝑘

and

𝑚

). Our approach has three advantages.

First, it only uses secure

and

operations supported by all pop-

ular MPC platforms, and we can prove that the security properties

are the same as the underlying platform with the same adversar-

ial models. Second, the evaluation is oblivious, i.e., the operation

sequence is not dependent on input data, allowing for predictable

running time and avoiding timing-related side-channels. Third, ob-

taining the approximation is independent of input data and hence

can be precomputed on plaintext.

Key challenges.

Finding a good

(𝑘,𝑚)

-piecewise polynomial ap-

proximation for MPC platforms is a challenging problem. First,

tting polynomials for FXP computation introduces many chal-

lenges: 1) the polynomial needs to meet both the range and the

resolution requirements of FXP, making sure all intermediate steps

neither overow nor underow; 2) an FXP is essentially an integer,

making the polynomials discrete. Fitting one polynomial minimiz-

ing the approximation error is an NP-complete integer programming

(IP) problem. Thus we need to nd an approximation. Second, there

is a trade-o between

𝑚

and

𝑘

: whether we get more pieces (mainly

leading to more

’s) or use a higher-order polynomial (leading to

’s). The choice depends on the performance of the specic

MPC system, as we discussed above.

Method overview.

We compute the polynomial tting as a pre-

computation step in plaintext. In a nutshell, we rst construct a

polynomial with order

𝑘

in FLP using Chebyshev Interpolation [

]

(or Lagrange Interpolation [

] for corner case) and then discretized

it into FXP. We check the accuracy of the FXP polynomial using

random data samples. If it does not achieve the user-specied ac-

curacy, we split the input domain into two and recurse on each

smaller domain. We design a series of algorithms leveraging the

FLP capability to help nd a better FXP approximation, like using

two FXPs to expand the range and improving the precision through

residual functions. Section 4 provides the details of the algorithms.

At runtime, we evaluate the (𝑘,𝑚)-piecewise polynomial in an

oblivious way, i.e. the execution only depends on

(𝑘,𝑚)

, but not

input data. We design an oblivious piecewise polynomial evaluation

(OPPE) algorithm (Section 4.3). To get a good

(𝑘,𝑚)

trade-o on dif-

ferent MPC platforms, NFGen uses a proler to collect performance

metrics of a specic deployment of an MPC platform and learns

a model to predict the performance with dierent

(𝑘,𝑚)

.NFGen

automatically makes the choice using the prediction and generates

MPC-platform-specic OPPE code using built-in code templates.

NFGen provides templates for both PrivPy [

] and MP-SPDZ [

The template is the only platform-dependent part in NFGen, and it

only takes a short template to port NFGen to a new MPC platform.

Evaluation results.

We evaluate NFGen against 6 secret sharing

protocols using

commonly used non-linear functions on both

PrivPy [

] and MP-SPDZ [

]. We observe signicant performance

improvements over baselines (direct evaluation) in

93%

of all cases

with an average speedup of

6.5×

and a maximum speedup of

86.1×

NFGen saves

39.3%

network communications on average. We also

show that we can avoid the overow errors and achieve much bet-

ter accuracy comparing with the baseline, and allow a larger input

domain even with small FXP widths. Using logistic regression (LR)

as an example, we demonstrate performance and accuracy improve-

ments over direct evaluation and ad hoc approximations, with

3.5×

speedup and

0.6% −14%

accuracy improvements. Additionally,

we illustrate how NFGen helps users to easily implement otherwise

hard-to-implement functions on MPC by using 8 complex functions

dened as integrals and the 𝜒2test on real data.

In summary, our contributions include:

1) We propose a series of algorithms to t an eective piece-

wise polynomial approximation on plaintext, fully considering the

dierences between FLP and FXP representations.

2) We design and implement the code generator with automatic

proling to allow portability to dierent MPC systems with distinct

performance characteristics.

3) We conduct comprehensive evaluations against six MPC pro-

tocols on two platforms over 23 non-linear functions, showing

signicant improvements in performance, accuracy, portability to

dierent MPC platforms, usability and savings in communications.

2 BACKGROUND AND RELATED WORK

In this section, we rst introduce the background of general-purpose

MPC platforms and FXP numbers for readers unfamiliar with this

area and then review related works.

2.1 General-purpose MPC Platforms

General-purpose MPC platforms usually provide a high-level pro-

gramming front-end with a compiler/interpreter to translate a high-

level code into a series of cryptographic building blocks [

]. They

provide common operators like

and

𝑥

in the front-end, and

implement these operations using MPC protocols. These platforms

guarantee privacy in the end-to-end algorithms based on the uni-

versal composability of the underlying security protocols. Example

platforms include MP-SPDZ [

], PrivPy [

], CrypTen [

], Se-

cureML [

], ABY [

], and CryptGPU [

] etc. They hugely lower

the barriers of developing privacy-preserving applications.

Most of the general-purpose MPC platforms use secret sharing

(SS) [

] as the underlying protocol. There are a range

of security assumptions (e.g., semi-honest vs. malicious) in these

protocols, resulting in signicantly diering performance. Some

platforms allow users to choose the underlying protocols, like [

Our goal is to make NFGen protocol-agnostic.

NFGen: Automatic Non-linear Function Evaluation Code Generator for General-purpose MPC Platforms CCS ’22, November 7–11, 2022, Los Angeles, CA, USA.

Secure Logistic

Regression

(require sigmoid)

‘Function desc’: {

𝐹: sigmoid

)) 𝑎, 𝑏 : [−10, 10],

2: )𝜀:10!",10!#

‘

System desc’:{

𝑛, 𝑓 :) 96,48

OPs: {+, >,×…}

}, NFD

FitPiecewise (𝑘, NFD):

Iterate 𝑘:

𝑎𝑏

𝑎 𝑏

𝑏𝑎 !"#

!"#

…

Try 𝑝̂!

Check ||"

Split if fail

Merge

𝒫

Construct

Code

Generator

@types.vectorize

def sigmoid(x):

breaks = [-1007.0, ...,10.0]

coeffA = [[0.0,... 0.0]]

scaler = [[1.0,... 1.0]]

m = len(coeffA),

k = len(coeffA[0])

…

comp = sfix.Array(m)

for iin range(m):

comp[i] = (x >= breaks[i])

…

return res

Select best plan

and generate:

Load

OPPE

templet Code

&:#62ms

𝑥:##150ms,

km-Profiler ,

…} PPD

𝒫

Figure 1: End-to-end Workow of NFGen

Secret sharing protocols require communications among the par-

ticipants on each operation, which results in signicantly slower

performance than plaintext (usually

10×−1000×

slower, depending

on the protocol and network environment). Also, dierent opera-

tors in the same protocol exhibit vast performance dierence. For

example, in the most common additive secret sharing protocol,

is almost as fast as plaintext as it is communication-free. However,

and

require communication and are slower. Non-linear opera-

tions like

𝑥

and

√𝑥

operate more slowly. It is important to make

fast as it is the most common operation in many applications.

To make

fast, MPC systems need to avoid oating point (FLP)

numbers because the ciphertext exponent in FLP prevents us from

adding up FLPs directly. Thus, almost all practical MPC platforms

use xed-point (FXP) numbers [

]. FXP repre-

sents each real number as an

𝑛

-bit integer, out of which

𝑓

least

signicant bits represent the fraction, and the most signicant bit is

the sign. We denote it as a

⟨𝑛,𝑓⟩

-FXP number. In the

⟨𝑛,𝑓⟩

format,

both the range and resolution of the FXP are xed to

2𝑛−𝑓−1

and

2−𝑓

, respectively. FXP oers a much smaller range and resolution

than FLP, and thus programmers need to be more careful with over-

ows and precision losses. MPC further complicates the problem

as we cannot detect overows on ciphertext. Also, the common

scaling method in plaintext FXP requires additional bit operations

in ciphertext and thus becomes expensive in MPC.

2.2 Non-linear Functions in MPC Platforms

Lacking of a complete general numeric computation library, MPC

application developers need to roll their application-specic solu-

tions even for common functions, like logistic regression (LR) [

decision trees [

], principal component analysis (PCA) [

]

and neural networks (NNs) [

]. Mohassel et al. [

] use

a 3-piece linear function to replace the slow sigmoid function in

LR and NNs. However, there is no guarantee that the approxima-

tion maintains accuracy in all cases. In fact, we nd cases with

signicant LR accuracy loss using this approximation.

The most straightforward method to evaluate non-linear func-

tions in MPC is directly adapting the plaintext code and replacing

basic operations to secure ones (e.g.,

and

). For example,

CrypTen [

] and CryptGPU [

] adopt a series of plaintext al-

gorithms like Newton-Raphson iterations,limit approximations to

implement

𝑥

𝑒𝑥

√𝑥

and

ln 𝑥

. Natively adopting plaintext code

usually leads to poor performance, as we do not know when we

have reached the desirable accuracy and need to iterate more.

There are also protocol-specic approaches. For example, Rathee

et al. [

] implement

ecient cryptographic building blocks to

support high-performance non-linear functions like reciprocal-of-

sqrt,sigmoid and exponent. However, these functions are optimized

for their 2-party-computation platform only. Similiarly, Damgård et

al. [

] propose a series of primitives to support ecient machine

learning applications for SPD

Z2𝑘

protocol [

]. More generally, Cat-

rina et al. [

] design a collection of general building-blocks suitable

for any xed-point MPC platform and propose an optimized

𝑥

prim-

itive using Goldschmidt algorithm on secret FXP. MP-SPDZ [

]

uses the same algorithm.

Another line of methods is to approximate non-linear functions

with polynomials. It is a well-studied problem in plaintext of nd-

ing an optimal polynomial approximating a given function

𝐹(𝑥)

minimizing the maximum dierence over a given input domain

[𝑎,𝑏]

. Such polynomial is referred to as minimax polynomial [

Chebyshev interpolation [

] is a well-known solution. It oers a

close approximation to the minimax polynomial (so-called Cheby-

shev (near) minimax polynomial) [

]. Hesamifard et al. [

]

adopt the Chebyshev polynomial to evaluate sigmoid on homo-

morphic encryption. However, the range of FXP limits the order

𝑘

of the polynomial and prevents it from reaching the desired ap-

proximation accuracy either. Another challenge is that the limited

resolution of FXP cannot capture sometimes-tiny coecients in

these polynomials. Previous work ignores this problem and leads

to large errors [

]. Boura et al. [

] propose to use Fourier series

to approximate sigmoid in MPC platform. They work around the

range and resolution issues using secure quadruple-precision FLP

but brings in expensive computation overhead.

Unlike previous eorts, we adopt piecewise polynomial and t

a Chebyshev polynomial for each piece, resulting in improved ac-

curacy. We take into account the dierences between FXP and

FLP and handle corner cases. Also, prior works focus on one or a

few functions on a single MPC platform, whereas our goal is to

build a general, cross-platform solution for all Lipschitz-continuous

functions2.

3 OVERVIEW

Notations and assumptions.

We rst describe the notations and

assumptions we use throughout the paper. We assume

𝐹(𝑥)

is a Lip-

schitz continuous function, and we can evaluate

𝐹(𝑥)

in plaintext

Even if the functions are Lipschitz continuous, there is no theoretical guarantee that

we will nd a feasible approximation for all functions on any accuracy requirements.

However, empirically, NFGen works well on all the functions we tested.

CCS ’22, November 7–11, 2022, Los Angeles, CA, USA. Xiaoyu Fan et al.

using FLP. NFGen approximates

𝐹(𝑥)

by nding a set of feasible

piecewise polynomials with dierent max order

𝑘

and the num-

ber of pieces

𝑚

. We denote the set of all feasible polynomials as

P={^

𝑝𝑚

𝑘}

. Each of the

𝑝𝑚

𝑘

contains

𝑚

pieces covering the entire

input domain of

[𝑎,𝑏]

[𝑤0,𝑤1,. . . ,𝑤𝑗,. . . ,𝑤𝑚]

(

𝑤0=𝑎

and

𝑤𝑚=𝑏

). In each piece

𝑗,(𝑖.𝑒., [𝑤𝑗−1,𝑤𝑗])

, we have a polynomial

𝑝(𝑗)

𝑘(^

𝑥)=Í𝑘

𝑖=0^

𝑐𝑖^

𝑥𝑖

to approximate it. When the piece index

𝑗

is not

important, we use a shorthand of

𝑝𝑘(𝑥)

to denote it. Throughout

the paper, symbols with a hat (

^·

) denote

⟨𝑛,𝑓⟩

-FXP representable

variables and the denition of functions like

𝑝𝑚

𝑘

means all the co-

ecients and terms are in

⟨𝑛,𝑓⟩

-FXP representation (Section 2.1).

We assume 64-bit double-precision FLP is equivalent to

. It is a

safe assumption in our situation, considering both the resolution

and range of FLP are orders of magnitudes larger than FXP of our

concern.

NFGen input les.

NFGen generates non-linear function approxi-

mation code for dierent MPC platforms according to two input

les. The rst is a user-provided non-linear function denition (NFD),

containing the expression of the target function

𝐹(𝑥)

, its domain

[𝑎,𝑏]

, FXP format

⟨𝑛,𝑓⟩

, target accuracy

𝜖

and

(in Eq. 1), and a

list of the operators supported by the target MPC platform. The

users can generate the second input le, performance prole deni-

tion (PPD), running a NFGen-provided proler on the target MPC

platform deployment. Note that NFD is MPC-platform-specic but

independent of the actual deployment (i.e., the CPU and network-

ing congurations), and PPD describes the deployment. Separating

them allows better portability across dierent deployments.

Workow.

Figure 1 illustrates NFGen workow. NFGen rst reads

in the NFD le, and on plaintext runs the algorithms in Section 4

to t the set of

with dierent

𝑘

and

𝑚

settings. Then using

the PPD le, NFGen chooses one

𝑝𝑚

𝑘∈^

with the

𝑘

and

𝑚

that

maximizes performance on the specic deployment (Section 6.1).

Finally, NFGen outputs the generated code that runs just like any

user-dened function on the target MPC system, using a set of

pre-dened, platform-dependent code templates.

Requirements for a feasible ^

𝑝𝑚

𝑘.

Given an MPC platform with

⟨𝑛,𝑓⟩

-FXP, the target function

𝐹(𝑥)

on input domain

[𝑎,𝑏]

, a fea-

sible ^

𝑝𝑚

𝑘needs to meet the following three conditions.

1) The evaluation of

𝑝𝑚

𝑘

should only consist of provided operators

in the target MPC platform. This requirement is usually true as all

we need are basic operators of +,×and >.

2) All the intermediate results in

𝑝𝑚

𝑘

, including polynomial coef-

cients

𝑐𝑖

and

𝑥𝑖

terms, etc., should be representable in

⟨𝑛,𝑓⟩

-FXP

without overow or underow.

3) For all

𝑥

in the range [

𝑎

𝑏

], the

𝑝𝑚

𝑘

should approximate

𝐹(𝑥)

with high accuracy, so we need to bound the max error of the approx-

imation rather than the mean error. We measure the approximation

error using the soft relative distance (SRD),

|𝑥−𝑦|𝑑=(|𝑥−𝑦|/|𝑥|,|𝑥|>^

|𝑥−𝑦|,|𝑥| ≤ ^

0,^

0<𝜖,(1)

and require

max

𝑥∈[𝑎,𝑏]|𝐹(^

𝑥) − ^

𝑝𝑚

𝑘(^

𝑥)|𝑑≤𝜖.(2)

Algorithm 1: FitPiecewise Algorithm

Global cong :

FXP format

⟨𝑛,𝑓⟩

, max sampling numbers

𝑀𝑆

and

max pieces 𝑚𝑚𝑎𝑥

Global state : The tted piecewise polynomial ^

𝑝𝑚

𝑘

Input : Target function 𝐹(𝑥), input domain [𝑎,𝑏]and

order 𝑘

1Initialize piece counter 𝑚𝑐←0;

2if ^

𝑝𝑘←FitOnePiece(𝐹,[𝑎,𝑏],𝑘)is NOT Null then

3Add ^

𝑝𝑘to global state ^

𝑝𝑚

𝑘;

4end

5else

6FitPiecewise(𝐹,[𝑎,𝑎+𝑏

2],𝑘) ;

7FitPiecewise(𝐹,[𝑎+𝑏

2,𝑏],𝑘) ;

8𝑚𝑐+=1;

9If 𝑚𝑐>𝑚𝑚𝑎𝑥 :Exit;

10 end

11 𝑖←0;

12 while 𝑖not reach the tail of ^

𝑝𝑚

𝑘do

13 𝑎,𝑏←𝑤𝑖,𝑤𝑖+2in ^

𝑝𝑚

𝑘;

14 if ^

𝑝𝑘←FitOnePiece(𝐹,[𝑎,𝑏],𝑘)is NOT Null then

15 Replace ^

𝑝(𝑖)

𝑘and ^

𝑝(𝑖+1)

𝑘with single ^

𝑝𝑘;

16 else

17 𝑖+=1;

18 end

19 end

20 Exit

The

is the soft zero. We use soft zeros because the relative

error can be very large when

|𝑥| → 0

. For example, for

𝑥=2−50

(in FLP), a good representable approximation in a

⟨96, 48⟩

-FXP,

𝑥=2−48

gives a large relative error of

22−1>𝜖

. To avoid ruling

out these good-performance approximations, we switch to bound

the absolute error instead when

|𝑥| ≤ ^

. By default, we set

𝜖=10−3

and

0=10−6

. We further relax the accuracy denition to maximum

sample SRD rather than the true maximum SRD by computing the

max error over a sample set of

𝑥∈ [𝑎,𝑏]

for practical performance.

Indeed, we prove that for any Lipschitz continuous function

𝐹(𝑥)

the true maximum SRD can be bounded by the sampled version,

for details, see Appendix A.1. Empirically, we nd that a modest

sample set (e.g. 1000 per piece) is frequently sucient (Section 7.3).

4 NON-LINEAR APPROXIMATION

The core of NFGen is to t a set of piecewise polynomials

that

estimate the function

𝐹(𝑥)

in plaintext. All

𝑝𝑚

𝑘∈^

can be evaluated

obliviously in ciphertext. We rst introduce the overall algorithm

that recursively nds a good

𝑚

for a given

𝑘

if possible. Then we

focus on the algorithm that ts a

𝑝𝑘

for a single piece, which is the

most challenging part due to FXP limitations. Finally, we introduce

the oblivious evaluation algorithm.

4.1 Fitting Piecewise Polynomials

The cost for evaluating

𝑝𝑚

𝑘

is mostly for computing 1) the

𝑘

-th

order polynomial and 2) deciding which of the

𝑚

pieces that input

𝑥

belongs to. Each

𝑝𝑚

𝑘

has

(𝑚×𝑘)

parameters. We want to deter-

mine

𝑚

and

𝑘

automatically. As dierent MPC platforms may have

文档加载中……请稍候！
如果长时间未打开，您也可以点击刷新试试。

下载文档到电脑，查找使用更方便

10 玖币 0人已下载

立即下载

摘要：

NFGen:AutomaticNon-linearFunctionEvaluationCodeGeneratorforGeneral-purposeMPCPlatformsXiaoyuFanfanxy20@mails.tsinghua.edu.cnIIIS,TsinghuaUniversityKunChenchenkun@tsingj.comTsingjiaoInformationTechnologyCo.Ltd.GuosaiWangguosai.wang@tsingj.comTsingjiaoInformationTechnologyCo.Ltd.MingchunZhuangmczhuang...

展开>> 收起<<

NFGen Automatic Non-linear Function Evaluation Code Generator for General-purpose MPC Platforms.pdf

共20页,预览4页

还剩页未读，继续阅读

声明：本站为文档C2C交易模式，即用户上传的文档直接被用户下载，本站只是中间服务平台，本站所有文档下载所得的收益归上传人(含作者)所有。玖贝云文库仅提供信息存储空间，仅对用户上传内容的表现方式做保护处理，对上载内容本身不做任何修改或编辑。若文档所含内容侵犯了您的版权或隐私，请立即通知玖贝云文库，我们立即给予删除！

NFGen Automatic Non-linear Function Evaluation Code Generator for General-purpose MPC Platforms

相关推荐

开通VIP享超值会员特权

作者详情

相关内容

热门标签

举报选择: