PaperlayerView exact revision on arXiv

Source-linked AI summary

SWIFT: Super-fast and Robust Privacy-Preserving Machine Learning

Nishat Koti, Mahak Pancholi, Arpita Patra, Ajith Suresh

arXiv:2005.10296v3cs.CRcs.LG

TL;DR

PPML needs to compute on private data despite the high cost of ML, motivating secure outsourcing to powerful servers. SWIFT provides maliciously secure, robust 3PC and 4PC protocols with guaranteed output delivery. It matches or improves prior efficiency while strengthening security, including twice-faster performance than robust FLASH in 4PC, but leaves mixed-world conversions and some algorithms for future work.

  • Problem

    PPML computation is costly, and existing outsourced protocols may provide only abort security or fairness rather than guaranteed output delivery.

  • Method

    SWIFT uses maliciously secure secret-shared 3PC and 4PC over rings, with preprocessing and Joint Message Passing to achieve robust PPML computation.

  • Results

    SWIFT matches or improves fair BLAZE and Trident while being twice faster than robust FLASH in 4PC.

  • Takeaways & Limitations

    SWIFT provides robust PPML with stronger output-delivery guarantees at competitive efficiency in 3PC and 4PC.

  • Takeaways & Limitations

    SWIFT leaves FaF-secure 4PC, mixed-world conversions, and support for algorithms such as Decision Trees and k-means for future work.

Abstract

from arXiv · show

