PaperlayerView exact revision on arXiv

Source-linked AI summary

BLAZE: Blazing Fast Privacy-Preserving Machine Learning

Arpita Patra, Ajith Suresh

arXiv:2005.09042v1cs.CRcs.LG

TL;DR

Privacy-preserving machine learning is computationally and communication-intensive, motivating secure outsourcing without exposing sensitive data. BLAZE provides a three-server PPML framework for Linear Regression, Logistic Regression, and Neural Networks, outperforming state-of-the-art solutions by several orders of magnitude in round and communication complexity.

  • Problem

    PPML adds computational and communication demands to already intensive ML algorithms, challenging end-users with limited infrastructure while preserving data privacy during outsourcing.

  • Method

    BLAZE uses secret-shared computation over Z2^ℓ with three servers tolerating one malicious corruption, supported by preprocessing and efficient PPML primitives.

  • Results

    BLAZE outperforms state-of-the-art solutions by several orders of magnitude in both round and communication complexity across Linear Regression, Logistic Regression, and Neural Networks.

  • Takeaways & Limitations

    BLAZE demonstrates fast PPML outsourcing for three-server deployments across the evaluated regression and neural-network applications.

Abstract

from arXiv · show

Machine learning tools have illustrated their potential in many significant sectors such as healthcare and finance, to aide in deriving useful inferences. The sensitive and confidential nature of the data, in such sectors, raise natural concerns for the privacy of data. This motivated the area of Privacy-preserving Machine Learning (PPML) where privacy of the data is guaranteed. Typically, ML techniques require large computing power, which leads clients with limited infrastructure to rely on the method of Secure Outsourced Computation (SOC). In SOC setting, the computation is outsourced to a set of specialized and powerful cloud servers and the service is availed on a pay-per-use basis. In this work, we explore PPML techniques in the SOC setting for widely used ML algorithms-- Linear Regression, Logistic Regression, and Neural Networks. We propose BLAZE, a blazing fast PPML framework in the three server setting tolerating one malicious corruption over a ring (\Z{\ell}). BLAZE achieves the stronger security guarantee of fairness (all honest servers get the output whenever the corrupt server obtains the same). Leveraging an input-independent preprocessing phase, BLAZE has a fast input-dependent online phase relying on efficient PPML primitives such as: (i) A dot product protocol for which the communication in the online phase is independent of the vector size, the first of its kind in the three server setting; (ii) A method for truncation that shuns evaluating expensive circuit for Ripple Carry Adders (RCA) and achieves a constant round complexity. This improves over the truncation method of ABY3 (Mohassel et al., CCS 2018) that uses RCA and consumes a round complexity that is of the order of the depth of RCA. An extensive benchmarking of BLAZE for the aforementioned ML algorithms over a 64-bit ring in both WAN and LAN settings shows massive improvements over ABY3.

I. INTRODUCTION … – Multiplication:

BLAZE addresses the computational and communication burdens of privacy-preserving machine learning in secure outsourced computation by building efficient three-server protocols over rings. Its constructions support major learning algorithms and improve performance through specialized primitives, preprocessing, and benchmarking.

  • I. INTRODUCTION: Privacy requirements make already compute-intensive ML algorithms more demanding, while many end-users lack infrastructure to execute them efficiently.These challenges motivate secure outsourced computation, where computation is delegated to specialized servers.
  • B. Our Contribution: BLAZE separates expensive input-independent preprocessing from a faster input-dependent online phase, and benchmarks its protocols against ABY3 and ASTRA.This two-phase design is used broadly to improve practical MPC efficiency.
  • A. Related Work: Prior PPML systems addressed several common algorithms but remained impractical because of high overheads; SecureML and later honest-majority systems improved performance.ASTRA provides primitives for Linear Regression and Logistic Regression inference, but not the additional tools needed for training or NN prediction.
  • B. Our Contribution: BLAZE targets PPML in a three-server SOC setting with at most one malicious corruption, using secret sharing over the ring Z_2^ℓ.The framework introduces new three-server sharing semantics tolerating one malicious corruption.
  • B. Our Contribution: BLAZE realizes privacy-preserving Linear Regression, Logistic Regression, and Neural Networks using layered primitives including dot product, truncation, and bit-to-arithmetic conversion.It supports training and inference for Linear Regression and Logistic Regression, and inference for Neural Networks.
  • B. Our Contribution: 194× and 15× improvements over ASTRA are reported for Linear Regression and Logistic Regression inference, respectively, over WAN.The corresponding LAN improvements are 1800× and 16×; ASTRA does not consider training or NN inference.
  • B. Our Contribution: BLAZE’s dot product protocol makes online communication independent of vector size, providing the first such result in the three-party honest-majority malicious setting.This primitive is important because dot products underlie many ML algorithms and can be viewed as repeated multiplications.
  • – Multiplication:: BLAZE’s multiplication protocol tolerates one malicious corruption and requires an amortized communication of 3 ring elements in both preprocessing and online phases.It uses the multiplication protocol of with distributed zero knowledge during preprocessing to enable an efficient input-dependent phase.

