Pith. sign in

REVIEW 4 major objections 5 minor 1 cited by

CrypTorch compiles MPC-based ML into modular stages and auto-tunes per-layer operator approximations, claiming 1.17–1.38× speedup without accuracy loss over an optimized baseline.

Reviewed by Pith at T0; open to challenge. T0 means a machine referee read the full paper against a public rubric. the ladder, T0–T4 →

T0 review · deepseek-v4-flash

2026-08-03 20:25 UTC pith:PNVFFYL4

load-bearing objection Worth taking seriously: a genuinely useful compiler framework for MPC inference, with one load-bearing validation gap around the non-MPC auto-tuning runtime. the 4 major comments →

arxiv 2511.19711 v2 pith:PNVFFYL4 submitted 2025-11-24 cs.CR cs.AIcs.PL

CrypTorch: PyTorch-based Auto-tuning Compiler for Machine Learning with Multi-party Computation

classification cs.CR cs.AIcs.PL
keywords multi-party computationMPC-based machine learningoperator approximationauto-tuning compilerprivate inferencefixed-point arithmeticPyTorch export IRaccuracy-performance tradeoff
verification ladder T0 review T1 audit T2 compute T3 formal T4 reserved

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper argues that in modern MPC-based machine learning, the dominant remaining bottleneck is no longer matrix multiplication or comparison kernels but the approximations used for operators MPC cannot run natively, such as Softmax, GELU, LayerNorm, and SiLU. Existing frameworks fix these approximations globally, and the paper shows they are often both too inaccurate—ruining output on some inputs—and unnecessarily slow. CrypTorch splits compilation into modular stages, exposes approximations as tunable compiler passes, and automatically chooses an approximation per operator under a user-supplied accuracy budget. On top of a heavily optimized baseline, the auto-tuner alone gives 1.17–1.38× speedup without accuracy loss and 1.22–1.8× when some degradation is allowed; the full framework is 3.22–8.6× faster than CrypTen. The broader point is that approximation selection should be a compiler optimization, not a manual runtime design decision.

Core claim

Operator approximation—not communication or MatMul—is the main performance and accuracy bottleneck in a well-optimized MPC-based ML framework, and it can be removed automatically. CrypTorch makes approximation a compiler stage: a frontend annotates tensor ownership on PyTorch export IR; an approximation stage rewrites unsupported operators into supported ones, each exposing tunable knobs (iteration count, clamping, polynomial degree); an auto-tuner searches these knobs per operator, tests candidates on a fast non-MPC GPU runtime, and rolls back changes that violate an accuracy threshold. A backend then lowers the chosen graph to MPC with formal encryption, scaling, truncation, and comparison

What carries the argument

The load-bearing mechanism is the tunable approximation pass combined with per-operator search. CrypTorch represents approximations as compiler passes with explicit knobs, provides a programming interface so new approximations are added as short pass bodies, and uses a greedy or hill-climbing tuner that lowers candidate graphs to a non-MPC PyTorch GPU runtime, compares output quality against the most accurate baseline, and rolls back unacceptable changes. Because graphs at that point are MPC-agnostic export IR, search cost stays low. The backend's formal type and scale rules—secret versus public, integer ring size, scaling-factor propagation, truncation—then make the chosen approximations ex

Load-bearing premise

The tuner judges candidate approximations by running them on a non-MPC PyTorch GPU and assumes this reflects their relative accuracy on the real MPC integer-ring runtime, where fixed-point truncation, scaling-factor mismatches, and local-truncation underflow also inject errors.

What would settle it

Run a model from the paper, such as BERT-SST2, under CrypTorch's chosen moderate configuration on a real two-party MPC setup and compare the resulting accuracy against the non-MPC estimate from the auto-tuner's search. If any operator's MPC-specific fixed-point error changes the final accuracy by more than the user's budget, or if two configurations ranked on GPU reverse their ranking on MPC, the 'without accuracy loss' claim is falsified.

Watch this falsifier — get emailed when new claim-graph text bears on it.

If this is right

  • If correct, the standard practice of hard-coding one approximation per operator globally in an MPC runtime can be replaced by automatic per-layer selection, removing a source of both wasted communication and accuracy failures.
  • Users can specify an accuracy budget (e.g., <0.5%, <2%, <5% degradation) and the tuner trades speed against that budget at operator granularity, including automatically discovering that some LayerNorm and Softmax instances tolerate very aggressive approximations.
  • New approximations can be added as short IR passes rather than by modifying runtime internals, lowering the barrier to adopting future advances in MPC kernels and protocols.
  • The speedup grows with longer BERT sequences and larger batch sizes because approximation tuning cuts communication bytes more than rounds; the benefit holds when models are encrypted, though slightly reduced.
  • Because the IR and backend formalism are separable from the specific MPC runtime, the same auto-tuning idea can be reapplied to other MPC backends once they are ported into the compiler.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • A natural extension is to treat the accuracy budget as one axis of a latency–accuracy Pareto search rather than a hard threshold, letting the tuner expose a frontier of configurations instead of a single point.
  • Because the tuner independently rediscovers known MPC-friendly design choices, such as ReLU-like Softmax and low-degree polynomial activations, it could serve as an automated oracle for architecture search: run the tuner on a candidate architecture to see which non-linearities are actually cheap.
  • The non-MPC search step is the main risk point: if fixed-point truncation, scaling-factor mismatch, or local-truncation underflow changes candidate rankings, the chosen configuration could violate a tight budget on the real MPC runtime. A cheap validation would be to run only the tuner's final configuration and its top alternates on real MPC during search.
  • The search currently uses loss on held-out data; using per-layer sensitivity metrics or calibrated uncertainty could reduce the hundreds of candidates tested and shorten the multi-hour search times reported.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit.

Referee Report

4 major / 5 minor

Summary. The paper presents CrypTorch, a multi-stage compiler for MPC-based ML built on PyTorch 2's compiler infrastructure. The authors first engineer CrypTen++, an optimized variant of CrypTen (14.4–96.2× kernel speedups), and use it to characterize MPC inference overheads, finding that operator approximations (Softmax, GELU, SiLU, etc.) dominate in Transformer and EfficientNet models (72.8–97%). CrypTorch separates operator approximation from the MPC runtime, exposes a tunable-pass programming interface, and auto-tunes per-operator approximation choices using a greedy/hill-climbing search that evaluates candidates on a non-MPC PyTorch GPU runtime. The paper claims 1.17–1.38× speedup without sacrificing accuracy and 1.22–1.8× speedup when some accuracy degradation is allowed, on top of CrypTen++; compared to CrypTen, it claims 3.22–8.6× end-to-end speedup. It also formalizes backend translation rules for scaling/truncation/encryption and demonstrates extensibility via a HummingBird auto-tuner pass.