Performing machine learning (ML) computation on private data while maintaining data privacy, aka Privacy-preserving Machine Learning~(PPML), is an emergent field of research. Recently, PPML has seen a visible shift towards the adoption of the Secure Outsourced Computation~(SOC) paradigm due to the heavy computation that it entails. In the SOC paradigm, computation is outsourced to a set of powerful and specially equipped servers that provide service on a pay-per-use basis. In this work, we propose SWIFT, a robust PPML framework for a range of ML algorithms in SOC setting, that guarantees output delivery to the users irrespective of any adversarial behaviour. Robustness, a highly desirable feature, evokes user participation without the fear of denial of service. At the heart of our framework lies a highly-efficient, maliciously-secure, three-party computation (3PC) over rings that provides guaranteed output delivery (GOD) in the honest-majority setting. To the best of our knowledge, SWIFT is the first robust and efficient PPML framework in the 3PC setting. SWIFT is as fast as (and is strictly better in some cases than) the best-known 3PC framework BLAZE (Patra et al. NDSS'20), which only achieves fairness. We extend our 3PC framework for four parties (4PC). In this regime, SWIFT is as fast as the best known fair 4PC framework Trident (Chaudhari et al. NDSS'20) and twice faster than the best-known robust 4PC framework FLASH (Byali et al. PETS'20). We demonstrate our framework's practical relevance by benchmarking popular ML algorithms such as Logistic Regression and deep Neural Networks such as VGG16 and LeNet, both over a 64-bit ring in a WAN setting. For deep NN, our results testify to our claims that we provide improved security guarantee while incurring no additional overhead for 3PC and obtaining 2x improvement for 4PC.

1 Introduction

PPML outsources computationally heavy private-data ML to secure multiparty protocols, but existing guarantees may permit aborts or fairness-only delivery. SWIFT targets robust guaranteed output delivery while retaining practical efficiency in 3PC and 4PC.

  • 1 Introduction: PPML protects private data during ML computation but increases computational cost, motivating secure outsourcing to specialized pay-per-use servers.The SOC paradigm addresses end-users’ lack of infrastructure for these workloads.
  • 1 Introduction: Robustness guarantees output delivery despite adversarial behavior, avoiding denial of service that can affect inference users and service providers.Fairness or abort security may leave users without desired outputs when a malicious server disrupts execution.
  • 1.1 Our Contributions: SWIFT provides maliciously secure 3PC and 4PC over rings with guaranteed output delivery in the honest-majority setting.Its preprocessing model separates input-independent, function-dependent work from the online computation.
  • 1.1 Our Contributions: SWIFT is as fast as, and sometimes better than, fair 3PC BLAZE, while 4PC is twice faster than robust FLASH and as fast as fair Trident.These comparisons pair stronger delivery guarantees with competitive efficiency.
  • 1.1 Our Contributions: SWIFT benchmarks Logistic Regression and neural-network inference, while mixed-world conversions required for neural-network training remain future work.The framework also supports blocks applicable to Linear Regression, SVMs, and Binarized Neural Networks.
  • 1.1 Our Contributions: The framework combines secret-shared PPML primitives with Joint Message Passing, which either relays a message successfully or identifies an honest server to complete computation.The amortized communication cost is ℓ elements for an ℓ-element message.
  • 1.1 Our Contributions: Eliminating or repeating computation in private-robustness approaches can double or triple communication cost, undermining efficiency gains.The paper also questions whether private robustness adds a clearly formalized security guarantee beyond traditional GOD.

2 Preliminaries

SWIFT models malicious 3PC with at most one corrupt server and represents PPML circuits over arithmetic or boolean rings. Secret sharing, fixed-point arithmetic, and setup primitives support preprocessing and online execution.

  • 2 Preliminaries: The 3PC model uses three servers, pairwise private authentic channels, synchrony, and a static adversary corrupting at most one server.A broadcast channel is used for 3PC, while training data and inference inputs are secret-shared among servers.
  • 2 Preliminaries: Protocols provide guaranteed output delivery, so all parties receive outputs regardless of adversarial behavior, with preprocessing separated from online computation.Training outputs the model to data owners, while inference outputs the query result to the client.
  • 2 Preliminaries: Circuits are evaluated over arithmetic Z2^ℓ or boolean Z2^1 rings, with fixed-point arithmetic representing decimals as signed ℓ-bit integers.The most significant bit represents the sign bit.
  • 2 Preliminaries: A one-time key setup establishes pre-shared PRF keys between servers, while protocols additionally use collision-resistant hashing and commitments.The key setup can itself be instantiated with a standard MPC protocol.
  • 2 Preliminaries: The notation defines vector elements x_i, vector dot products, matrix multiplication, bit positions v[i], and ring encoding b_R for Boolean bits.These definitions support the arithmetic and Boolean operations used by the protocols.

3 Robust 3PC and PPML

This section defines SWIFT’s 3PC sharing and Joint Message Passing primitives, then uses them to build robust protocols with guaranteed output delivery. The resulting protocols provide malicious security while preserving efficient communication through amortization.

  • Secret-Sharing Semantics: SWIFT’s 3PC uses [·]-, ⟨·⟩-, and J·K-sharing over Z2^ℓ, with boolean sharing over Z2^1.The J·K-sharing semantics combine additive sharing of α_v with values β_v and γ_v distributed across the servers.
  • Joint Message Passing: Joint Message Passing lets two servers relay a common value to the third, either completing delivery or identifying a trusted third party.The protocol uses a value and a hash, inconsistency bits, broadcasts, and a TTP-selection mechanism without retransmitting the value.
  • Joint Message Passing: 1 round and amortized communication of ℓ bits are required by Πjmp.The initial value transfer accounts for the communication, while later verification steps can be combined across multiple instances.
  • 3PC Protocols: 2 rounds and amortized communication of 2ℓ bits are required by the 3PC sharing protocol Πsh.Preprocessing is non-interactive; online sharing combines a direct transmission with one jmp-send.
  • Security Scope: The framework leaves Friends-and-Foes-secure robust 4PC for future work because robust 3PC cannot achieve that stronger security notion.Friends-and-Foes security requires hiding inputs from a quorum of honest parties treated as semi-honest.

4 Robust 4PC and PPML

SWIFT’s 4PC construction uses an efficient robust joint-message-passing primitive to build secret sharing, multiplication, and related protocols with guaranteed output delivery. The design removes broadcast, simplifies preprocessing, and improves communication over prior robust approaches.

  • 4PC contributions: 4PC eliminates broadcast and substantially simplifies multiplication preprocessing, while its jmp4 primitive robustly sends a common value between servers.The jmp4 primitive allows two servers to send a common value to a third server robustly.
  • Joint message passing: jmp4 identifies a TTP unanimously on inconsistency and halves bi-convey’s communication cost.Unlike bi-convey, jmp4 avoids exchanging internal randomness and requiring fresh key setup after inconsistencies.
  • Joint message passing: jmp4 requires 1 round and amortized communication of ℓ bits in the online phase.Hashing and inconsistency-bit exchanges can be amortized across multiple instances.
  • Sharing protocols: Sharing by P0, P1, or P2 requires 2 rounds and 2ℓ bits, whereas sharing by P3 requires 2 rounds and 3ℓ bits.The higher P3 cost results from an additional message before two parallel jmp4 calls.
  • Sharing protocols: Joint sharing requires 2ℓ bits when P3 shares with another server and ℓ bits otherwise.When P3 and P0 jointly share a preprocessing value, communication can drop to one element.
  • Multiplication protocol: 4PC multiplication reduces communication from 6 to 3 ring elements in both preprocessing and online phases compared with FLASH, matching Trident’s communication cost.The online protocol requires 1 round and amortized communication of 3ℓ bits.
  • PPML building blocks: The optimized PPML construction reduces online cost by deriving arithmetic shares of e^R and checking correctness through a relation involving (e⊕r_b)^R.The optimization replaces a more direct route with a lower-communication variant.

5 Applications and Benchmarking

SWIFT benchmarks Logistic Regression and neural-network inference over a 64-bit ring in a WAN, using throughput alongside communication and latency. Its 3PC performance matches BLAZE with stronger security, while 4PC improves substantially over FLASH and remains competitive with Trident.

  • Experimental Setup: SWIFT benchmarks Logistic Regression training and inference plus inference for three neural networks on MNIST and CIFAR-10.Experiments use a 64-bit ring and WAN deployment.
  • Logistic Regression: 3PC achieves guaranteed output delivery at no additional cost compared with BLAZE, although Logistic Regression inference throughput is slightly lower because verification adds rounds.Verification overhead becomes less evident when several iterations are grouped in neural-network inference.
  • Benchmarking Parameters: Throughput measures training iterations or inference queries per minute, complemented by online and overall communication and latency.The metric captures communication and round-complexity effects in a single parameter.
  • Logistic Regression: 2× higher inference throughput and 2.3× higher training throughput are observed for 4PC compared with FLASH.Compared with Trident, inference throughput drops 15.86% while training remains on par, trading performance for stronger security.
  • NN Inference: 3PC neural-network inference is on par with BLAZE while providing a better security guarantee.The reported 3PC comparison covers the benchmarked neural-network architectures.
  • NN Inference: 4PC neural-network inference improves throughput by at least 2.5× over FLASH for every architecture and is on par with Trident.The extra verification rounds are amortized as neural-network inference requires more rounds.

6 Conclusion

SWIFT presents an efficient PPML framework with guaranteed output delivery. Its 3PC protocols retain near-BLAZE performance with stronger security, while its 4PC protocols outperform FLASH and strengthen Trident’s security.

  • Conclusion: SWIFT achieves guaranteed output delivery, the strongest security guarantee considered in the framework.The framework targets efficient PPML computation in the honest-majority setting.
  • Conclusion: 3PC achieves almost the performance of BLAZE while improving its security guarantee.The authors report better performance in some cases.
  • Conclusion: 4PC outperforms the robust protocol FLASH by 2× performance-wise and uplifts the security of the fair protocol Trident.These comparisons combine performance against FLASH with stronger security against Trident.
  • Open Problems: Extending SWIFT to mixed-world conversions and algorithms such as Decision Trees and k-means Clustering remains open.The paper explicitly leaves these extensions as future work.

A.1 Shared Key Setup

The shared-key setup establishes PRF keys among the servers so they can non-interactively generate shared randomness. The setup is modeled as an ideal functionality for both 3PC and 4PC.

  • PRF-Based Sampling: The PRF has codomain Z2^ℓ and is used to generate non-interactive random values.Servers invoke the PRF with counters maintained across invocations.
  • 3PC Key Structure: In 3PC, each server pair shares one key, and all servers share an additional common key.The pairwise keys are k01, k02, and k12; the common key is kP.
  • Setup Functionality: The key setup is represented by functionality Fsetup and can be realized using any secure MPC protocol.An analogous functionality is specified for 4PC.
  • Zero Sharing: Servers generate additive shares of zero by subtracting neighboring pairwise PRF outputs, producing shares whose sum is zero.For server s, ζs = rs − r(s−1)%3.
  • Commitments: The commitment construction uses hashing to provide hiding and binding properties.Hiding protects the committed value, while binding prevents opening it to a different value.

B Instantiating FDotPPre

FDotPPre computes dot products through a semi-honest protocol followed by malicious verification. Grouped random-linear-combination checks reduce verification communication while preserving robust correctness checks.

  • Protocol Structure: FDotPPre first runs a semi-honest dot-product protocol and then verifies the output.This avoids treating a dot product as n separate multiplications.
  • Correctness Check: The verification circuit checks whether the difference between expected and actual messages is zero.Each server proves correctness of the additive share it sent.
  • Batch Verification: A random linear combination lets the protocol verify multiple dot-product tuples simultaneously with high probability.The approach extends verification techniques for degree-two relations to dot products over rings.
  • Communication Reduction: Grouping L small circuits into g and setting uL = M yields verification communication O(uL + M), giving a sub-linear cost.Here u = 4n + 2 and M = m/L.
  • Communication Cost: Verification of m dot products with vector dimension n costs O(√nm) extended ring elements.The construction supports robust verification for dot-product tuples rather than only scalar multiplications.
  • Communication Cost: The amortized maliciously secure dot-product cost can match the semi-honest cost of 3 ring elements.This is achieved by choosing the verification parameters appropriately.

C Security Analysis of Our Protocols

The security analysis proves the constructions using real-world/ideal-world simulation in setup-hybrid models for both three-party and four-party computation. It accounts for corruption-aware subprotocols and composes modular simulation steps into proofs for the complete protocols.

  • Proof Framework: Security is proved using real-world/ideal-world simulation in the Fsetup-hybrid model for 3PC and the Fsetup4-hybrid model for 4PC.Fsetup and Fsetup4 represent the ideal setup functionalities for three-server and four-server shared-key setup, respectively.
  • Proof Framework: The adversary model allows corruption of at most one server in the server set P.
  • Corruption Model: Corruption-aware functionalities provide the corrupt server’s identity when the adversary can choose which honest party becomes the Trusted Third Party.
  • Modular Simulation: Separate simulations for each subprotocol compose, in order, into the simulation for the entire 3PC or 4PC protocol.If a TTP is identified, the simulator stops that step and receives the corrupt party’s clear input for 3PC or input shares from the adversary for 4PC in the next round.

C.1 Security Proofs for 3PC protocols

The 3PC security proof is framed around an ideal functionality for evaluating a function f. The functionality is specified as F3PC and presented in Figure 29.

  • Ideal Functionality: The 3PC security proof uses the ideal functionality F3PC, shown in Figure 29.
  • Ideal Functionality: The ideal functionality for 3PC evaluates a function f.

C.1.1 Joint Message Passing (jmp) Protocol

The joint message passing protocol’s security proof uses simulators tailored to corrupt senders and receivers. Its checks, accusations, hashes, and TTP selection support the guaranteed-output-delivery construction.

  • Purpose: The jmp primitive is the crux for achieving guaranteed output delivery in the constructions.
  • Corrupt Sender: For a corrupt sender, the simulator receives the receiver’s value, computes a reference value from the adversary interaction and shared keys, and compares the two values.If the sender fails to provide a value, the simulator broadcasts an accusation and selects another TTP.
  • Corrupt Sender: A matching value causes the simulator to send b_k = 0, while a mismatch causes b_k = 1 on behalf of the receiver.
  • TTP Selection: Accusations can set the simulated value to ⊥ and select an honest party as TTP before the simulator skips to the final step.The specified cases select P_j or P_k depending on which party is accused.
  • Corrupt Sender: The sender-side simulator broadcasts H_j = H(v) on behalf of the other sender.
  • Corrupt Receiver: For a corrupt receiver, the simulator computes v honestly and sends v and H(v) to the adversary on behalf of the honest parties.The corrupt-receiver case is presented in Figure 31.

C.1.2 Sharing Protocol

The sharing protocol’s simulators emulate setup keys and then invoke jmp simulations according to which party is the dealer. The cases are organized by corrupt dealer and corresponding party roles.

  • Setup Simulation: The simulator emulates Fsetup and provides the adversary with the keys (k01, k02, kP).Commonly held values are sampled using the appropriate shared key; otherwise, values are sampled randomly.
  • Dealer Cases: When P0 is the dealer, the simulator receives β_v for P1, sets msg = v, and simulates jmp with P0 as a sender.
  • Dealer Cases: When P1 is the dealer, the jmp simulation follows the corrupt-receiver simulator with P0 acting as receiver.
  • Dealer Cases: The P2 dealer case is handled similarly to the P1 dealer case.The corrupt P1 proof is given in Figure 33, while the corrupt P2 case is stated to be similar.

C.1.3 Multiplication Protocol

The multiplication protocol is described through simulator cases for corrupt parties, with simulator actions covering multiplication, extraction, and joint-message steps.

  • C.1.3 Multiplication Protocol: Simulator cases cover corruption of P0 and P1, with the P2 case stated as similar.The figures identify the corresponding simulator views for corrupt P0 and P1.
  • C.1.3 Multiplication Protocol: The simulator generates shared values and emulates multiplication-related functionality on behalf of honest parties.The described actions include generating shares of d,e, extracting ψ and χ shares, and computing βz + γz.
  • C.1.3 Multiplication Protocol: Joint-message steps are simulated according to the relevant simulator while parties act as senders or receivers for shared products.The protocol includes sender and receiver roles for [β⋆z]1 and [β⋆z]2.

C.1.4 Reconstruction Protocol

The reconstruction protocol’s security proof gives a simulator for a corrupt P0 and states that the P1 and P2 cases are analogous.

  • C.1.4 Reconstruction Protocol: The corrupt-P0 case is presented in Figure 52, while the corrupt-P1 and corrupt-P2 cases are stated to be similar.The simulator computes commitments on shared values for the honest parties.
  • C.1.4 Reconstruction Protocol: The simulator computes commitments on [αv]1, [αv]2, and γv for P1 and P2 using their respective shared keys.This is the stated simulator action for the reconstruction proof.

C.1.5 Joint Sharing Protocol

The joint sharing protocol is analyzed with simulator cases for corrupt parties, covering setup, dot-product preprocessing, and generation of shared randomness.

  • C.1.5 Joint Sharing Protocol: Simulator cases are provided for corrupt P0 and P1, with the corresponding P2 cases stated as similar.The proof identifies Figures 37–39 for these corruption cases.
  • C.1.5 Joint Sharing Protocol: The simulator emulates setup and provides shared keys to the adversary, sampling commonly held values with keys and other values randomly.This setup pattern is stated for the joint sharing proof.
  • C.1.5 Joint Sharing Protocol: For dot-product preprocessing, the simulator emulates FDotPPre and derives ψ and the corresponding χ shares for honest parties.The online simulation is then described separately for corrupt P0, P1, and P2.
  • C.1.5 Joint Sharing Protocol: The truncation-generation simulator samples r1[i] using shared keys and samples r2[i] randomly on behalf of the relevant parties.The protocol generates J·K-shares of the resulting values.

C.2 Security Proofs for 4PC protocols

The 4PC security proofs define the ideal functionality and analyze simulator cases for corrupt senders, receivers, and servers across the protocol primitives.

  • C.2 Security Proofs for 4PC protocols: The ideal functionality F4PC evaluates a circuit-defined function f in the 4PC setting.The corresponding figure presents the ideal functionality for 4PC computation.
  • C.2 Security Proofs for 4PC protocols: The proofs analyze corruption of senders, receivers, and the fourth server through dedicated simulator cases for joint message passing.Figures 43–45 cover corrupt sender Pi, receiver Pk, and outside server Pl.
  • C.2 Security Proofs for 4PC protocols: For corrupt receivers, simulators send v and H(v) on behalf of honest parties using shared-key knowledge.This behavior is stated for the receiver-corruption case.
  • C.2 Security Proofs for 4PC protocols: Several simulators compute or sample protocol shares while emulating joint-message steps according to the relevant corruption case.The descriptions include β⋆z shares, χ shares, Γxy shares, and α-values sampled with keys or randomly.
  • C.2 Security Proofs for 4PC protocols: The truncation-generation proof samples R1 and R2 using the respective shared keys with the adversary.The corrupt-party cases are given in Figures 59 and 60.
Loading 2005.10296v3…