Ironman: Accelerating Oblivious Transfer Extension for Privacy-Preserving AI with Near-Memory Processing

---

Review Form

Reviewer: The Guardian (Adversarial Skeptic)

Summary

The authors propose "Ironman," a Near-Memory Processing (NMP) architecture to accelerate Oblivious Transfer Extension (OTE), a critical component in many Privacy-Preserving Machine Learning (PPML) frameworks. The proposal involves a hardware/software co-design approach: for the compute-bound Single-Point Correlated OT (SPCOT) sub-protocol, they introduce an m-ary GGM tree expansion using a ChaCha-based PRG instead of the standard AES. For the memory-bound Learning Parity with Noise (LPN) sub-protocol, they propose an NMP architecture with a memory-side cache and a pre-sorting algorithm to improve data locality. While the paper identifies the correct bottlenecks, its central claims are predicated on a number of strong, and in some cases, unrealistic, hardware assumptions, and the reported performance gains appear to be misleadingly framed.

Strengths

1. The fundamental diagnosis of the performance bottlenecks in PCG-style OTE is sound. The identification of SPCOT as compute-bound and LPN as memory-bandwidth-bound (Section 1, page 2, Figure 1(c)) correctly motivates the need for distinct optimization strategies.
2. The algorithmic optimization for SPCOT, specifically the combination of m-ary tree expansion with a ChaCha8-based PRG, is a logical approach to reducing the total number of PRG calls. The ablation study presented in Figure 13(a) (Section 6.2, page 11) provides clear evidence that this combined approach is superior to applying either optimization in isolation.
3. The proposed index sorting algorithm for the LPN phase (Section 5.3, page 9) is an intelligent technique to mitigate the performance degradation from irregular memory accesses. The use of offline, compile-time sorting for a fixed matrix is a valid optimization strategy in principle.

Weaknesses

1. Fundamentally Unrealistic Hardware Model: The entire proposal hinges on the ability to place a custom, high-throughput "ChaCha8 Core" and other specialized logic (e.g., the Unified Unit) on the buffer chip of a DRAM DIMM (Section 5.1, page 7, Figure 9). The authors themselves concede in Section 5.1.3 (page 8) that deploying this on existing commercial NMP hardware like UPMEM or HBM-PIM would present "certain challenges" and would ultimately "require replacing the existing hardware with our custom ASIC." This admission relegates the work to a purely theoretical exercise. It is not an acceleration on near-memory processing as it exists, but on a hypothetical, full-custom memory system that is not commercially viable or available.
2. Misleading Presentation of Performance Gains: The abstract and headline results prominently feature a "39.2-237.4× improvement in OT throughput." However, the end-to-end application speedup for actual PPML frameworks is a far more modest 2.1-3.4× (Table 5, Section 6.5, page 11). While solving one bottleneck to reveal another (communication) is a common outcome, framing the work around a component speedup that is orders of magnitude larger than the real-world application benefit is misleading to the reader. The true impact is much smaller than suggested.
3. Insufficiently Rigorous Baseline Comparisons: The paper compares against a "full-thread CPU implementation" and a GPU implementation. The GPU baseline, an NVIDIA A6000, is a powerful accelerator. However, its implementation is described in a single sentence (Section 6.1, page 10), lacking any detail on the level of optimization. Without evidence of a highly optimized CUDA implementation that effectively leverages GPU architecture for this specific task, the 40.31x speedup claimed over the GPU baseline is suspect and likely inflated by comparing against a strawman implementation.
4. Unsupported Claims of Negligible Overhead: The authors claim in Section 5.1.3 (page 8) that the cost of offloading data to the host CPU "becomes negligible" because generation can be overlapped with transmission. This is an oversimplification that ignores the complexities of host-device synchronization, instruction dispatch overhead, and potential bus contention. This critical system-level cost is dismissed without any quantitative analysis or simulation data to support the claim.
5. Limited Applicability of LPN Optimization: The index sorting algorithm, which is key to the LPN speedup, requires the index matrix A to be fixed and known at compile time (Section 5.3, page 9). This is a strong assumption that may not hold for all PPML scenarios or future cryptographic protocols. The paper fails to discuss the implications or performance impact if this matrix were dynamic or generated on-the-fly.