Significance. If validated, CrypTorch would be a practically valuable contribution: it converts a manual, global, and often opaque approximation-selection process into an automatic per-operator compiler stage, and it ships a usable optimized baseline (CrypTen++) as well as a formal specification of MPC-specific lowering rules. The modular design on PyTorch 2's IR is sensible, and the characterization study is a useful update to older overhead analyses. However, the central accuracy-preservation claim currently rests on an unvalidated proxy: candidate approximations are ranked on a non-MPC GPU runtime, while the actual MPC backend introduces fixed-point truncation, scaling-conversion, and underflow errors that are not modeled during the search. No final task accuracy numbers are reported for any tuned configuration, so the 'without accuracy loss' claim is not established by the evidence in the paper.

major comments (4)
  1. [§4.3.2, Figure 8] The load-bearing assumption is stated in §4.3.2: testing on a non-MPC PyTorch GPU runtime 'still captur[es] all the approximation-induced errors.' This is not supported. The search graph is lowered before the MPC backend inserts MPC-specific operations: truncation after every secret multiplication (Sec-Sec Mul, §4.4.2), scaling-factor conversion errors (Sec-PubFloat Add/Mul, §4.4.2), and probabilistic underflow from local truncation (§2.2.1). These errors are not candidate-independent: changing t or the polynomial degree changes the distribution of intermediate values, which can change the sign and magnitude of fixed-point error, and hence which approximation is actually best on the MPC runtime. The paper provides no experiment comparing candidate rankings or final accuracy between the non-MPC search runtime and the real CrypTen++ runtime. Without such validation, the 'without accuracy l
  2. [§6.2, Figure 14] No final task accuracy numbers are reported for CrypTorch-eco, -moderate, or -aggressive. The text and figure only state user-supplied thresholds (<0.5%, <2%, <5%) and report speedups. The claim that CrypTorch-eco 'mostly maintains accuracy' therefore lacks direct evidence. The manuscript should report achieved accuracy (with variance or confidence intervals) for each model and task, for CrypTen++ and for each CrypTorch configuration, and clearly state how many runs were averaged.
  3. [§4.3.2 / §6.1] The output-quality metric used by the auto-tuner is not precisely defined. §4.3.2 says quality is compared with the 'maximally accurate approximation' against a user-given threshold, and §6.1 says both model accuracy and loss were explored with loss working better. The exact loss function, the search dataset size per model, whether the threshold is checked on a held-out split, and the rollback rule are not specified. This matters because the search result—and therefore the speedup numbers—depends on this metric. Please provide the concrete definition and the values used for each experiment.
  4. [§1 / §6.2.1] The speedup claims are reported differently in the abstract, introduction, and evaluation body. The abstract says auto-tuning alone gives 1.21–1.5× and 1.33–1.74×; the introduction says 1.20–1.7× and 1.31–1.8×; §6.2.1 reports LAN 1.20–1.38× / 1.21–1.55× / 1.31–1.7× and WAN 1.19–1.42× / 1.24–1.62× / 1.35–1.80×. The end-to-end CrypTen comparison also varies (abstract 3.74–8.32×, introduction and §6.2.2 3.22–8.6×). The central claim should be stated with one consistent set of numbers and clearly tied to the experimental section.
minor comments (5)
  1. [§3.1 / §4.5] The HummingBird technique [78] is used both inside CrypTen++ as a static guess and as an additional auto-tuned pass in CrypTorch. The paper does isolate its incremental benefit (6–10%, Figure 17), which is good. Given that [78] is a co-authored work of one of the authors, please add an explicit disclosure in the final version.
  2. [§3.2.2, Figure 4] The axis labels in Figure 4 are difficult to read and appear garbled (e.g., the x-axis around '-520/-515/-510' and the labels '5 0 5'). Please redraw with clearer tick labels and larger fonts.
  3. [§4.5] Typo: 'addational speedup' should be 'additional speedup'.
  4. [§6.5] The usability comparison reports lines of code added (3 vs. 46), but no information is given about the complexity or maintainability of the pass interface beyond line counts. Please also provide the actual pass code for LayerNorm in an appendix or artifact.
  5. [§5] The security argument says MPC kernels are secure by themselves and 'their security does not degrade upon composition.' This is stated without reference to standard composition theorems or to the semi-honest threat model. A brief justification or citation would strengthen the claim.

Circularity Check

0 steps flagged

No derivation-level circularity: the speedup claims are measured on the actual MPC runtime, and the only self-citation (HummingBird) is isolated and not load-bearing. The main caveat is an unvalidated transfer assumption from the non-MPC search runtime to MPC fixed-point behavior, which is a correctness risk rather than a circular step.

full rationale

The paper's central claims are empirical measurements, not quantities derived from a fitted model. The auto-tuner in Section 4.3.2 selects approximations by evaluating output quality on a non-MPC PyTorch GPU runtime, but the reported speedups in Section 6.2.1 are measured end-to-end on the CrypTen++ MPC runtime. No equation-level reduction equates the search-time quality metric to the final MPC accuracy or to the speedup numbers; the speedup is observed, not derived. The backend translation rules in Section 4.4.2 are formalizations of standard fixed-point scaling and do not constitute a prediction that is forced by construction. The only notable self-citation is [78] (HummingBird), by co-author Maeng, used in the CrypTen++ baseline and as an additional pass. This is not load-bearing: the auto-tuning speedup is reported on top of CrypTen++, which already includes the HummingBird-based improvements, and Figure 17 isolates the additional benefit of the CrypTorch HummingBird tuner at only 6-10%. The paper also explicitly states its HummingBird implementation 'does not follow the original proposal's search strategy exactly' and is a proof-of-concept, further reducing any reliance on the self-cited work. The genuine risk flagged by the paper's own design is Section 4.3.2's statement that testing on a non-MPC GPU runtime 'still captur[es] all the approximation-induced errors.' The MPC backend in Section 4.4.2 inserts truncation, scaling-factor conversion, and probabilistic underflow effects (Section 2.2.1, Sec-Sec Mul, Sec-PubFloat Add) that the non-MPC GPU runtime does not model. If those fixed-point effects change the relative ranking of approximation candidates, the selected configurations could violate the user's accuracy budget on the real MPC runtime. The paper reports no experiment comparing candidate rankings or final task accuracy on CrypTen++ versus the non-MPC search runtime. This is an internal-correctness / validation gap, not circularity: the speedup is not a consequence of the search metric, and the accuracy claim is an empirical transfer assumption rather than an equation that reduces to its input. There is also a wording inconsistency: the abstract/intro claim 'without sacrificing accuracy' is looser than the Section 6.2.1 definition of CrypTorch-eco as tolerating '< 0.5% accuracy degradation.' That is a reporting discrepancy, not a circular derivation. Overall, the central auto-tuning speedup claims have independent empirical content, so the