II. PRELIMINARIES AND DEFINITIONS · III. BUILDING LAYER-I PRIMITIVES · A. Secret Sharing Semantics

The framework operates with three servers under a one-corruption Byzantine adversary, using phased outsourced computation and shared-circuit evaluation. Its Layer-I foundation defines three secret-sharing schemes over arithmetic and Boolean rings, with linear operations available locally.

  • II. PRELIMINARIES AND DEFINITIONS: Three servers communicate over pair-wise private, authentic channels in a synchronous network while tolerating a static Byzantine adversary corrupting at most one server.Data owners secret-share training data, while a model owner and client secret-share the model and query for inference.
  • II. PRELIMINARIES AND DEFINITIONS: ML algorithms are represented as public-topology circuits using Layer-II Dot Product, Truncation, Sigmoid, and ReLU gates built from Layer-I primitives.The Layer-I primitives are Multiplication, Bit Extraction, and Bit2A.
  • II. PRELIMINARIES AND DEFINITIONS: Protocols separate input-independent preprocessing from input-dependent online computation, enabling parallel preprocessing across multiple outsourced instances.Some protocols may have an empty preprocessing phase.
  • II. PRELIMINARIES AND DEFINITIONS: A one-time shared-key setup establishes pre-shared PRF randomness, and security proofs are conducted in the corresponding Fsetup-hybrid model.Collision-resistant hashing reduces communication, while commitments strengthen security from abort to fairness.
  • III. BUILDING LAYER-I PRIMITIVES: The Layer-I primitives execute computations on shared values to provide privacy-preserving computation.This section introduces the sharing semantics underlying all primitives.
  • A. Secret Sharing Semantics: [·]-sharing splits v ∈ Z2^ℓ between P1 and P2 as additive shares satisfying v = [v]1 + [v]2.The two shares are held respectively by P1 and P2.
  • A. Secret Sharing Semantics: ⟨·⟩-sharing and J·K-sharing distribute masked values and auxiliary information across P0, P1, and P2, with J·K-sharing additionally incorporating correlated values.The specified shares use masks such as αv and βv, with βv = v + αv and αv = [αv]1 + [αv]2.
  • A. Secret Sharing Semantics: The schemes support arithmetic sharing over Z2^ℓ and Boolean sharing over Z2^1, and their linearity enables local addition and multiplication by public constants.Linearity extends across [·]-, ⟨·⟩-, and J·K-sharing.

B. Secret Sharing and Reconstruction protocols · C. Layer-I Primitives