Questions to Address In Rebuttal

1. Regarding the hardware model: Can you justify the practicality of your proposed architecture? Please provide a clear pathway for implementing this design on any existing or near-future NMP platform without requiring a full-custom ASIC on the DIMM buffer chip. If no such pathway exists, the contribution must be re-framed as purely theoretical.
2. Regarding the performance claims: Please reconcile the 237.4x component speedup highlighted in the abstract with the ~3x end-to-end application speedup from Table 5. Why is the most prominent number in the paper not representative of the actual system-level impact?
3. Regarding the GPU baseline: Please provide concrete details of your GPU implementation. Specifically, what CUDA kernels were designed, how was work distributed across thread blocks, and what memory optimizations (e.g., shared memory usage, coalesced access patterns) were employed? This is necessary to validate that your comparison is fair.
4. Regarding the offloading cost: Please provide a quantitative breakdown (e.g., from your ZSim simulation) of the overhead associated with the host processor dispatching NMP instructions and receiving the final COT correlations. How does this overhead scale with the number of correlations, and under what specific conditions is it truly "negligible"?
5. Regarding the LPN sorting algorithm: Please clarify the assumptions under which the index matrix A can be considered static and sorted offline. What is the performance impact on the LPN stage if this assumption is violated and the matrix must be processed without prior sorting?

---

Review Form

Reviewer: The Synthesizer (Contextual Analyst)

Summary

This paper presents "Ironman," a specialized hardware accelerator designed to address a critical performance bottleneck in Privacy-Preserving Machine Learning (PPML): the Oblivious Transfer Extension (OTE) protocol. The authors correctly identify that as other parts of PPML frameworks are optimized, the cryptographic machinery for handling non-linear functions—which heavily relies on OTE—becomes the dominant cost.

The core contribution is a holistic hardware/software co-design. The authors cleverly partition the OTE protocol into its two main components: the computation-bound SPCOT and the memory-bound LPN. For SPCOT, they propose replacing the standard binary AES-based tree expansion with a more hardware-friendly 4-ary tree using a custom ChaCha8 core, significantly reducing the number of primitive operations. For LPN, they leverage a Near-Memory Processing (NMP) architecture with memory-side caches and a novel offline index sorting algorithm to mitigate the performance degradation from LPN's irregular memory access patterns. The design is thoughtfully unified to support the switching of sender/receiver roles inherent in many MPC protocols. The simulation-based results demonstrate a substantial 39x-237x speedup for the OTE protocol itself and a compelling 2.1x-3.4x end-to-end latency reduction for complex CNN and Transformer models within modern PPML frameworks.

Strengths

1. Excellent Problem Identification and Contextualization: The paper is situated at the crucial intersection of computer architecture, applied cryptography, and secure AI. The authors have correctly diagnosed that OTE is the next major frontier for optimization in making large-scale PPML practical. By profiling real frameworks (Figure 1, page 2), they provide strong motivation that this is not a theoretical problem, but a real-world engineering challenge for the deployment of private AI.

2. Sophisticated HW/SW Co-Design: This is the paper's most significant strength. Rather than naively accelerating the canonical OTE algorithm, the authors re-evaluate the algorithmic components from first principles with hardware in mind. The decision to move from a standard binary GGM tree with AES to a 4-ary tree with a custom ChaCha8 primitive (Section 4, page 6) is an outstanding example of co-design. It showcases a deep understanding of both the cryptographic requirements and the hardware implementation trade-offs, leading to a 6x performance improvement for the SPCOT component (Figure 13, page 11).