Axiom & Free-Parameter Ledger

3 free parameters · 5 axioms · 0 invented entities

CrypTorch introduces no new cryptographic primitives or physical entities. The central claim rests on empirical assumptions about approximation-error dominance, the fidelity of non-MPC testing, and the representativeness of the search data, plus inherited MPC protocol security assumptions.

free parameters (3)
  • Accuracy budget thresholds = 0.5% / 2% / 5%
    User-specified bounds used by the auto-tuner. All reported speedup ranges are conditional on these choices, and no sensitivity analysis across threshold values is shown.
  • Fixed-point scale s_d = 2^16
    Inherited from CrypTen; determines truncation error in the backend. The paper uses it without evaluating its effect on the accuracy of tuned approximations.
  • Search dataset sizes = 8k (BERT) / 10k (image models)
    Chosen by hand for the auto-tuner; the speedup/accuracy results depend on this choice and on the held-out split being representative.
axioms (5)
  • domain assumption Underlying MPC protocols (Beaver triples, GMW, CUTLASS kernels, HummingBird) are secure and correct as claimed by their original papers.
    Section 2.1.2: 'We reuse low-level MPC protocols and kernel designs from existing literature and build atop them, assuming they are secure.'
  • ad hoc to paper Approximation output quality measured on a non-MPC GPU runtime is a faithful proxy for final MPC output quality.
    Section 4.3.2: The auto-tuner lowers candidates to a PyTorch GPU runtime to test output quality; this ignores MPC fixed-point truncation and underflow effects.
  • domain assumption Parties are semi-honest and non-colluding.
    Section 2.1.2: 'We assume the parties do not collude... and the parties are semi-honest.'
  • domain assumption The held-out search dataset is representative of deployment inputs and can be treated as public.
    Section 5: 'the approximation auto-tuner... relies on a representative training data that is considered public' and assumes deployment inputs follow the same distribution.
  • ad hoc to paper Per-operator approximation choices compose independently, so greedy/hill-climbing search over individual operators reaches a safe global configuration.
    CrypTorch tunes at per-operator granularity and relies on the search to capture context-dependent error tolerance; no formal guarantee is provided for composition of many tuned approximations.

pith-pipeline@v1.3.0-alltime-deepseek · 32762 in / 11956 out tokens · 106199 ms · 2026-08-03T20:25:23.721069+00:00 · methodology

0 comments
read the original abstract

MPC-based ML uses multi-party computation (MPC) to run machine learning (ML) workloads across multiple parties without each having to share their private data or model parameters. However, existing frameworks frequently degrade accuracy and performance due to a series of MPC-specific transformations that add errors and overheads. These transformations are mostly opaque to users, making it hard to find and/or optimize problematic transformations. We propose CrypTorch, a modular, extensible, and iteratively-testable compiler framework for MPC-based ML. CrypTorch splits MPC-specific transformations into modular compilation stages, allowing users to easily inspect and optimize them. CrypTorch emits an executable graph after each transformation, allowing iterative testing to pinpoint any problematic transformations. Building on these features, CrypTorch automatically chooses a set of transformations from a pool of choices to balance performance and accuracy during the operator approximation stage, which we identified as the biggest contributor to accuracy/performance degradation. CrypTorch's auto-tuning alone provides 1.21-1.5x speedup without accuracy loss, and 1.33-1.74x speedup when some accuracy degradation is allowed. Combined with better engineering and adoption of state-of-the-art practices (made easier due to CrypTorch's modular design), CrypTorch brings 3.74-8.32x end-to-end speedup compared to the popular CrypTen. CrypTorch is built as an extension to PyTorch 2's compiler.

Figures

Figures reproduced from arXiv: 2511.19711 by Gang Tan, Jinyu Liu, Kiwan Maeng.