The paper defines authenticated sharing, joint sharing, reconstruction, and fair reconstruction protocols for three-server outsourced computation, then builds Layer-I multiplication, bit extraction, and Bit2A primitives over Z2^ℓ. Its multiplication protocol addresses malicious inconsistencies through preprocessing checks, while bit extraction supports both PPA- and garbled-circuit-based approaches.

  • B. Secret Sharing and Reconstruction protocols: Πsh lets a server generate J·K-sharing of v ∈ Z2^ℓ using preprocessing randomness and online hash checks before completing the shares.The online phase verifies βv consistency and aborts on mismatched values.
  • B. Secret Sharing and Reconstruction protocols: Πjsh enables two servers that know v to jointly generate its J·K-sharing, with one server executing Πsh and the other verifying correctness.When v is available during preprocessing, the protocol can be non-interactive and tolerates one active corruption.
  • B. Secret Sharing and Reconstruction protocols: Πrec reconstructs a secret by having each server receive a missing share and a hash from different servers, proceeding only when consistency checks pass.For party-directed reconstruction, servers send shares and corresponding hashes directly to the data owner or client.
  • B. Secret Sharing and Reconstruction protocols: Fair reconstruction prevents a corrupt server from learning the output while causing honest parties to abort, using an adaptation of ASTRA’s techniques.The fairness goal is motivated by outsourced machine-learning services offered against payment.
  • C. Layer-I Primitives: Πmult computes J·K-sharing of z = xy, using preprocessing-generated masks and shares so the online phase reconstructs βz and completes the product sharing.Correctness follows from βz = xy + αz and the relation βz − αz = xy.
  • C. Layer-I Primitives: Malicious security addresses three multiplication failures: incorrect Γxy-sharing by corrupt P0, incorrect βz-shares from P1 or P2, and incorrect βz + γz sent to P0.A hash check handles the third issue, while a single check based on asymmetric server roles addresses the first two.
  • C. Layer-I Primitives: The multiplication protocol computes a multiplication triple during preprocessing with ΠmulZK, binding Γxy, ψ, and χ to correct values before online computation.The same verification reduces χ correctness to checking whether (d, e, f) is a multiplication triple and detects errors in Γxy-sharing.
  • C. Layer-I Primitives: Πbitext extracts the most significant bit from arithmetic sharing using either ABY3’s PPA with 2ℓ AND gates and multiplicative depth log(ℓ), or a constant-round garbled circuit; Πbit2A converts bit sharing to arithmetic sharing.Bit2A uses the identity (b)A = (βb)A + (αb)A − 2(βb)A(αb)A and computes the required products from shared values.

IV. BUILDING LAYER-II PRIMITIVES

BLAZE builds fixed-point MPC primitives over a 64-bit ring, including communication-efficient dot products and constant-round truncation. It combines these mechanisms with secure comparison and MPC-friendly activation protocols for PPML computations.

  • Fixed-Point Representation: BLAZE represents decimal values in signed two’s-complement form over Z2^64, using d = 13 fractional bits and 50 integer bits.The most significant bit stores the sign, while the final 13 bits store the fractional part.
  • Dot Product: Protocol Πdotp generates a shared dot product from shared vectors without online communication that depends on vector size.It avoids treating the dot product as n separate multiplication instances whose results are then locally added.
  • Truncation: Protocol Πtrgen generates a random truncation pair during preprocessing, enabling truncation without reconstructing the secret value.The servers verify the sharing by checking that a computed ring element equals zero, with hash-based communication optimization.
  • Dot Product with Truncation: Protocol Πdotpt produces a shared truncated dot product without inflating online cost, unlike ABY3, which requires an additional online reconstruction.It runs Πtrgen during preprocessing and combines the truncated masked value with the shared truncated mask.
  • Secure Comparison and Activation Functions: Secure comparison extracts the most significant bit of the shared difference x − y, while ReLU and Sigmoid use this comparison machinery with Bit2A and multiplication protocols.ReLU computes max(0, v), and the MPC-friendly Sigmoid uses the piecewise expression sig(v) = b1b2(v + 1/2) + b2.

V. BUILDING PPML AND BENCHMARKING