3. Sound and Modern Architectural Approach: The use of Near-Memory Processing (NMP) for the memory-bound LPN component is a well-justified and modern architectural choice. The design insight that LPN's random access patterns can be regularized via offline sorting (Section 5.3, page 9) and serviced efficiently by distributed memory-side caches and rank-level parallelism is very compelling. This correctly maps the problem's characteristics (low compute intensity, high memory bandwidth demand) to an appropriate architectural solution.

4. Enabling Practical Private AI for Complex Models: By achieving significant end-to-end speedups, this work pushes the boundary of what is considered feasible for PPML. The evaluation on large Transformer models (ViT, BERT, GPT-2) is particularly important, as these models are often considered prohibitively expensive to run in a secure context. This work provides a credible pathway to deploying such state-of-the-art models with strong privacy guarantees.

Weaknesses

While the core ideas are strong, the paper could be improved by addressing the following points, which are more about completeness than fundamental flaws:

1. Positioning of Novelty: The paper's novelty lies in the synthesis and application of existing ideas to a new, important domain. NMP, custom cryptographic cores, and index sorting for sparse operations are established techniques. The paper would be stronger if it more explicitly framed its contribution not as the invention of these components, but as the first successful synthesis of them into a coherent accelerator for the PCG-style OTE bottleneck.

2. Practicality of NMP Integration: The paper relies on a simulated NMP environment. While this is standard for architectural research, a brief discussion on the practical path to deployment would be valuable. For instance, what modifications would be needed in the OS/memory controller to manage the NMP units? How would the Ironman software stack integrate with existing PPML frameworks like PyTorch or TensorFlow, which are often the front-ends for these secure back-ends?

3. Overhead of Offline Pre-processing: The index sorting algorithm for LPN is performed offline. The paper states this cost is amortized because the LPN matrix is fixed. While true for many inference scenarios, it would be useful to quantify this one-time cost. Furthermore, a discussion on scenarios where the matrix might not be fixed (e.g., certain types of secure training or dynamic systems) would add nuance and scope the applicability of this specific optimization.

Questions to Address In Rebuttal

I am broadly supportive of this work and believe it makes a valuable contribution. I encourage the authors to use the rebuttal to address the following to strengthen the final paper:

1. Regarding the LPN optimization (Section 5.3, page 9): Could you quantify the one-time computational cost of the offline column and row sorting algorithm? How does this cost scale with the size of the LPN matrix, and at what point might it become a consideration in the overall workflow?

2. Regarding the architectural scalability: Your evaluation shows strong scaling up to 16 ranks. As you scale to a larger number of DIMMs/ranks, do you foresee the final XOR reduction in the DIMM-NMP module (Figure 9b, page 8) becoming a new bottleneck, and if so, how might your design address this?

3. Regarding the algorithmic co-design (Section 4.1, page 6): You make a compelling case for using a 4-ary tree with ChaCha8. Could you provide a little more architectural insight into why ChaCha8 is so well-suited for a pipelined hardware implementation compared to, for example, a pipelined AES implementation? Is it primarily the longer output, or are there also advantages in the simplicity of its core operations (Add-Rotate-XOR) that lead to a more area- or power-efficient pipeline?

Review Form

Reviewer: The Innovator (Novelty Specialist)

Summary

The paper presents "Ironman," a hardware accelerator architecture for PCG-style Oblivious Transfer Extension (OTE), targeting the performance bottleneck in modern Privacy-Preserving Machine Learning (PPML) frameworks. The authors identify two key components of OTE: the computation-bound Single-Point Correlated OT (SPCOT) and the memory-bandwidth-bound Learning Parity with Noise (LPN). To address these, they propose a two-pronged solution: 1) a novel "hardware-aware" m-ary GGM tree expansion algorithm for SPCOT that uses a ChaCha-based PRG instead of AES, and 2) a Near-Memory Processing (NMP) architecture with an index sorting algorithm to improve data locality for LPN.

My primary concern is the degree of conceptual novelty. While the paper claims to be the first customized accelerator for PCG-style OTE, which appears to be true, the underlying techniques employed are largely adaptations of well-known principles from other domains. The primary contribution is therefore the synthesis and application of these existing ideas to a new problem, rather than the invention of fundamentally new architectural or algorithmic concepts.