Figure 1
Figure 1. Figure 1: Scenarios for MPC-based ML. MPC-based ML frameworks run ML training/inference with￾out the parties having to reveal their secret data or model weights to others. Existing frameworks can be categorized into either client-server MPC or multi-server MPC. Client￾server MPC [16, 32, 46, 53, 70, 73, 81, 83, 89, 95] assumes MPC between a powerful server and a less-powerful client device (e.g., smartphone). They r… view at source ↗
Figure 3
Figure 3. Figure 3: Overhead breakdown from CrypTen++. The thick contour shows the breakdown between higher [PITH_FULL_IMAGE:figures/full_fig_p005_3.png] view at source ↗
Figure 2
Figure 2. Figure 2: Speedups from CrypTen++’s kernels compared to the original CrypTen’s. CrypTen++ adopted the following optimizations. First, it replaced the slow 64-bit integer MatMul and Conv2d kernels from CrypTen with more efficient ones based on the NVIDIA CUTLASS [86] library, as suggested by several recent works [40, 76, 120]. This improved the per￾formance of these compute kernels by 96.2× and 14.4×, respectively, o… view at source ↗
Figure 4
Figure 4. Figure 4: Functional behavior (left) and the latency (right) for various MPC approximations for [PITH_FULL_IMAGE:figures/full_fig_p006_4.png] view at source ↗
Figure 5
Figure 5. Figure 5: Overview of CrypTorch. Compared to existing approaches where the approximation of an operation [PITH_FULL_IMAGE:figures/full_fig_p009_5.png] view at source ↗
Figure 6
Figure 6. Figure 6: User-level code for CrypTorch. 4.2.1 Programming Model and IR [PITH_FULL_IMAGE:figures/full_fig_p009_6.png] view at source ↗
Figure 8
Figure 8. Figure 8: During the search, each candidate is lowered to a non-MPC GPU runtime and tested. [PITH_FULL_IMAGE:figures/full_fig_p011_8.png] view at source ↗
Figure 7
Figure 7. Figure 7: Approximation with tunable knobs (highlighted). [PITH_FULL_IMAGE:figures/full_fig_p011_7.png] view at source ↗
Figure 9
Figure 9. Figure 9: Grammar for the input graph to the CrypTorch compiler backend. [PITH_FULL_IMAGE:figures/full_fig_p012_9.png] view at source ↗
Figure 10
Figure 10. Figure 10: Grammar for the output of the CrypTorch compiler backend. [PITH_FULL_IMAGE:figures/full_fig_p013_10.png] view at source ↗
Figure 11
Figure 11. Figure 11: Rules for encryption. 𝐸 contains the normal (non-MPC) add/mul-like operators (⊕, ⊗), and is additionally equipped with MPC-specific operators. 𝐸 has an MPC version of mul-like operators (⊗𝑀𝑃𝐶) and an MPC version of less-than-zero (ltz𝑀𝑃𝐶), which correspond to the MPC multiplication using the Beaver’s triples and comparison using the GMW protocol (Section 2.2.1), respectively. 𝐸 also has a truncation opera… view at source ↗
Figure 12
Figure 12. Figure 12: Rules for add-like operators. Γ ⊢ 𝑒1 ⇒𝑖 𝐸1 : ⟨Sec, Int𝑑, 𝑠1⟩ Γ ⊢ 𝑒2 ⇒𝑖 𝐸2 : ⟨Sec, Int𝑑, 𝑠2⟩ min(𝑠1, 𝑠2) = 𝑠𝑚𝑖𝑛 max(𝑠1, 𝑠2) = 𝑠𝑚𝑎𝑥 Γ ⊢ ⊗(𝑒1, 𝑒2) ⇒𝑖 trunc(⊗𝑀𝑃𝐶 (𝐸1, 𝐸2), 𝑠𝑚𝑖𝑛) : ⟨Sec, Int𝑑, 𝑠𝑚𝑎𝑥 ⟩ (Sec-Sec Mul) Γ ⊢ 𝑒1 ⇒𝑖 𝐸1 : ⟨Sec, Int𝑑, 𝑠1⟩ Γ ⊢ 𝑒2 ⇒𝑖 𝐸2 : ⟨Pub,𝑖𝑡, 𝑠2⟩ min(𝑠1, 𝑠2) = 𝑠𝑚𝑖𝑛 max(𝑠1, 𝑠2) = 𝑠𝑚𝑎𝑥 Γ ⊢ ⊗(𝑒1, 𝑒2) ⇒𝑖 trunc(⊗(𝐸1, 𝐸2), 𝑠𝑚𝑖𝑛) : ⟨Sec, Int𝑑, 𝑠𝑚𝑎𝑥 ⟩ (Sec-PubInt Mul) Γ ⊢ 𝑒1 ⇒𝑖 𝐸1 : ⟨Sec, Int… view at source ↗
Figure 13
Figure 13. Figure 13: Rules for mul-like operators. CrypTorch always performs the addition in party 0. Again, if the two scaling factors do not match, CrypTorch adds a scale operator. When adding a secret and a public floating-point (Sec-PubFloat Add), the floating-point is first converted to an integer through a scale operator, using a scaling factor of max(𝑠, 𝑠𝑑 ) = 𝑠𝑚𝑎𝑥 . Then, similar to Sec-PubInt Add, the secret is resca… view at source ↗
Figure 14
Figure 14. Figure 14: End-to-end speedup of CrypTorch with a varying degree of approximation (-eco tolerates <0.5% [PITH_FULL_IMAGE:figures/full_fig_p016_14.png] view at source ↗
Figure 15
Figure 15. Figure 15: Visualization of the auto-tuner results from CrypTorch-moderate. The x-axis shows each operator, [PITH_FULL_IMAGE:figures/full_fig_p017_15.png] view at source ↗
Figure 16
Figure 16. Figure 16: Speedup over CrypTen++ under various param [PITH_FULL_IMAGE:figures/full_fig_p018_16.png] view at source ↗
Figure 17
Figure 17. Figure 17: Impact of HummingBird auto-tuning vs. ap [PITH_FULL_IMAGE:figures/full_fig_p019_17.png] view at source ↗

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score.

  1. Beyond Latency: A System-Level Characterization of MPC and FHE for PPML

    cs.CR 2026-03 accept novelty 6.0

    System-level evaluation reveals that network constraints and hardware costs, rather than raw latency, often dictate the optimal choice between MPC and FHE for privacy-preserving ML.

Reference graph

Works this paper leans on

135 extracted references · 15 canonical work pages · cited by 1 Pith paper · 4 internal anchors

  1. [1]

    Kusner, and Adrià Gascón

    Nitin Agrawal, Ali Shahin Shamsabadi, Matt J. Kusner, and Adrià Gascón. 2019. QUOTIENT: Two-Party Secure Neural Network Training and Prediction. InProceedings of the 2019 ACM SIGSAC Conference on Computer and Communications Security, CCS 2019, London, UK, November 11-15, 2019. ACM, 1231–1247. doi:10.1145/3319535.3339819

  2. [2]

    Chandrakasan, Vinod Vaikuntanathan, and Ajay Joshi

    Rashmi Agrawal, Leo de Castro, Guowei Yang, Chiraag Juvekar, Rabia Tugce Yazicigil, Anantha P. Chandrakasan, Vinod Vaikuntanathan, and Ajay Joshi. 2023. FAB: An FPGA-based Accelerator for Bootstrappable Fully Homomorphic Encryption. InIEEE International Symposium on High-Performance Computer Architecture, HPCA 2023, Montreal, QC, Canada, February 25 - Mar...

  3. [3]

    Amazon. 2023. Amazon Echo & Alexa Devices. https://www.amazon.com/smart-home-devices/b?ie=UTF8&node= 9818047011

  4. [4]

    AMD. 2023. AMD Secure Encrypted Virtualization (SEV). https://www.amd.com/en/developer/sev.html

  5. [5]

    hack_softmax

    anakinxc. 2025. "hack_softmax" (spu/examples/python/ml/flax_llama7b/flax_llama7b.py, Line 56). https://github.com/secretflow/spu/blob/e86227631b115f5983aef8315adde387e0c0f63a/examples/python/ml/ flax_llama7b/flax_llama7b.py#L56

  6. [6]

    Jason Ansel, Edward Z. Yang, Horace He, Natalia Gimelshein, Animesh Jain, Michael Voznesensky, Bin Bao, Peter Bell, David Berard, Evgeni Burovski, Geeta Chauhan, Anjali Chourdia, Will Constable, Alban Desmaison, Zachary DeVito, Elias Ellison, Will Feng, Jiong Gong, Michael Gschwind, Brian Hirsh, Sherlock Huang, Kshiteej Kalambarkar, Laurent Kirsch, Michae...

  7. [7]

    Apple. 2024. Private Cloud Compute: A new frontier for AI privacy in the cloud. https://security.apple.com/blog/ private-cloud-compute/

  8. [8]

    Arm. 2023. TrustZone for Cortex-A. https://www.arm.com/technologies/trustzone-for-cortex-a

  9. [9]

    Donald Beaver. 1991. Efficient Multiparty Protocols Using Circuit Randomization. InAdvances in Cryptology - CRYPTO ’91, 11th Annual International Cryptology Conference, Santa Barbara, California, USA, August 11-15, 1991, Proceedings (Lecture Notes in Computer Science, Vol. 576). Springer, 420–432. doi:10.1007/3-540-46766-1_34

  10. [10]

    Dan Bogdanov, Sven Laur, and Jan Willemson. 2008. Sharemind: A Framework for Fast Privacy-Preserving Com- putations. InComputer Security - ESORICS 2008, 13th European Symposium on Research in Computer Security, Málaga, Spain, October 6-8, 2008. Proceedings (Lecture Notes in Computer Science, Vol. 5283). Springer, 192–206. doi:10.1007/978-3-540-88313-5_13

  11. [11]

    Megha Byali, Harsh Chaudhari, Arpita Patra, and Ajith Suresh. 2020. FLASH: Fast and Robust Framework for Privacy- preserving Machine Learning.Proc. Priv. Enhancing Technol.2020, 2 (2020), 459–480. doi:10.2478/popets-2020-0036

  12. [12]

    Han Cai, Chuang Gan, Tianzhe Wang, Zhekai Zhang, and Song Han. 2020. Once-for-All: Train One Network and Specialize it for Efficient Deployment. In8th International Conference on Learning Representations, ICLR 2020, Addis Ababa, Ethiopia, April 26-30, 2020. OpenReview.net. https://openreview.net/forum?id=HylxE1HKwS

  13. [13]

    Han Cai, Ligeng Zhu, and Song Han. 2019. ProxylessNAS: Direct Neural Architecture Search on Target Task and Hardware. InInternational Conference on Learning Representations. https://openreview.net/forum?id=HylVB3AqYm

  14. [14]

    Nicholas Carlini, Samuel Deng, Sanjam Garg, Somesh Jha, Saeed Mahloujifar, Mohammad Mahmoody, Shuang Song, Abhradeep Thakurta, and Florian Tramèr. 2020. An Attack on InstaHide: Is Private Learning Possible with Instance Encoding?CoRRabs/2011.05315 (2020). arXiv:2011.05315 https://arxiv.org/abs/2011.05315

  15. [15]

    Nicholas Carlini, Daniel Paleka, Krishnamurthy Dj Dvijotham, Thomas Steinke, Jonathan Hayase, A Feder Cooper, Katherine Lee, Matthew Jagielski, Milad Nasr, Arthur Conmy, et al. 2024. Stealing part of a production language model.arXiv preprint arXiv:2403.06634(2024). 22 Jinyu Liu, Gang Tan, and Kiwan Maeng

  16. [16]

    Nishanth Chandran, Divya Gupta, Aseem Rastogi, Rahul Sharma, and Shardul Tripathi. 2019. EzPC: Programmable and Efficient Secure Two-Party Computation for Machine Learning. InIEEE European Symposium on Security and Privacy, EuroS&P 2019, Stockholm, Sweden, June 17-19, 2019. IEEE, 496–511. doi:10.1109/EuroSP.2019.00043

  17. [17]

    Harsh Chaudhari, Ashish Choudhury, Arpita Patra, and Ajith Suresh. 2019. ASTRA: High Throughput 3PC over Rings with Application to Secure Prediction. InProceedings of the 2019 ACM SIGSAC Conference on Cloud Computing Security Workshop(London, United Kingdom)(CCSW’19). Association for Computing Machinery, New York, NY, USA, 81–92. doi:10.1145/3338466.3358922

  18. [18]

    Harsh Chaudhari, Rahul Rachuri, and Ajith Suresh. 2019. Trident: Efficient 4PC Framework for Privacy Preserving Machine Learning. Cryptology ePrint Archive, Paper 2019/1315. doi:10.14722/ndss.2020.23005

  19. [19]

    Wahby, Fraser Brown, and Wenting Zheng

    Edward Chen, Jinhao Zhu, Alex Ozdemir, Riad S. Wahby, Fraser Brown, and Wenting Zheng. 2023. Silph: A Framework for Scalable and Accurate Generation of Hybrid MPC Protocols. In44th IEEE Symposium on Security and Privacy, SP 2023, San Francisco, CA, USA, May 21-25, 2023. IEEE, 848–863. doi:10.1109/SP46215.2023.10179397

  20. [20]

    Siddhartha Chhabra, Brian Rogers, Yan Solihin, and Milos Prvulovic. 2011. SecureME: a hardware-software approach to full system security. InProceedings of the 25th International Conference on Supercomputing, 2011, Tucson, AZ, USA, May 31 - June 04, 2011, David K. Lowenthal, Bronis R. de Supinski, and Sally A. McKee (Eds.). ACM, 108–119. doi:10.1145/199589...

  21. [21]

    Minsu Cho, Zahra Ghodsi, Brandon Reagen, Siddharth Garg, and Chinmay Hegde. 2022. Sphynx: A Deep Neural Network Design for Private Inference.IEEE Secur. Priv.20, 5 (2022), 22–34. doi:10.1109/MSEC.2022.3165475

  22. [22]

    Minsu Cho, Ameya Joshi, Brandon Reagen, Siddharth Garg, and Chinmay Hegde. 2022. Selective Network Linearization for Efficient Private Inference. InInternational Conference on Machine Learning, ICML 2022, 17- 23 July 2022, Baltimore, Maryland, USA (Proceedings of Machine Learning Research, Vol. 162), Kamalika Chaud- huri, Stefanie Jegelka, Le Song, Csaba ...

  23. [23]

    Wonseok Choi, Jongmin Kim, and Jung Ho Ahn. 2025. Cheddar: A Swift Fully Homomorphic Encryption Library Designed for GPU Architectures.arXiv preprint arXiv:2407.13055(2025)

  24. [24]

    Daniel Demmler, Thomas Schneider, and Michael Zohner. 2015. ABY - A Framework for Efficient Mixed-Protocol Secure Two-Party Computation. In22nd Annual Network and Distributed System Security Symposium, NDSS 2015, San Diego, California, USA, February 8-11, 2015. The Internet Society. https://www.ndss-symposium.org/ndss2015/aby--- framework-efficient-mixed-...

  25. [25]

    Naren Dhyani, Jianqiao Mo, Minsu Cho, Ameya Joshi, Siddharth Garg, Brandon Reagen, and Chinmay Hegde. 2023. PriViT: Vision Transformers for Fast Private Inference.CoRRabs/2310.04604 (2023). doi:10.48550/ARXIV.2310.04604 arXiv:2310.04604

  26. [26]

    Ye Dong, Wen-jie Lu, Yancheng Zheng, Haoqi Wu, Derun Zhao, Jin Tan, Zhicong Huang, Cheng Hong, Tao Wei, and Wenguang Chen. 2023. PUMA: Secure Inference of LLaMA-7B in Five Minutes.CoRRabs/2307.12533 (2023). doi:10.48550/ARXIV.2307.12533 arXiv:2307.12533

  27. [27]

    Austin Ebel, Karthik Garimella, and Brandon Reagen. 2025. Orion: A Fully Homomorphic Encryption Framework for Deep Learning. InProceedings of the 30th ACM International Conference on Architectural Support for Programming Languages and Operating Systems, Volume 2(Rotterdam, Netherlands)(ASPLOS ’25). Association for Computing Machinery, New York, NY, USA, 7...

  28. [28]

    EPFL-LDS. 2021. Lattigo v2.3.0. https://github.com/ldsec/lattigo

  29. [29]

    facebookresearch. 2025. CrypTen/crypten/mpc/primitives/arithmetic.py, Line 362. https://github.com/ facebookresearch/CrypTen/blob/775868a02d6dac50774ce376a55b01fbd8bd85b6/crypten/mpc/primitives/arithmetic. py#L362

  30. [30]

    Liyue Fan. 2018. Image Pixelization with Differential Privacy. InData and Applications Security and Privacy XXXII - 32nd Annual IFIP WG 11.3 Conference, DBSec 2018, Bergamo, Italy, July 16-18, 2018, Proceedings (Lecture Notes in Computer Science, Vol. 10980), Florian Kerschbaum and Stefano Paraboschi (Eds.). Springer, 148–162. doi:10.1007/978- 3-319-95729-6_10

  31. [31]

    Liyue Fan. 2019. Differential privacy for image publication. InTheory and Practice of Differential Privacy (TPDP) Workshop, Vol. 1. 6

  32. [32]

    Karthik Garimella, Zahra Ghodsi, Nandan Kumar Jha, Siddharth Garg, and Brandon Reagen. 2023. Characterizing and Optimizing End-to-End Systems for Private Inference. InProceedings of the 28th ACM International Conference on Architectural Support for Programming Languages and Operating Systems, Volume 3, ASPLOS 2023, Vancouver, BC, Canada, March 25-29, 2023...

  33. [33]

    Karthik Garimella, Nandan Kumar Jha, and Brandon Reagen. 2021. Sisyphus: A Cautionary Tale of Using Low- Degree Polynomial Activations in Privacy-Preserving Deep Learning.CoRRabs/2107.12342 (2021). arXiv:2107.12342 https://arxiv.org/abs/2107.12342 CrypTorch : PyTorch-based Auto-tuning Compiler for Machine Learning with Multi-party Computation 23

  34. [34]

    Craig Gentry. 2009. Fully homomorphic encryption using ideal lattices. InProceedings of the 41st Annual ACM Symposium on Theory of Computing, STOC 2009, Bethesda, MD, USA, May 31 - June 2, 2009, Michael Mitzenmacher (Ed.). ACM, 169–178. doi:10.1145/1536414.1536440

  35. [35]

    Lauter, Michael Naehrig, and John Wernsing

    Ran Gilad-Bachrach, Nathan Dowlin, Kim Laine, Kristin E. Lauter, Michael Naehrig, and John Wernsing. 2016. In Proceedings of the 33nd International Conference on Machine Learning, ICML 2016, New York City, NY, USA, June 19-24, 2016 (JMLR Workshop and Conference Proceedings, Vol. 48). JMLR.org, 201–210. http://proceedings.mlr.press/v48/gilad- bachrach16.html

  36. [36]

    Oded Goldreich, Silvio Micali, and Avi Wigderson. 1991. Proofs that yield nothing but their validity or all languages in NP have zero-knowledge proof systems.J. ACM38, 3 (July 1991), 690–728. doi:10.1145/116825.116852

  37. [37]

    Google-BERT. 2018. BERT base model (uncased). https://huggingface.co/google-bert/bert-base-uncased

  38. [38]

    Kanav Gupta, Neha Jawalkar, Ananta Mukherjee, Nishanth Chandran, Divya Gupta, Ashish Panwar, and Rahul Sharma. 2024. SIGMA: Secure GPT Inference with Function Secret Sharing.Proc. Priv. Enhancing Technol.2024, 4 (2024), 61–79. doi:10.56553/POPETS-2024-0107

  39. [39]

    Meng Hao, Hongwei Li, Hanxiao Chen, Pengzhi Xing, Guowen Xu, and Tianwei Zhang. 2022. Iron: Private Inference on Transformers. InAdvances in Neural Information Processing Systems 35: Annual Conference on Neural Information Processing Systems 2022, NeurIPS 2022, New Orleans, LA, USA, November 28 - December 9, 2022

  40. [40]

    Christopher Harth-Kitzerow, Yongqin Wang, Rachit Rajat, Georg Carle, and Murali Annavaram. 2025. PIGEON: A High Throughput Framework for Private Inference of Neural Networks using Secure Multiparty Computation.Proc. Priv. Enhancing Technol.2025, 3 (2025), 88–105. doi:10.56553/POPETS-2025-0090

  41. [41]

    Marcella Hastings, Brett Hemenway, Daniel Noble, and Steve Zdancewic. 2019. SoK: General Purpose Compilers for Secure Multi-Party Computation. In2019 IEEE Symposium on Security and Privacy, SP 2019, San Francisco, CA, USA, May 19-23, 2019. IEEE, 1220–1237. doi:10.1109/SP.2019.00028

  42. [42]

    Trang-Thi Ho, Khoa-Dang Tran, and Yennun Huang. 2022. FedSGDCOVID: Federated SGD COVID-19 Detection under Local Differential Privacy Using Chest X-ray Images and Symptom Information.Sensors22, 10 (2022), 3728

  43. [43]

    Andreas Holzer, Martin Franz, Stefan Katzenbeisser, and Helmut Veith. 2012. Secure two-party computations in ANSI C. Inthe ACM Conference on Computer and Communications Security, CCS’12, Raleigh, NC, USA, October 16-18, 2012, Ting Yu, George Danezis, and Virgil D. Gligor (Eds.). ACM, 772–783. doi:10.1145/2382196.2382278

  44. [44]

    Google Home. 2023. Brands you love, united with Google Home. https://home.google.com/explore-devices/

  45. [45]

    Pengzhi Huang, Thang Hoang, Yueying Li, Elaine Shi, and G Edward Suh. 2022. STAMP: Lightweight TEE-Assisted MPC for Efficient Privacy-Preserving Machine Learning.arXiv preprint arXiv:2210.10133(2022)

  46. [46]

    Zhicong Huang, Wen-jie Lu, Cheng Hong, and Jiansheng Ding. 2022. Cheetah: Lean and Fast Secure Two-Party Deep Neural Network Inference. In31st USENIX Security Symposium, USENIX Security 2022, Boston, MA, USA, August 10-12, 2022, Kevin R. B. Butler and Kurt Thomas (Eds.). USENIX Association, 809–826. https://www.usenix.org/conference/ usenixsecurity22/pres...

  47. [47]

    Intel. 2023. Intel®Software Guard Extensions. https://www.intel.com/content/www/us/en/developer/tools/software- guard-extensions/overview.html

  48. [49]

    Siddharth Jayashankar, Edward Chen, Tom Tang, Wenting Zheng, and Dimitrios Skarlatos. 2025. Cinnamon: A Frame- work for Scale-Out Encrypted AI. InProceedings of the 30th ACM International Conference on Architectural Support for Programming Languages and Operating Systems, Volume 1(Rotterdam, Netherlands)(ASPLOS ’25). Association for Computing Machinery, N...

  49. [50]

    Nandan Kumar Jha, Zahra Ghodsi, Siddharth Garg, and Brandon Reagen. 2021. DeepReDuce: ReLU Reduction for Fast Private Inference. InProceedings of the 38th International Conference on Machine Learning, ICML 2021, 18-24 July 2021, Virtual Event (Proceedings of Machine Learning Research, Vol. 139), Marina Meila and Tong Zhang (Eds.). PMLR, 4839–4849. http://...

  50. [51]

    Nandan Kumar Jha and Brandon Reagen. 2023. DeepReShape: Redesigning Neural Networks for Efficient Private Inference.arXiv preprint arXiv:2304.10593(2023)

  51. [52]

    Wonkyung Jung, Sangpyo Kim, Jung Ho Ahn, Jung Hee Cheon, and Younho Lee. 2021. Over 100x Faster Bootstrapping in Fully Homomorphic Encryption through Memory-centric Optimization with GPUs.IACR Trans. Cryptogr. Hardw. Embed. Syst.2021, 4 (2021), 114–148. doi:10.46586/tches.v2021.i4.114-148

  52. [53]

    Chandrakasan

    Chiraag Juvekar, Vinod Vaikuntanathan, and Anantha P. Chandrakasan. 2018. GAZELLE: A Low Latency Framework for Secure Neural Network Inference. In27th USENIX Security Symposium, USENIX Security 2018, Baltimore, MD, USA, August 15-17, 2018, William Enck and Adrienne Porter Felt (Eds.). USENIX Association, 1651–1669. https: //www.usenix.org/conference/useni...

  53. [54]

    Marcel Keller. 2020. MP-SPDZ: A Versatile Framework for Multi-Party Computation. InCCS ’20: 2020 ACM SIGSAC Conference on Computer and Communications Security, Virtual Event, USA, November 9-13, 2020, Jay Ligatti, Xinming Ou, Jonathan Katz, and Giovanni Vigna (Eds.). ACM, 1575–1590. doi:10.1145/3372297.3417872

  54. [55]

    Mustakimur Rahman Khandaker, Yueqiang Cheng, Zhi Wang, and Tao Wei. 2020. COIN Attacks: On Insecurity of Enclave Untrusted Interfaces in SGX. InASPLOS ’20: Architectural Support for Programming Languages and Operating Systems, Lausanne, Switzerland, March 16-20, 2020, James R. Larus, Luis Ceze, and Karin Strauss (Eds.). ACM, 971–985. doi:10.1145/3373376.3378486

  55. [56]

    Donghwan Kim, Jaiyoung Park, Jongmin Kim, Sangpyo Kim, and Jung Ho Ahn. 2023. HyPHEN: A Hybrid Packing Method and Optimizations for Homomorphic Encryption-Based Neural Networks.CoRRabs/2302.02407 (2023). doi:10.48550/arXiv.2302.02407 arXiv:2302.02407

  56. [57]

    Jongmin Kim, Gwangho Lee, Sangpyo Kim, Gina Sohn, Minsoo Rhu, John Kim, and Jung Ho Ahn. 2022. ARK: Fully Homomorphic Encryption Accelerator with Runtime Data Generation and Inter-Operation Key Reuse. In55th IEEE/ACM International Symposium on Microarchitecture, MICRO 2022, Chicago, IL, USA, October 1-5, 2022. IEEE, 1237–1254. doi:10.1109/MICRO56248.2022.00086

  57. [58]

    Sangpyo Kim, Jongmin Kim, Michael Jaemin Kim, Wonkyung Jung, John Kim, Minsoo Rhu, and Jung Ho Ahn. 2022. BTS: an accelerator for bootstrappable fully homomorphic encryption. InISCA ’22: The 49th Annual International Symposium on Computer Architecture, New York, New York, USA, June 18 - 22, 2022, Valentina Salapura, Mohamed Zahran, Fred Chong, and Lingjia...

  58. [59]

    Hannun, Shubho Sengupta, Mark Ibrahim, and Laurens van der Maaten

    Brian Knott, Shobha Venkataraman, Awni Y. Hannun, Shubho Sengupta, Mark Ibrahim, and Laurens van der Maaten

  59. [60]

    Nishant Kumar, Mayank Rathee, Nishanth Chandran, Divya Gupta, Aseem Rastogi, and Rahul Sharma. 2020. CrypT- Flow: Secure TensorFlow Inference. In2020 IEEE Symposium on Security and Privacy, SP 2020, San Francisco, CA, USA, May 18-21, 2020. IEEE, 336–353. doi:10.1109/SP40000.2020.00092

  60. [61]

    Souvik Kundu, Shunlin Lu, Yuke Zhang, Jacqueline Tiffany Liu, and Peter A. Beerel. 2023. Learning to Linearize Deep Neural Networks for Secure and Efficient Private Inference. InThe Eleventh International Conference on Learning Representations, ICLR 2023, Kigali, Rwanda, May 1-5, 2023. OpenReview.net. https://openreview.net/pdf?id= BGF9IeDfmlH

  61. [62]

    Lee, Vijay Janapa Reddi, Gu-Yeon Wei, David Brooks, and G

    Maximilian Lam, Jeff Johnson, Wenjie Xiong, Kiwan Maeng, Udit Gupta, Minsoo Rhu, Hsien-Hsin S. Lee, Vijay Janapa Reddi, Gu-Yeon Wei, David Brooks, and G. Edward Suh. 2024. GPU-based Private Information Retrieval for On-Device Machine Learning Inference. InProceedings of the 29th ACM International Conference on Architectural Support for Programming Languag...

  62. [63]

    Chris Lattner and Vikram S. Adve. 2004. LLVM: A Compilation Framework for Lifelong Program Analysis & Transformation. In2nd IEEE / ACM International Symposium on Code Generation and Optimization (CGO 2004), 20-24 March 2004, San Jose, CA, USA. IEEE Computer Society, 75–88. doi:10.1109/CGO.2004.1281665

  63. [64]

    Dayeol Lee, David Kohlbrenner, Shweta Shinde, Krste Asanovic, and Dawn Song. 2020. Keystone: an open framework for architecting trusted execution environments. InEuroSys ’20: Fifteenth EuroSys Conference 2020, Heraklion, Greece, April 27-30, 2020, Angelos Bilas, Kostas Magoutis, Evangelos P. Markatos, Dejan Kostic, and Margo I. Seltzer (Eds.). ACM, 38:1–3...

  64. [65]

    Lee, Peter C

    Ruby B. Lee, Peter C. S. Kwan, John Patrick McGregor, Jeffrey S. Dwoskin, and Zhenghong Wang. 2005. Architecture for Protecting Critical Secrets in Microprocessors. In32st International Symposium on Computer Architecture (ISCA 2005), 4-8 June 2005, Madison, Wisconsin, USA. IEEE Computer Society, 2–13. doi:10.1109/ISCA.2005.14

  65. [66]

    Xing, and Hao Zhang

    Dacheng Li, Rulin Shao, Hongyi Wang, Han Guo, Eric P. Xing, and Hao Zhang. 2022. MPCFormer: fast, perfor- mant and private Transformer inference with MPC.CoRRabs/2211.01452 (2022). doi:10.48550/ARXIV.2211.01452 arXiv:2211.01452

  66. [67]

    Yunsheng Li, Yinpeng Chen, Xiyang Dai, Dongdong Chen, Mengchen Liu, Lu Yuan, Zicheng Liu, Lei Zhang, and Nuno Vasconcelos. 2021. MicroNet: Improving Image Recognition with Extremely Low FLOPs. In2021 IEEE/CVF International Conference on Computer Vision, ICCV 2021, Montreal, QC, Canada, October 10-17, 2021. IEEE, 458–467. doi:10.1109/ICCV48922.2021.00052

  67. [68]

    Mitchell, Chandramohan A

    David Lie, John C. Mitchell, Chandramohan A. Thekkath, and Mark Horowitz. 2003. Specifying and Verifying Hardware for Tamper-Resistant Software. In2003 IEEE Symposium on Security and Privacy (S&P 2003), 11-14 May 2003, Berkeley, CA, USA. IEEE Computer Society, 166. doi:10.1109/SECPRI.2003.1199335

  68. [69]

    Chang Liu, Xiao Shaun Wang, Kartik Nayak, Yan Huang, and Elaine Shi. 2015. ObliVM: A Programming Framework for Secure Computation. In2015 IEEE Symposium on Security and Privacy, SP 2015, San Jose, CA, USA, May 17-21, 2015. IEEE Computer Society, 359–376. doi:10.1109/SP.2015.29 CrypTorch : PyTorch-based Auto-tuning Compiler for Machine Learning with Multi-...

  69. [71]

    Weijie Liu, Hongbo Chen, XiaoFeng Wang, Zhi Li, Danfeng Zhang, Wenhao Wang, and Haixu Tang. 2021. Under- standing TEE containers, easy to use? Hard to trust.arXiv preprint arXiv:2109.01923(2021)

  70. [72]

    Qian Lou, Yilin Shen, Hongxia Jin, and Lei Jiang. 2021. SAFENet: A Secure, Accurate and Fast Neural Network Inference. In9th International Conference on Learning Representations, ICLR 2021, Virtual Event, Austria, May 3-7, 2021. OpenReview.net. https://openreview.net/forum?id=Cz3dbFm5u-

  71. [73]

    Wen-jie Lu, Zhicong Huang, Zhen Gu, Jingyu Li, Jian Liu, Cheng Hong, Kui Ren, Tao Wei, and Wenguang Chen

  72. [74]

    Jinglong Luo, Yehong Zhang, Jiaqi Zhang, Xin Mu, Hui Wang, Yue Yu, and Zenglin Xu. 2024. SecFormer: Towards Fast and Accurate Privacy-Preserving Inference for Large Language Models.CoRRabs/2401.00793 (2024). doi:10. 48550/ARXIV.2401.00793 arXiv:2401.00793

  73. [75]

    lvdmaaten. 2022. comment on: How to directly define the LayerNorm module? https://github.com/facebookresearch/ CrypTen/issues/399#issuecomment-1229263703

  74. [76]

    Junming Ma, Yancheng Zheng, Jun Feng, Derun Zhao, Haoqi Wu, Wenjing Fang, Jin Tan, Chaofan Yu, Benyu Zhang, and Lei Wang. 2023. SecretFlow-SPU: A Performant and User-Friendly Framework for Privacy-Preserving Machine Learning. InProceedings of the 2023 USENIX Annual Technical Conference, USENIX ATC 2023, Boston, MA, USA, July 10-12, 2023. USENIX Associatio...

  75. [77]

    Edward Suh

    Kiwan Maeng, Chuan Guo, Sanjay Kariyappa, and G. Edward Suh. 2023. Bounding the Invertibility of Privacy- preserving Instance Encoding using Fisher Information. InAdvances in Neural Information Processing Systems 36: Annual Conference on Neural Information Processing Systems 2023, NeurIPS 2023, New Orleans, LA, USA, December 10 - 16, 2023. http://papers.n...

  76. [78]

    Edward Suh

    Kiwan Maeng and G. Edward Suh. 2023. Approximating ReLU on a Reduced Ring for Efficient MPC-based Private Inference. arXiv:2309.04875 [cs.LG] https://arxiv.org/abs/2309.04875

  77. [79]

    Meta. 2023. Meta Portal Go. https://www.meta.com/portal/products/portal-go/

  78. [80]

    Microsoft. 2025. Azure Confidential Computing. https://learn.microsoft.com/en-us/azure/confidential-computing/

  79. [81]

    Pratyush Mishra, Ryan Lehmkuhl, Akshayaram Srinivasan, Wenting Zheng, and Raluca Ada Popa. 2020. Delphi: A Cryptographic Inference Service for Neural Networks. In29th USENIX Security Symposium, USENIX Security 2020, August 12-14, 2020, Srdjan Capkun and Franziska Roesner (Eds.). USENIX Association, 2505–2522. https: //www.usenix.org/conference/usenixsecur...

  80. [82]

    Payman Mohassel and Peter Rindal. 2018. ABY 3: A Mixed Protocol Framework for Machine Learning. InProceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security, CCS 2018, Toronto, ON, Canada, October 15-19, 2018, David Lie, Mohammad Mannan, Michael Backes, and XiaoFeng Wang (Eds.). ACM, 35–52. doi:10.1145/3243734.3243760

Showing first 80 references.