This section benchmarks BLAZE against ABY3 and ASTRA for linear regression, logistic regression, and neural-network inference, using throughput over 64-bit-ring LAN and WAN environments. It also specifies the implementation, fairness reconstruction, and experimental methodology.

  • Benchmark Scope: BLAZE is benchmarked on linear regression and logistic regression training and inference, plus neural-network inference; neural-network training is excluded because it requires garbled-circuit conversions.The benchmark compares these algorithms with their closest competitors.
  • Fairness: Fairness is obtained by reconstructing the final outcome through the fair reconstruction protocol Πfrec(P, JvK).This reconstruction is used to ensure the stated fairness property of the protocols.
  • Benchmarking Environment: The experiments use a 64-bit ring (Z264), with 1Gbps LAN and 75Mbps WAN bandwidth.LAN machines use 3.6 GHz Intel Core i7-7700 processors and 32 GB of RAM; WAN machines are geographically distributed Google Cloud instances.
  • Software Details: The protocols are implemented in C++17 using ENCRYPTO, while ABY3 and ASTRA are reimplemented because their code was unavailable.SHA-256, multithreading up to 32 threads, and averages over 20 runs are used.
  • Benchmarking Parameter: Throughput (TP) measures operations per minute, counting training iterations or inference queries, to capture communication and round-complexity effects.Minute is used as the unit because most WAN protocols require more than a second to complete.
  • Benchmarking Results: WAN benchmarking is presented in this section, while LAN benchmarking is deferred to Appendix E.The section therefore emphasizes WAN results in its main presentation.

A. Dot Product

BLAZE substantially improves dot-product throughput over ABY3 in both preprocessing and online phases. Its online advantage reaches 64×–580× at 50 Mbps, while preprocessing gains remain consistent across bandwidths.

  • A. Dot Product: At least 4× preprocessing throughput gain over ABY3 results from a 4× communication improvement for vectors of length 100–1000.Throughput is measured in #dotp/min separately for preprocessing and online phases.
  • A. Dot Product: 25 Mbps gives BLAZE better preprocessing throughput than ABY3 achieves at 75 Mbps.
  • A. Dot Product: 64× to 580× online throughput gain over ABY3 occurs at 50 Mbps because BLAZE’s communication is independent of vector size.
  • A. Dot Product: Increasing bandwidth reduces the online throughput gain because processors cannot handle the maximum attainable throughput even at 25 Mbps.
  • A. Dot Product: Preprocessing throughput gain does not drop as bandwidth increases because maximum attainable throughput remains within the machines’ processing capacity.

B. ML Training

This section evaluates Linear and Logistic Regression training, defining an iteration as forward propagation followed by backward propagation. BLAZE improves throughput over ABY3, with gains driven by efficient dot products but reduced by Logistic Regression’s sigmoid overhead.

  • Training procedure: Each training iteration consists of forward propagation followed by backward propagation, where model parameters are adjusted using the prediction error.The benchmark defines one iteration as one forward propagation followed by a backward propagation phase.
  • Linear Regression: Linear Regression updates the weight vector with gradient descent over randomly selected batches, using dot products for the required matrix multiplications.Subtraction and multiplication by a public constant can be performed locally on shared values.
  • Linear Regression: 4× preprocessing gain and 9.2× to 83.4× online gain are achieved over ABY3 for Linear Regression with batch size 128.The gains are attributed to BLAZE’s efficient dot product protocol.
  • Logistic Regression: Logistic Regression carries over Linear Regression’s improvements, but sigmoid activation overhead reduces throughput in both preprocessing and online phases.The sigmoid is applied to Xi ◦ w during forward propagation.
  • Varying bandwidths: At 75Mbps, online throughput gains range from 6.18× to 55.62× for Linear Regression and from 2.78× to 22.95× for Logistic Regression over ABY3.For Logistic Regression at 25Mbps, the gain ranges from 6.11 to 51.21.

C. ML Inference … VI. CONCLUSION