Strengths

1. First-Mover on a Relevant Problem: To the best of my knowledge, this is the first work to propose a dedicated, end-to-end hardware architecture for accelerating PCG-style OTE. Previous work on OT acceleration (e.g., POTA [94]) has focused on other variants like IKNP-style OT, which have different performance characteristics. Identifying and targeting this specific, computationally intensive protocol is a timely contribution.

2. Hardware/Algorithm Co-Design for SPCOT: The most novel element of this work is the proposed co-design for SPCOT in Section 4 (Page 6). The idea of replacing the standard 2-ary AES-based GGM tree with an m-ary ChaCha-based tree is a clever, hardware-centric optimization. While m-ary trees have been explored for V-OLE [88], the explicit analysis and motivation for coupling this with a specific, hardware-friendly PRG like ChaCha8 to reduce operator count and improve area/power efficiency (Table 2, Page 5) constitutes a legitimate, albeit specialized, engineering novelty.

Weaknesses

1. Limited Conceptual Novelty in LPN Acceleration: The proposed solution for the memory-bound LPN component lacks fundamental novelty. The core ideas are:

   • Applying NMP: Using Near-Memory Processing to accelerate a memory-bandwidth-bound problem with low computational intensity is the foundational premise of NMP research. The application here is a straightforward, albeit effective, use case. It does not introduce a new NMP paradigm.
   • Index Sorting: The "Index Sorting Algorithm for Memory-side Cache" described in Section 5.3 (Page 9) is conceptually identical to decades of work on improving data locality for Sparse Matrix-Vector Multiplication (SpMV). The authors themselves formulate LPN as an SpMV problem. Techniques such as column and row reordering to cluster non-zero elements and improve cache utilization are standard practice in the high-performance computing (HPC) and compiler communities. The application to LPN is new, but the technique itself is not.

2. "Unified Architecture" is Standard Design Practice: The claim of novelty for a unified architecture supporting both sender and receiver roles (Section 5.2, Page 8) is overstated. Designing a datapath with shared resources (like an XOR tree) that can be reconfigured through control logic to perform slightly different but related functions is a standard, fundamental principle of efficient hardware design to minimize area. While a necessary feature for a practical implementation, it does not constitute a novel research contribution.

3. The "Delta" is Primarily Application-Specific: The paper's main strength—being the first accelerator for PCG-style OTE—is also the source of its weakness from a novelty perspective. The contributions are highly specific to this protocol. The core takeaways for a general hardware architect are "use NMP for memory-bound problems" and "reorder memory accesses to improve locality," both of which are already known. The paper does an excellent job of system integration and engineering, but the set of new, generalizable concepts is small.

Questions to Address In Rebuttal

The authors should focus their rebuttal on clarifying the conceptual advances beyond the direct application to PCG-style OTE.

1. On LPN Acceleration: The authors frame the LPN operation as an SpMV problem (Section 5.3, Page 9). Please explicitly differentiate your proposed "Column Swapping + Row Looking-ahead" sorting algorithm from existing graph partitioning or matrix reordering algorithms used to optimize SpMV performance in the HPC domain. What is fundamentally new about your sorting approach that is uniquely tailored to the structure of LPN and not just an application of a known technique?

2. On Conceptual Contribution: Beyond being the first architecture for this specific task, what is the single most important conceptual and generalizable contribution of this work? Is there a new principle of cryptographic acceleration or NMP design that a future architect, working on a different protocol, could learn and apply from this paper?

3. On the "Hardware-Aware" m-ary Tree: The co-design of the m-ary tree with ChaCha is presented as a key contribution. Could the authors elaborate on whether this principle is more profound than a simple substitution of a more parallelizable PRG? For instance, does the structure of the ChaCha output influence the optimal choice of m in a way that would not apply to other long-output PRGs? This would help solidify the "co-design" aspect as more than just a component swap.