BLAZE delivers high-throughput private inference for linear regression, logistic regression, and neural networks, outperforming ABY3 and ASTRA under the reported settings. The framework operates with three servers tolerating one malicious corruption, while training neural networks remains open.

  • C. ML Inference: BLAZE benchmarks inference throughput for Linear Regression, Logistic Regression, and Neural Networks using queries processed per minute.The online phase is benchmarked directly, while preprocessing details are deferred to Appendix D-B.
  • C. ML Inference: 14× to 216× gain in online throughput over ABY3 is reported for Linear Regression, compared with 3× to 27× for Logistic Regression.These gains span different bandwidths.
  • C. ML Inference: BLAZE’s neural-network throughput gain over ABY3 does not decline as bandwidth increases, unlike the Linear Regression and Logistic Regression trend.The passage attributes this to the large communication incurred by neural networks and limited processing capacity.
  • 1) ML Inference on Real World Datasets:: On UCI real-world datasets, BLAZE’s Linear Regression throughput does not increase with bandwidth because processing capacity becomes the bottleneck.The passage notes that adding computing power could prevent this limitation.
  • 2) Comparison with ASTRA:: Against ASTRA, BLAZE’s online-throughput gain for both Linear Regression and Logistic Regression decreases with bandwidth because limited processing capacity constrains BLAZE.ASTRA’s throughput increases with bandwidth; at 3Mbps, the comparison is further examined.
  • VI. CONCLUSION: BLAZE is a three-server PPML framework tolerating one malicious corruption over the ring Z2^ℓ, with applications to three inference algorithms.Its constructs outperform state-of-the-art solutions by several orders of magnitude in round and communication complexity.
  • VI. CONCLUSION: Extending BLAZE to neural-network training and exploring Trusted Execution Environments for improved efficiency remain open directions.These are identified as future work in the conclusion.

APPENDIX A PRELIMINARIES · APPENDIX B MULTIPLICATION PROTOCOL OF [17]

The appendices define shared-key, hashing, and commitment preliminaries, then detail ’s multiplication protocol, its verification checks, and its communication complexity. The protocol verifies multiplication through polynomial identities and achieves 4 rounds with amortized communication of 3ℓ bits.

  • APPENDIX A PRELIMINARIES: Shared-key setup establishes pairwise keys k01, k02, k12 and one key kP shared among all three servers.Pairwise PRF invocations non-interactively sample random values in Z2^ℓ using locally updated counters.
  • APPENDIX A PRELIMINARIES: Collision resistance requires that probabilistic polynomial-time adversaries find distinct inputs hashing to the same value only with negligible probability.The hash family maps keys and inputs to outputs, with inputs of length m = poly(κ).
  • APPENDIX A PRELIMINARIES: Commitments provide hiding of the committed value and binding against opening it to a different value.The scheme can be instantiated using a hash function whose security is proved in the random-oracle model.
  • APPENDIX B MULTIPLICATION PROTOCOL OF [17]: The ⟨·⟩-shared multiplication protocol takes shares of d and e and produces shares of f = de.Its sharing represents each value using masked components distributed across P0, P1, and P2.
  • APPENDIX B MULTIPLICATION PROTOCOL OF [17]: Verifiers test the polynomial relation at a jointly sampled r and separately check that h(M) = 0.They construct query vectors, compute additive shares of evaluations, reconstruct f(r), and abort when the h(M) equality fails.
  • APPENDIX B MULTIPLICATION PROTOCOL OF [17]: The prover encodes multiplication-gate wires into polynomials f, g, and h, with h representing output-wire values and degree at most 2M.Random constants z1 and z2 initialize f and g, while h uses z1z2; the proof contains the witness and coefficients of h.
  • APPENDIX B MULTIPLICATION PROTOCOL OF [17]: [17] gives a 2-round fully linear interactive oracle proof with query complexity O(√n), which this work uses.A second variant instead has O(log(M)) rounds and O(log(M)) query complexity; additionally, ΠmulZK requires 4 rounds and amortized communication of 3ℓ bits.

APPENDIX C BUILDING BLOCKS … 4) Fair Reconstruction Protocol:

Appendix C presents sharing, joint sharing, reconstruction, and fair reconstruction protocols with non-interactive preprocessing, low-round online execution, and amortized communication over ring elements. The fair reconstruction protocol uses commitments and consistency checks to ensure honest servers obtain the output whenever the corrupt server does.

  • 1) Sharing Protocol:: Πsh uses non-interactive preprocessing, then completes online sharing in 1 round with amortized communication of 2ℓ bits.Servers generate α and γ shares during preprocessing; online communication is amortized across multiple instances.
  • 2) Joint Sharing Protocol:: Πjsh also has non-interactive preprocessing and requires 1 online round with at most 2ℓ bits of amortized communication.One server runs Πsh while another sends hash information in parallel, with costs amortized over multiple instances.
  • 3) Reconstruction Protocol:: Πrec reconstructs a value in 1 round using amortized communication of 3ℓ bits during the online phase.Each server receives its missing share and a verification hash; hashes for multiple instances can be combined.
  • 3) Reconstruction Protocol:: Πfrec guarantees fair reconstruction: honest servers obtain secret v whenever the corrupt server obtains the same secret.The protocol adapts ASTRA’s fairness techniques to the paper’s sharing scheme.
  • 4) Fair Reconstruction Protocol:: Fair reconstruction commits common shares before opening them, with recipients aborting on inconsistent commitments and P0 signaling continuation when checks pass.Preprocessing commits [αv]1 and [αv]2 to the other servers; online, P1 and P2 commit βv to P0 before the missing shares are opened.
  • 4) Fair Reconstruction Protocol:: In outsourced reconstruction, servers omit online commitment openings, send commitments toward the output recipient, and use honest-majority majority values.The supplied passage describes this as the outsourced variant of Fig. 21’s fair reconstruction procedure.
  • 4) Fair Reconstruction Protocol:: Πfrec requires 4 online rounds and amortized communication of 6ℓ bits.The rounds cover commitment exchange, abort-or-continue signaling, message exchange, and missing-share exchange; the first three rounds’ communication is amortized across instances.

1) Multiplication Protocol: … 3) Dot Product with Truncation:

The paper specifies communication-efficient protocols for multiplication, bit extraction, Bit2A conversion, dot products, truncation, and dot products with truncation. Their costs are characterized by preprocessing and online rounds and amortized communication over the ring.

  • 1) Multiplication Protocol:: Πmult requires 4 preprocessing rounds with amortized communication of 3ℓ bits, followed by 1 online round with 3ℓ bits.The online exchange combines share transmission and hash communication across multiple instances.
  • 2) Bit Extraction protocol:: Πbitext requires 5 preprocessing rounds with amortized communication of 5ℓκ + κ bits and 2 online rounds with ℓκ + 2 bits.Here κ is the computational security parameter; the online phase communicates an input key, a resultant bit, and one additional bit.
  • C. Layer-II Primitives: The Layer-II primitive constructions use non-interactive shared-randomness preprocessing where specified, with communication deferred to before output reconstruction when noted.The supplied protocol descriptions state these properties for bit extraction, Bit2A conversion, and truncation-related steps.
  • 3) Bit2A Conversion protocol:: Πbit2A requires 5 preprocessing rounds with amortized communication of 9ℓ bits and 1 online round with 4ℓ bits.Its preprocessing combines two Πjsh instances with multiplication-related preprocessing, while the online phase combines Πjsh and multiplication communication.
  • 1) Dot Product Protocol:: Πdotp requires 4 preprocessing rounds with amortized communication of 3nℓ bits and 1 online round with 3ℓ bits, independent of vector size n online.The preprocessing runs n multiplication instances in parallel, while the online phase combines their shares before exchange.
  • 2) Truncation:: Πtrgen requires 2 rounds and amortized communication of 2nℓ bits.Servers sample additive shares of r non-interactively, then execute sharing and amortized hash communication.
  • 3) Dot Product with Truncation:: Πdotpt requires 4 preprocessing rounds with amortized communication of 3nℓ + 2ℓ bits and 1 online round with 3ℓ bits.Preprocessing combines n multiplication instances with one Πtrgen instance; online communication handles z − r and truncated arithmetic sharing.

4) Activation Functions: … B. ML Training

The paper benchmarks BLAZE against ABY3 across activation protocols, WAN/LAN microbenchmarks, and ML training and inference. BLAZE shows substantial throughput gains, especially in online dot products and LAN training.

  • 4) Activation Functions:: ReLU requires 5 preprocessing rounds and 3 online rounds, with amortized communication of 12ℓ+9p bits and 7ℓ+3p+1 bits, respectively.Here p = ℓ+25.
  • A. ML Training: WAN benchmarking reports BLAZE and ABY3 performance for Linear Regression and Logistic Regression training across batch sizes 128, 256, 512 and feature sizes 100, 500, 900.Preprocessing and online results are measured as iterations completed per minute, where higher is better.
  • B. ML Inference: Inference preprocessing benchmarks cover Linear Regression, Logistic Regression, and Neural Networks using dedicated figures for each algorithm.The figures compare BLAZE and ABY3 preprocessing throughput.
  • B. ML Inference: ≈4× preprocessing throughput gain is observed over ABY3 for all three inference algorithms.This result summarizes the preprocessing comparisons for Linear Regression, Logistic Regression, and Neural Networks.
  • APPENDIX E MICRO BENCHMARKING OVER LAN: LAN benchmarking covers BLAZE and ABY3 performance, including dot products and Linear Regression and Logistic Regression training.Training comparisons vary feature sizes from 100 to 1000 and batch sizes 128, 256, 512.
  • A. Dot Product: At least 4× preprocessing gain over ABY3 is reported for dot products, attributed to a 4× communication improvement.The preprocessing evaluation uses vector lengths from 100 to 1000.
  • A. Dot Product: 363× to 3272× online throughput gain over ABY3 is reported for dot products across varying feature sizes in LAN settings.The larger LAN advantage arises because communication time scales with communication size, unlike WAN behavior across wide communication-size ranges.

C. ML Inference · APPENDIX F SECURITY OF OUR CONSTRUCTIONS · A. Sharing Protocol

BLAZE’s inference benchmarks report large online-phase gains over ABY3 for Linear Regression, Logistic Regression, and Neural Networks. Its security analysis uses real/ideal-world simulation in the {Fsetup, FmulZK}-hybrid model, including explicit sharing-protocol functionalities and simulators.

  • C. ML Inference: Inference benchmarking measures the number of queries processed per minute for Linear Regression, Logistic Regression, and Neural Networks.The corresponding results appear in Fig. 28, Fig. 29, and Fig. 30, respectively.
  • C. ML Inference: 400× to 3600×: BLAZE’s Linear Regression inference online phase gains over ABY3.The reported gain range is for the online phase of Linear Regression inference.
  • C. ML Inference: 3.16× to 27.04×: BLAZE’s Logistic Regression inference online phase gains over ABY3.The gain range is reported for Logistic Regression inference.
  • C. ML Inference: 65× to 276×: BLAZE’s Neural Network inference online phase gains over ABY3.Table XV provides concrete inference details for feature size 784.
  • APPENDIX F SECURITY OF OUR CONSTRUCTIONS: Security proofs follow the standard real/ideal-world paradigm in the {Fsetup, FmulZK}-hybrid model.Fsetup and FmulZK represent the ideal-world shared key-setup and ΠmulZK functionalities.
  • APPENDIX F SECURITY OF OUR CONSTRUCTIONS: The simulator sets honest inputs to 0, extracts the corrupt adversary’s input, and thereby derives the circuit’s intermediate values and output.These values support simulation of each circuit component.
  • A. Sharing Protocol: The sharing functionality receives v from one server and ⊥ from the others, returning ⊥ to every server when v = ⊥.Otherwise, the functionality proceeds with the computation.
  • A. Sharing Protocol: For corrupt P0 and P1, sharing simulators emulate Fsetup, provide keys to the adversary, and generate γv using the designated key or a random value.For corrupt P0, mismatched received values set flag = 1; for noncorrupt-input cases, the simulator sets v = 0 by assigning βv = αv.

B. Joint Sharing Protocol · C. Reconstruction Protocol

The joint sharing and reconstruction sections specify ideal functionalities and simulator behavior for protocols Πjsh and Πrec, including share generation, adversarial outputs, and corruption-case emulation. They also describe simulator actions for multiplication-related shares and keys.

  • B. Joint Sharing Protocol: Πjsh receives v from two servers, rejects mismatched inputs with ⊥, and otherwise generates randomized output shares over Z2ℓ.The shares use random [αv]1, [αv]2, and γv, with βv = v + [αv]1 + [αv]2.
  • B. Joint Sharing Protocol: Πjsh sends the corrupt server its corresponding share unless it aborts, in which case all servers receive (Output, ⊥).The adversary receives (Output, JvKS) when it does not send abort.
  • B. Joint Sharing Protocol: The joint-sharing functionality can selectively suppress outputs to honest servers chosen by the adversary, while sending the corresponding share to others.An honest server Pi in the selected subset receives (Output, ⊥); otherwise it receives (Output, JvKi).
  • B. Joint Sharing Protocol: For corrupt P0, Sjsh emulates Fsetup, gives A keys k01, k02, and kP, learns α-values for v, and samples γv for P1 and P2.This simulator is identified as the simulator for the corrupt P0 case.
  • B. Joint Sharing Protocol: For corrupt P1, Sjsh emulates Fsetup, gives A keys k01, k12, and kP, learns α-values for v, and computes γv with k12.This simulator is identified as the simulator for the corrupt P1 case.
  • C. Reconstruction Protocol: Πrec is defined through an ideal functionality with simulators covering corruption of P0 and P1.The section presents the Πrec functionality, a corrupt-P0 simulator, and the corrupt-P1 simulator.
  • C. Reconstruction Protocol: For corrupt P1, Srec sends [αv]2 and H([αv]2) on behalf of P2 and P0, receives v on their behalf, and sets a flag based on a hash check.The supplied reconstruction description states that flag = 1 if either H([α′... condition is met.
  • C. Reconstruction Protocol: The multiplication simulators compute [αz]1 and γz with keys k01 and k12, sample [αz]2, and prepare d,e shares honestly.The supplied figures identify simulators for corrupt P0 and P1.

E. Bit Extraction Protocol … H. Truncation Protocol

Sections E–H specify ideal functionalities and simulator constructions for bit extraction, Bit2A conversion, dot products, and truncation. The protocols define server inputs, adversarial abort behavior, preprocessing simulations, and randomized truncation values over Z_{2^ℓ}.

  • E. Bit Extraction Protocol: Bit extraction is defined through an ideal functionality Πbitext that receives a J·K-share of v from the servers.The functionality proceeds unless the adversary supplies ⊥, in which case every server receives ⊥.
  • E. Bit Extraction Protocol: The bit-extraction security proof provides simulator descriptions for corrupt P0 and corrupt P1.The corrupt-P1 simulator is presented separately from the corrupt-P0 case.
  • F. Bit2A Protocol: Bit2A is specified by an ideal functionality Πbit2A that accepts a J·K_B-share of bit b from the servers.It sends ⊥ to every server if the adversary provides ⊥; otherwise, it continues computation.
  • F. Bit2A Protocol: The Bit2A simulation handles Πjsh and Πmult analogously to the simulators Sjsh and Smult for corrupt P1.The corresponding simulator figures cover corrupt P0 and corrupt P1.
  • G. Dot Product Protocol: The dot-product protocol Πdotp is realized through an ideal functionality, with preprocessing corresponding to each of the n multiplications.For corrupt P1, its preprocessing simulation follows the preprocessing simulation of Πmult.
  • G. Dot Product Protocol: Dot-product security includes simulator figures for corrupt P0 and corrupt P1.The functionality is captioned as Fig. 49, while the simulator constructions appear in Figs. 50 and 51.
  • H. Truncation Protocol: The truncation protocol uses an ideal functionality Πtrgen that interacts with the servers and adversary.The construction randomly selects r ∈ Z_{2^ℓ}, sets r_d = r/2^d, samples [αr]_1, [αr]_2, and γr, and defines βr = r + [αr]_1 + [αr]_2.
  • H. Truncation Protocol: The truncation security proof supplies simulator descriptions for corrupt P0 and corrupt P1.The corrupt-P1 simulator is presented separately in Fig. 54.
Loading 2005.09042v1…