Rosemary: Efficient and Adaptable In-Storage Acceleration for Fully Homomorphic Encryption

Introduction

As data storage and computation increasingly move to the cloud, preserving data privacy has become critical [49, 66]. Regulations [1, 55] further mandate strong privacy protection. Fully Homomorphic Encryption (FHE) [12, 13, 19] addresses this need by enabling computation on encrypted data without decryption. FHE is especially valuable for privacy-sensitive cloud applications such as deep learning inference, database analytics, and information retrieval.

However, existing FHE schemes suffer from prohibitive performance overhead. With highly customized FHE libraries [4, 16, 48], computations are still $10^{4}\times$ to $10^{5}\times$ slower than their unencrypted counterparts on CPUs [57]. Fortunately, recent advances in ASIC accelerators [30, 28] have dramatically improved the performance of FHE, which has narrowed the performance gap between FHE operations and their unencrypted counterparts to 2–4 orders of magnitude (e.g., [35, 57]). Previous studies also demonstrated 2-3 orders of magnitude speedup on GPUs [23, 32, 61, 3] compared to CPU implementations.

Despite those advances, adopting FHE acceleration in real systems remains limited by system-level bottlenecks, where the enormous cost of data movement and heavy computational demands severely restrict achievable performance and scalability. Depending on the parameter configuration, ciphertexts may expand to $10^{3}\times$ to $10^{5}\times$ compared to the size of their corresponding plaintext version [72, 17, 34]. Consequently, the memory footprints of FHE workloads frequently reach hundreds of gigabytes or even terabytes, far exceeding typical main memory capacity. For example, FHE-enabled deep learning inference can require model weights up to hundreds of terabytes [42, 40, 31], while data-intensive workloads, such as database search [8, 46] and information retrieval [6, 65], may operate on datasets of even larger size.

Given the excessive memory footprint, naively connecting the host-side FHE accelerators with large memory to SSD (Figure 1(a)), leads to a significant system bus bottleneck for I/O bound FHE computations. Prior work [17, 44] and our analysis in Section III-A demonstrate 57% to 85% I/O overhead for overall execution time on CPU/GPU/ASIC systems. Motivated by this observation, in-storage-processing (ISP), which moves computation closer to storage, presents a promising approach. Several prior works have explored ISPs to accelerate FHE workloads [17, 44, 34, 65]. However, these works primarily adopt an ISP-only approach (Figure 1(b)), where the limited compute and memory resources within SSDs hinder the adoption of such accelerators to support FHE with large parameter sizes and complex operation patterns. As a result, existing designs either accelerate only lightweight FHE programs [17, 44, 34, 65], or deliver sub-optimal performance [69]. CIPHERMATCH [34] targets exact string matching, while INSPIRE [44] and SmartPIR [17] leverage in-storage PIR (Private Information Retrieval). Although Poseidon-NDP [69] supports general FHE, its FPGAbased design requires over 1000s even for shallow MNIST inference, far behind ASIC accelerators. Consequently, ISP-only designs are largely limited to lightweight or specialized FHE workloads, while ASIC-only accelerators continue to suffer from high storage data-movement overheads, hindering efficient support for large-scale end-to-end FHE applications.

Our goal in this work is to architect an efficient and adaptable FHE acceleration system to tackle the computation and I/O challenges of large-scale privacy-preserving applications by exploiting heterogeneous computing with a novel in-storage processing accelerator integrated in host-side ASIC-accelerated FHE systems (Figure 1(c)). To achieve our goal of efficiently integrating ISP into a full-stack FHE system, we propose Rosemary, which addresses challenges stemming from the hardware properties of FHE and the architectural characteristics of the storage devices via hardware-software co-design. First, we propose a high-performance ISP architecture with novel hardware components for accelerating general FHE operations in storage, including (i) reconfigurable FHE processing units for cost-effective processing of various kernels and (ii) a hierarchical on-chip buffer architecture for ciphertext and key management. Second, for the heterogeneous system, Rosemary incorporates compiler-driven optimizations to identify HE computations suitable for in-storage execution, partition workloads across the host and SSD, and optimize ciphertext and key movement for efficient heterogeneous execution. The key contributions of this work are as follows:

• We propose Rosemary, an efficient, cost-effective, and adaptable heterogeneous FHE acceleration system that exploits ISP for I/O challenges of large-scale applications.

• Rosemary introduces coordinated compilation innovations, including the Throughput-Data-Aware Program Allocator (TDAP) for heterogeneous partitioning across the host and SSD, and the Compiler-Level Ciphertext-Aware Optimizer (CLCAO) for memory optimizations.

• We conduct workload characterization over FHE workloads and comprehensive design space explorations to derive new insights into I/O-compute tradeoffs. These insights motivate the key architectural choices in RosemarySSD, enabling ISP-friendly execution and improved exploitation of SSD-internal parallelism.

• Our evaluation shows that Rosemary delivers geometric-mean speedups of 185.7× over state-of-the-art CPU/GPU implementations and 3.7× over prior FHE accelerators [72]. It also improves energy efficiency by up to 3.9× and reduces EDAP by up to 16.5×.

Background

Fully Homomorphic Encryption

FHE Basics

1. FHE Basics: Modern FHE schemes include CKKS [19, 21], BGV [13], BFV [12], and GSW [29]. We mainly focus on CKKS for its wide popularity. CKKS is built on the ring learning-with-errors (RLWE) problem over the polynomial ring $R_Q = \mathbb{Z}_Q[X]/(X^N+1)$, where $N$ is the ring dimension and $Q$ is the ciphertext modulus. A vector of raw data is first encoded into a polynomial $m \in R_Q$, then encrypted under secret key $s$ with small error $e$ by sampling uniform

random polynomial $a$ and setting $b=-as+m+e$, producing ciphertext $\mathrm{ct}$:

A function $f(\cdot)$ can be homomorphically evaluated directly on the ciphertext without decryption. Such evaluation is expressed as a sequence of HE operations, including ciphertext-ciphertext and ciphertext-plaintext addition/multiplication (HAdd/HMult/PMult) and ciphertext slot rotations (HRot). To efficiently support large integers, CKKS uses residue number system (RNS) to represent $Q=\prod_{i=0}^{L-1}q_i$ as a product of $L$ word-sized primes, decomposing a degree-$N$ polynomial into an $L \times N$ layout, where each row is a limb associated with prime $q_i$ and can be viewed as a polynomial.

Main Functions of CKKS

2. Main Functions of CKKS: Homomorphic operations are modular arithmetic on ciphertext polynomials. HAdd and PMult use modular element-wise operations, HRot applies an automorphism that maps coefficient $i$ to $ik \bmod N$, corresponding to cyclic slot rotations, and HMult uses modular multiplication and addition. To accelerate polynomial multiplication in $R_Q$, CKKS uses the NTT, which converts RNS limbs to the evaluation domain so negacyclic convolution becomes coefficient-wise multiplication, reducing complexity from $O(N^2)$ to $O(N \log N)$ [25, 26]. The iNTT converts results back only when coefficient-domain access is needed.

HMult and HRot change the secret key of the result ciphertext, so CKKS invokes key switching to restore the original key. This uses a large evaluation key, often hundreds of MB [2], $\mathrm{evk} \in R_{P Q}^{2 \times d_{\mathrm{num}}}$, where $P$ is an auxiliary modulus and $d_{\mathrm{num}}=\left\lceil\frac{L}{K}\right\rceil\ge1$ is the decomposition number. In RNS form, the evaluation key consists of $d_{\mathrm{num}}$ decomposition components, each containing a pair of $(L+K)\times N$ matrices. Key switching also requires base conversion (BConv) to match moduli. BConv mainly performs a matrix-matrix multiplication between an input polynomial and a fixed $K \times L$ base table, but it requires coefficient-wise representation. As a result, iNTT $\rightarrow$ BConv $\rightarrow$ NTT is a common sequence in key switching and requires coefficient-wise access to the full polynomial. To sustain an unbounded multiplicative budget, FHE uses bootstrapping to refresh the accumulated noise budget from computations and restore depth. However, bootstrapping is very expensive, dominated by a sequence of NTT/iNTT transforms and repeated keyswitching [11, 20].

In-Storage Processing

SSD Basics

1. SSD Basics: A NAND flash-based SSD comprises a controller, host interface, on-device DRAM, and multiple flash channels connected to NAND dies. The controller manages the overall system, while a Direct Memory Access (DMA) engine supports high-throughput host-SSD transfers. An embedded processor runs firmware for Flash Translation Layer (FTL), including logical-to-physical (L2P) address translation and garbage collection [52]. To access flash efficiently, the SSD employs multiple per-channel flash controllers so that channels can operate in parallel and provide high aggregate bandwidth.

ISP Architecture

2) ISP Architecture: In-Storage Processing (ISP) reduces memory-hierarchy bottlenecks by moving data-intensive computation closer to storage. By integrating compute units within the SSD controller or near-chip/die, ISP exploits the SSD’s internal bandwidth and parallelism to reduce host-memory pressure and data movement. Prior non-FHE ISP designs have used programmable logic [64, 41, 17] or specialized hardware accelerators [27, 68, 67] to accelerate I/O-bound workloads such as bioinformatics, retrieval-augmented generation, graph neural networks, and databases.

Motivation

I/O Overhead Analysis

FHE drastically increases memory demand due to slot-based encoding and encryption, while FHE computation continues to accelerate, targeting on bridging the gap with unencrypted counterparts. The $10^{3}$–$10^{5} \times$ memory overhead therefore makes data movement a dominant bottleneck. This growing imbalance motivates an FHE architecture to mitigate I/O constraints. Figure 2(a) breaks down ResNet inference latency into computation and SSD I/O based on our FHE accelerator performance model with a cold-start HBM. In a host-accelerator-only baseline, SSD accesses account for about 70% of execution time for inference with unencrypted weights and 75% for inference with encrypted weights. Prior studies also report substantial I/O overheads, reaching 57% and 85% in CPU- and GPU-based systems [44, 17]. FHE inference quickly exceeds main-memory capacity. Existing FHE inference systems require up to 512GB RAM due to hundreds of GBs of data, while BERT-Base and Llama3-8B can demand about 1.5TB and 112TB, respectively [42, 40, 31, 71]. Even optimized LLM weights alone can occupy 982GB [31], making storage I/O the scalability bottleneck.

Limitations of Prior Approaches

Table I highlights the trade-offs for prior FHE accelerators. Host-accelerators support general workloads and large parameters but incur high data-movement overhead when ciphertexts exceed main memory [35, 72, 57]. Scale-out systems provide greater compute and memory capacity, yet still suffer substantial inter-device I/O [70, 30]. ISP accelerators reduce data movement but mainly target lightweight workloads and smaller parameters (e.g., $N = 2^{13}$ to $2^{14}$) [44, 17, 65]. Rosemary bridges these approaches through heterogeneous execution that balances compute capability and I/O efficiency.

Heterogeneous Computing with ISP for FHE

To overcome the scalability and generality limitations of prior FHE ISP-only accelerators, Rosemary adopts a heterogeneous architecture that jointly exploits ISP resources and host-side accelerators. ISP is beneficial when its computation fits within the SSD’s critical I/O path. Specifically, with $b$ parallel flash channels, NAND-read latency $t$ cycles, page size $p$ bytes, per-operation latency $n$ cycles, and ciphertext size $cipher_{size}$, the maximum number of in-storage operations that can be hidden by I/O is approximately $\frac{cipher_{size} \times t}{b \times p \times n}$.

Figure 3 gives an example of how heterogeneous processing can benefit a FHE vectorized database search workload. This example queries for a cat candidate younger than 3 years old, preferably a Ragdoll, from a vectorized database with $n$ entries. HE comparison [10, 8], HE gate [10], and HE inner product/HE distance [71, 33] are offloaded to the ISP because they involve intensive direct access to the encrypted database and have shallow multiplicative depth. HE sorting [46, 10] remains on the host due to its deep multiplicative depth, frequent rotations, and potential need for multiple bootstrappings. The identified indices and distance scores are returned to the host for sorting, and the sorted results are then sent back to the SSD for final retrieval from the encrypted database. In summary, ISP reduces data movement

Approach	Low I/O	Large $N$	General	Trade-offs
Host-Accel [35, 72]	$\times$	$\checkmark$	$\checkmark$	High compute throughput, but high data movement.
ISP-only [44, 17, 65]	$\checkmark$	$\times$	$\times$	Low data movement, but limited compute capability.
Scale-out [70, 30]	$\times$	$\checkmark$	$\checkmark$	Increased parallelism and aggregated memory, but persistent I/O overhead.
Rosemary (this work)	$\checkmark$	$\checkmark$	$\checkmark$	Balanced compute and I/O through heterogeneous execution.

by computing near storage, but supporting general-purpose FHE remains challenging under SSD resource constraints.

Rosemary Design

Rosemary is an efficient heterogeneous ISP system that supports broad FHE parameters and end-to-end applications. However, building such a system presents both hardware and software challenges. On the hardware side, the host provides abundant compute resources but is constrained by storage I/O bandwidth and memory capacity. SSDs, in contrast, operate closer to the data but offer limited logic and buffering resources and must accommodate flash-specific constraints such as page-granularity access. These limitations complicate support for diverse FHE operators and parameters, particularly because FHE polynomials can occupy several MBs. On the software side, the system must determine when ISP offloading is beneficial, coordinate execution between the host and SSD, and maintain generality across workloads. Rosemary addresses these challenges through hardware–software co-design, combining a Rosemary SSD architecture with algorithmic and compiler optimizations to integrate a cost-effective ISP accelerator into a heterogeneous execution flow.

Rosemary System

Figure 4 presents an overview of Rosemary system. Rosemary integrates an ISP-enabled SSD, RosemarySSD, with a high-performance host-side accelerator, FHE Accel ❷, to reduce host–SSD data movement while preserving execution flexibility and throughput without overburdening SSD resources. RosemaryHost consists of Host CPU, FHE Accel, and RosemaryCompiler ❶. At compile time, RosemaryCompiler statically analyzes the FHE program and uses the Throughput-Data-Aware Program Allocator (TDAP, Section VI-B) to partition operations between FHE Accel and RosemarySSD. It then generates the instructions required for end-to-end execution and orchestrates the heterogeneous system. At runtime, the host follows the precomputed allocation to manage data transfers and issue execution commands over PCIe.

When RosemaryHost receives the user query ciphertexts, Host CPU issues ciphertext requests ❶ and the precompiled mProgram (Section VII-A) to invoke SSD-Segment Execution of the ciphertext-heavy and data-movement-intensive program segments on the Rosemary Engine ❸ within the controller. During this SSD-Segment Execution, the SSD concurrently reads required FHE polynomials from the NAND flash backend across all channels ❸ and returns the processed ciphertexts (intermediate) results ❹ to FHE Accel in

RosemaryHost for the compute-and-memory-bound segments that demand high on-chip throughput. This design embeds specialized FHE support within a commodity SSD controller, whose detailed architecture is described in Section V. Through hardware-software co-design and heterogeneous execution, Rosemary efficiently supports diverse FHE workloads across a wide range of parameter settings.

RosemarySSD

RosemarySSD is the SSD-side architecture that enables efficient FHE execution within the heterogeneous Rosemary system. RosemarySSD extends a commodity SSD controller with four key components: ❶ an FHE Engine, ❷ a scratchpad eDRAM, ❸ a heProgram Dispatcher, and ❹ the Rosemary FTL. It is designed to address three core challenges: (1) tight resource constraints in a low-power, high-capacity SSD, (2) adaptability across diverse FHE parameter settings and workloads, and (3) limited off-chip DDR DRAM bandwidth.

FHE Engine Architecture

Rosemary engine centers on a 2D array of Adaptive Units (AUs), shown in Figure 5, that unifies the dominant FHE kernels on a single reconfigurable datapath. Specifically, each AU contains multiple lanes of butterfly units [9] and modular adders and multipliers. During execution, FHE polynomials are distributed across the lanes of all processing elements (PEs). When the polynomial size exceeds the total lane count, coefficients are streamed through the same lanes over multiple rounds. To reduce SRAM port pressure, Rosemary forwards intermediate data across processing units through vector chaining [57, 56, 18], improving locality while sustaining throughput. Because Rosemary implements arithmetic primitives shared across major FHE schemes, its architecture can be extended to support schemes beyond CKKS with limited scheme-specific modifications.

A key advantage of the AU-based design is that it avoids kernel-specific logic and datapaths while remaining adaptable across FHE parameter and workload settings. Prior accelerators often employ dedicated base-conversion (BConv) units for key switching [35, 72]. In contrast, Rosemary reuses the (i)NTT datapath, whose modular MAC, addition, and multiplication operators already support BConv. This sharing is

efficient because BConv typically executes sequentially within the $iNTT$-$BConv$-$NTT$ pipeline rather than concurrently with (i)NTT. Through lightweight multiplexing, the same arithmetic units can also operate as element-wise modular adders or multipliers, efficiently supporting shallower workloads with different operation mixes. This flexibility is particularly valuable for information-retrieval workloads such as PIR [6, 65], which often have a higher proportion of element-wise operations than key-switching-intensive workloads.

Rosemary centralizes the AU array in a single SSD-level FHE engine instead of distributing smaller accelerators across flash channels. This organization better matches SSD access granularity and FHE execution characteristics. NAND accesses are page-granular, whereas FHE polynomials are substantially larger (e.g., 256 KB) and span many pages and channels. A centralized engine can gather pages from all flash channels without cross-engine coordination, which is particularly important for kernels such as key switching, where the $\mathit{Decompose} \rightarrow iNTT \rightarrow BConv \rightarrow NTT$ sequence operates over the full ciphertext. In contrast, per-channel engines fragment the datapath, create load imbalance, and require costly replication of buffers and arithmetic units. Centralization also enables buffering. A centralized engine can buffer the $\alpha$ limbs from $\mathit{Decompose}$ and generate the remaining $\mathit{ModUp}$ limbs entirely on chip [2]. Section VI-C describes the limb-aware data layout.

To keep AU design under the area and power budgets of the SSD-controller, Rosemary adopts Geometry-Constant NTT (GC-NTT) [54] to reduce permutation complexity. The remaining permutations are decomposed across the 2D PE array into x-axis switching (xshuffle), y-axis shuffling (yshuffle), and intra-PE shuffling (rshuffle) [47], implemented by the X/Y-Switch interconnects. Since all PEs can perform these transfers independently at each shuffle step, Rosemary pipelines them across NTT operations to sustain throughput. We support automorphism over the same 2D interconnect [72], use an HE-friendly modular multiplier [53], generate twiddle factors on the fly, and store only half of each KSK while regenerating the pseudo-random half with a PRNG [57, 29, 9].

RosemarySSD Memory

RosemarySSD uses a four-level memory hierarchy to keep hot data near the AU array and minimize off-chip accesses, as shown in Figure 5. Each AU uses a local 1R1W RegFile for operands and partial sums, while a shared 32MB SRAM buffers intermediate polynomials. The 256–512MB SRAM capacities used in prior accelerators [35, 72] are impractical for an SSD controller.

However, during key switching, a small SRAM buffer forces tens of MB of KSK data to stream from off-chip memory, making performance highly sensitive to the limited DDR bandwidth of SSDs Figure 6.

Rosemary therefore adds a 64MB, 8-bank eDRAM scratchpad directly accessible by the AU array. SRAM buffers active intermediates, while eDRAM retains hot keys and overflow data, reducing off-chip accesses and NAND write-backs. In this hierarchy, SRAM serves as a fine-grained buffer for active intermediates, while eDRAM provides a larger storage layer for hot keys and overflow data that cannot fit in SRAM. eDRAM offers substantially higher density and lower cost under SSD power and thermal constraints, making large-capacity on-chip storage practical inside the controller. eDRAM refresh overhead is negligible for long-running FHE kernels: its $10^{-3}$-cycle retention time and approximately 34-cycle parallel refresh latency can be hidden by computation [43]. Its refresh energy also remains substantially lower than that of an equivalently sized SRAM.

Rosemary Dataflow

Figure 7 illustrates the RosemarySSD dataflow using key switching as an example. Before key switching, the input ciphertext from RosemaryHost is stored in LPDDR and fed to the FHE engine, while the large FHE dataset is streamed from NAND flash into the eDRAM scratchpad through the flash channels. After earlier HE operations and scaling, the ciphertext enters the key-switching flow, which begins with decomposition and modulus raising (ModUp). Decomposition expands the original $l$ polynomials into $\beta$ digits, each containing $\alpha$ polynomials, and the resulting intermediate polynomials are buffered in SRAM. The engine then executes the KSK inner-product step, where the much larger evaluation keys (KSKs) are supplied directly from the on-chip eDRAM scratchpad. If the required KSK is not resident in eDRAM, RosemarySSD fetches it from LPDDR DRAM. If it is also absent there, it is retrieved from NAND flash. When SRAM capacity is exceeded, intermediate polynomials overflow first into eDRAM, and further spill into LPDDR only if eDRAM capacity is exhausted. In this design, SRAM serves as a fine-grained intra-operation buffer, while eDRAM holds larger hot keys and streamed operands, allowing the AU array to sustain throughput without being throttled by off-chip bandwidth. This hierarchy keeps frequently reused keys and intermediates close to the 2D AU array, reducing repeated off-chip accesses across the $iNTT$-$BConv$-$NTT$ sequence.

Compilation and Optimization

To fully exploit Rosemary’s heterogeneous architecture, we propose a hardware-aware compilation flow that maps FHE

programs across the execution platform. Figure 8 shows the overview of the proposed compilation stack, where the input to this flow is a weighted DAG representation of the FHE program. Specifically, each node corresponds to an FHE primitive operation (e.g., $HMult$, $HAdd$, $Boot$), where the node weight captures the computational cost under the corresponding FHE parameters (e.g., ring dimension $N$, modulus $\lvert q\rvert$, and depth $l$). Each edge represents ciphertext data dependencies, and its weight corresponds to the input or output ciphertext size in bytes. The architecture configuration of Rosemary is taken as an input for the compiler, which is used to statically estimate the execution latency and resource usage of each HE operation, enabling static scheduling given the regularity of FHE.

A Compiler-Level Ciphertext-Aware Optimizer (CLCAO) then applies optimization passes to convert operations in FHE DAG into ISP-friendly kernels and computation flows to improve the efficiency of execution using restricted ISP hardware resources. Then, a Throughput-Data-Aware Program Allocator (TDAP) optimizes the computation partition across the host-side FHE Accel and RosemarySSD using a cost model that captures compute throughput, memory capacity, and data-movement overheads. Finally, the backend generates the corresponding execution formats, including mPrograms for RosemarySSD and APIs for the communication between host and SSD to enable seamless cooperative execution across the heterogeneous FHE system.

Ciphertext-Aware Optimizer

Rosemary incorporates a Compiler-Level Ciphertext-Aware Optimizer (CLCAO) that reduces data movement from off-chip LPDDR to ISP processing logic through two memory-capacity- and bandwidth-aware optimizations for FHE kernels and computation flows. The first optimization is rotation-key decomposition. While Rosemary uses its SRAM-eDRAM hierarchy to keep hot data close to the AU array, the working set of rotation keys (i.e., KSK in Figure 7) can still exceed on-chip capacity, creating LPDDR bandwidth pressure that lowers throughput. CLCAO therefore analyzes the required rotation set, $\mathcal{R}$, and removes keys through rotation decomposition. Specifically, it decomposes a rotation $r$ into a short chain of $r=s_1+s_2+\cdots+s_k$ rotations using hot keys $s_1,\ldots,s_k$, which are already in eDRAM. This reduces the number of distinct rotation keys for the active working set. The decomposition is applied only when the key read cost exceeds the added compute cost, when $\tau_{\mathrm{key}}>m\cdot\tau_{\mathrm{rot}}$, where $\tau_{\mathrm{key}}$ is the latency of reading the additional rotation key, $\tau_{\mathrm{rot}}$ is the latency of one additional $rot\_relin$, and $m$ is the number of extra rotation steps introduced by the decomposition.

Another optimization is static ciphertext placement and scheduling, which exploits the regular structure of FHE programs to determine data placement and execution order ahead of time. Because encrypted data cannot directly drive data-dependent control flow, FHE workloads are typically static with fixed execution structure. CLCAO therefore performs compile-time liveness analysis to track ciphertext production, reuse, and lifetime, assigning each live ciphertext a cost of evicting and reloading based factors such as size and level. With this cost model, CLCAO optimizes data placement and execution order to minimize expensive evictions from the SRAM-eDRAM hierarchy. For example, in vectorized database score summation, a straightforward schedule may first calculate many score ciphertexts before defer accumulation, increasing memory pressure and causing short-lived intermediates to spill to LPDDR. CLCAO instead performs partial reductions earlier, consuming scores closer to their production time. This shortens their live ranges, reduces costly spills, and improves sustained throughput.

Program Allocator

Rosemary requires effective allocation of program segments between the host FHE Accel and RosemarySSD to jointly balance computation cost and I/O cost. However, the computation cost of each node is placement-dependent and thus unknown until the partition is fixed. We therefore leverage the Binary-Min-Cut [38] algorithm and propose the Throughput-Data-Aware Program Allocator (TDAP), which performs cost-aware heterogeneous partitioning over the weighted DAG to assigns each segment based on placement-dependent execution cost and host–SSD I/O overhead. TDAP improves end-to-end throughput by jointly considering segment execution efficiency and ciphertext I/O movement between host and SSD.

First, TDAP estimates the execution cost of each homomorphic operation on FHE Accel and RosemarySSD, as well as the associated ciphertext I/O cost:

where $T_{ij}^{\mathrm{comm}}=\frac{b_{ij}}{B_{\mathrm{PCIe}}}$, and $D_i(d)$ is the raw execution cost of operation $i$ on device $d\in\{\mathrm{Host},\mathrm{SSD}\}$, and the three terms capture arithmetic execution, ciphertext buffer, and scratchpad memory traffic, and KSK access overhead, respectively. $T_{ij}^{\mathrm{comm}}$ is the I/O cost for the edge $(i,j)$, where $b_{ij}$ is the transferred ciphertext volume and $B_{\mathrm{PCIe}}$ is the PCIe bandwidth. A caveat is that, for SSD execution, the cost of key-switching-heavy operators (e.g., $HMult$ and $HRot$) depends on whether their predecessor nodes are also placed on the SSD. For tractable static estimation, we assume predecessors are assigned to the same execution domain as the current node. Using these estimates, TDAP selects the placement $x_i \in\{\mathrm{Host}, \mathrm{SSD}\}$ with the Binary-Min-Cut [38] algorithm such that it minimizes

The first term favors the device that executes each segment more efficiently, while the second penalizes cuts across large ciphertext boundaries. As a result, TDAP optimizes end-to-end throughput at the program level rather than making isolated per-segment decisions. To ensure tractable partitioning, we follow the regularized graph-construction constraints in [38], which avoid an NP-hard formulation. Specifically, all weights are required to be positive, and we assume $D_i(\mathrm{SSD}) \ge D_i(\mathrm{Host})$, reflecting the fact that the SSD is less powerful than the host due to power budget constraints. TDAP performs node-level placement over the FHE DAG, allowing multiple host and SSD subgraphs. Consecutive operators mapped to the same domain are coalesced into an $mProgram$, while cross-domain dependencies incur ciphertext-transfer costs, discouraging excessive host–SSD switching.

FHE-Friendly Interleaving and FTL

The data layout within the SSD has a substantial impact on SSD channel bandwidth utilization. Since FHE ciphertexts are large RNS objects, even a single polynomial/RNS limb can span multiple SSD pages. Rosemary therefore interleaves the pages of each limb across multiple channels, enabling the FHE engine to leverage aggregated internal channel bandwidth during processing, as shown in Figure 8. Specifically, FHE ciphertexts and evaluation keys are initially written through the normal NVMe and FTL path. During pre-computation stage, each FHE object are written according to the channel-interleaved layout through API commands (Section VII and publishes its object descriptor only after all object pages and metadata have been persisted. An update is written out of place as a new immutable object generation and is relayed out before use. After the new generation is complete, the controller atomically changes the active descriptor, and the old generation becomes reclaimable through normal garbage collection. Rosemary therefore does not support in-place modification of an object generation while it is being processed.

The regularity of Rosemary’s data layout also simplifies FTL metadata. Because each polynomial limb is distributed across channels evenly, the controller does not need page-granularity L2P entries. Instead, it only stores a compact object descriptor and derives page locations analytically from the base address and interleaving pattern. For example, with $N = 65536$ and 4-byte coefficients, 16 KiB SSD pages, a ciphertext with two polynomials and $L = 30$ limbs occupies 15MB, or 960 pages. Under a conventional page-level FTL with 4-byte entries, this requires $\approx3.75$KB of metadata. In contrast, Rosemary only needs a small descriptor, e.g., two 4-byte base addresses for the two polynomials with a few bytes for the limb count and layout rule, for a total of 16B per ciphertext. Thus, Rosemary reduces metadata from about 3.75 KB to only 16 B per ciphertext, about $240\times$, while still enabling full internal channel-bandwidth utilization. Prior works also leverage customized FTL approaches to release DRAM capacity [27, 67, 68].

System Support

End-to-End System Design

To enable end-to-end heterogeneous FHE execution, Rosemary defines a host-RosemarySSD communication API, together with $mProgram$, an instruction interface for the ISP FHE engine. Rosemary exposes a uniform API (Table II) to enable input and intermediate ciphertext communication between the host and RosemarySSD. This API is tightly coupled with our heterogeneous compilation flow. After the compiler selects segments offloaded to SSD and generates their corresponding $mProgram$, the runtime uses these commands to transfer ciphertexts and trigger execution on the ISP FHE engine. Thus, the API bridges compiler-driven partitioning and end-to-end heterogeneous execution.

Type	API	Description
Init	$Prog\_Set(op, mprog)$	Store compiled mProgram to device.
Run	$Send(ctxt, mprog)$	Send encrypted query to device.
Run	$Recv(ctxt)$	Retrieve encrypted results from device.

When the FHE program is offloaded to the SSD, we leverage the vendor-reserved ONFI [51, 59] commands to support two control primitives: $config()$, which sets FHE parameters and configures the AU array, and $init()$, which starts execution. Upon $init()$, the $heProgram$ Dispatcher (§ 5-A) drives the FHE engine according to an $mProgram$, a sequence of simple fixed-format commands summarized in Table III. Reserved ONFI commands are internal controller micro-operations generated after command validation, FTL translation, and channel scheduling; they are not exposed directly to host software. This preserves the protection and resource-management responsibilities of the conventional SSD firmware. All command fields are statically resolved by the compiler, referring only to logical NAND addresses or pre-allocated buffer/scratchpad locations. Thus, no dynamic allocation or runtime address computation is required beyond standard FTL translation. This makes $mProgram$ compact. For example, an ISP segment of Llama70B needs only 3.8MB of $mProgram$, even less than the size of a single ciphertext.

Instruction	Operands
$\{NTT, iNTT\}$	$A\_addr$, $Out\_addr$
$\{MODADD, MODMUL, MODMAC\}$	$A\_addr$, $B\_addr$, $Out\_addr$
AUTOMORPH	$A\_addr$, $rotIdx$, $Out\_addr$
$\{LD, ST\}$	$Addr$, $Type$

SSD Management and Control Tasks

Rosemary preserves the conventional SSD control plane: the NVMe frontend, embedded cores, FTL, ECC engines, GC, and NAND scheduler retain their existing roles. The FHE engine operates as a separate acceleration plane, consuming data after ECC decoding and issuing page requests through the existing FTL and flash scheduler, without involving embedded cores in FHE arithmetic or modifying NAND-channel control. Additional state is limited to the mProgram command queue, FHE configuration registers, a small object-descriptor cache, buffer-ownership state, and arbitration logic between accelerator and conventional I/O requests. Once FHE metadata is placed, Rosemary enters a dedicated ISP mode and no longer serves conventional host I/O, following prior work [34, 41, 27]. Because Rosemary only reads NAND data and does not generate NAND writes, it introduces no additional write-induced endurance overhead [14] or write-side management such as garbage collection and wear leveling [52, 27, 15].

Methodology

Hardware Implementation and System Modeling

We develop an event-driven, cycle-accurate in-house simulator based on MQSim [62]. The simulator models the latency of traditional SSD components, including embedded processor cores, SSD DRAM, and the multi-level flash backend, as well as the customized multi-level processing engines introduced in our design. The mPrograms, which encode all basic FHE operators and data-movement kernels as ISA-level commands, are used to drive our simulation. We implemented and synthesized the major logic units with a 32-bit word length at the RTL level using the ASAP7 7nm process design kit (PDK) [24] and support bootstrapping with double-scaling operations [35]. The technology node is selected based on the 8nm and 5nm technology nodes for controllers in existing commercial SSD products [63]. We provision a total of 64 MB eDRAM and 32 MB SRAM and use FinCACTI [60] to model the interconnects, register files, SRAM, and eDRAM components with the published information [45, 43]. The FHE engine is composed of $4 \times4$ AU arrays, where each AU contains 128 lanes. We model the SSD with the configuration in Table IV based on a commercial SSD design [63].

Component	Configuration
General	3D TLC NAND flash-based SSD; 4 ARM Cortex-A9 cores; NVMe 2.0
I/O	PCIe 4.0 ×4 (8 GB/s)
DRAM	4 GB LPDDR5, 51.2 GB/s
Flash Memory	16 Channels/SSD; 4 Chips/Channel; 2.4 GB/s
Flash Parameters	Page size = 32 KB; 2 Dies/Chip; 2 Planes/Die; 1024 Blocks/Plane; 1024 Pages/Block; 8-bit Channel Bus

Baselines

CPU: We evaluate open-source implementations on an AMD Ryzen Threadripper 9970X with 256GB RAM, using swap files when datasets exceed memory capacity.

Host-Accelerator (HA): Our baseline couples SSD storage with a state-of-the-art FHE accelerator [72], streaming data directly from SSD to accelerator HBM over PCIe [50] and optimistically assuming full PCIe bandwidth. To validate the model, we compare the non-SSD portion of our simulation against the original paper and find less than 8% difference.

INSPIRE: We use INSPIRE [44] as the baseline for ASIC-based FHE ISP acceleration. To ensure a faithful comparison, we validate our INSPIRE model against the original paper.

Workloads

We evaluate Rosemary on diverse FHE workloads, following state-of-the-art open-source implementations and preserving their algorithms, operator structure, bootstrapping placement, and $\ge128$-bit-secure parameters [5]. We port them into our framework as follows:

1. Private Information Retrieval (PIR): We evaluate PIR using the SmartPIR protocol [17]. We map its BFV parameters [12], $(N, T, \log Q) = (2^{13}, 2^{16} + 1218)$, to BGV with $N = 4096$ and $\log QP = 218$, supporting multiplicative depth 2. We evaluate on VCaLL ($2^{32}$ entries, 96B records), Comm ($2^{30}$, 288B), and Fsys ($2^{17}$, 10MB) [44].

2. Database (DB): We build our database benchmarks on Engorgio [10]¹ and HEVEC [8]², both CKKS-based designs with customized or quantized encoding. Rosemary supports them through its generic FHE primitive support. For Engorgio, we evaluate VQ1 and VQ2 (Section 6.3 and Appendix § 9.4 in [10]) with 10K dataset entries. The workload includes homomorphic distance, synchronization, and non-linear top-$k$ queries with bootstrapping, using parameters $L = 43$, $N = 2^{17}$, and $\log QP = 3516$. HEVEC is an HE database implementation [8] with coefficient encoding (Section 4 in [8]) with $N = 4096$ and $\log QP = 109$, evaluate it on Deep1B [7].

3. DNN Inference: This benchmark includes ResNet [40]³ on CIFAR-10. We follow the algorithmic implementation and FHE parameters in [40], consistent with prior accelerators [57, 35, 72], and evaluate both encrypted- and plaintext-weight settings.

4. LLM Inference: NEXUS [71]⁴ provides an FHE implementation optimized for dominant attention-layer kernels, including plaintext–ciphertext matrix multiplications, ciphertext–ciphertext matrix multiplications, and bootstrapping placement. We evaluate both BERT-Base and Llama3-8B.

Evaluation

Overall Performance

Speedup

1) Speedup: Figure 9 shows the performance of Rosemary, CPU, and Host-Accelerator (HA) across the FHE workloads in § 8-C. Rosemary outperforms the CPU/GPU baselines by $4.6\times$ to $3790.9\times$, achieving a GM speedup of $185.7\times$. Relative to HA, Rosemary delivers up to $5.4\times$ speedup and a GM speedup of $3.7\times$. The large spread in speedup over CPU baselines mainly arises from differences in the platforms and assumptions used in prior work. For instance, the $3790.9\times$ speedup on ResNet is partly driven by a single-threaded SEAL [16] CPU baseline. Meanwhile, gains over recent GPU-based implementations are smaller, at $2.8\times$ for BERT-Base and $1.1\times$ for Llama3-8B, as these baselines already employ strong GPU backends and incur large plaintext-weight footprints.⁵ Overall, more I/O-bound workloads benefit less from HA, which accelerates computation but not storage I/O.

Compared to HA, Rosemary provides larger gains on data-intensive workloads. For PIR, it achieves an average speedup of $4.3\times$ across VCALL, COMM, and FSYS. For the database workloads, VQ1_S and VQ2_S achieve $4.6\times$ and $3.6\times$ speedups over HA, while VQ1_L and VQ2_L see more moderate gains of around $2\times$. The smaller improvement for VQ_L comes from its higher baseline slot usage. Since each ciphertext has a fixed number of slots, Rosemary can pack fewer ciphertexts together and obtain less benefit from in-SSD reduction. VQ2 also benefits less than VQ1 because its 16-way sort is more constrained by host-side computation than the 4-way sort in VQ1. Among the database workloads, HEVEC achieves the largest speedup over HA because its coefficient-encoded inner product relies primarily on lightweight multiply-add operations while substantially reducing data movement.

For encrypted and unencrypted DNN inference, Rosemary achieves speedups of $2.95\times$ to $3.52\times$ and $3.40\times$ to $4.19\times$ compared to HA, respectively. These results show that Rosemary is not limited to retrieval-style workloads, but also provides robust improvements for model inference pipelines with substantial arithmetic and large working sets. Rosemary improves over HA by $5.37\times$ on BERT-Base and $4.09\times$ on Llama3-8B. The performance gains of Rosemary over HA arise from two main factors: (1) in-storage execution minimizes host-side I/O by reducing ciphertext transfers across the host-storage interface; and (2) heterogeneous execution exposes additional compute parallelism between the host FHE accelerator and the RosemarySSD FHE engine.

PCIe Traffic

Figure 10 compares the PCIe traffic of HA and Rosemary. Across all workloads, Rosemary reduces host–SSD data movement by a geometric mean of $2207.7\times$. The largest reductions occur for data-intensive workloads such as PIR and HEVEC, where communication dominates end-to-end execution. LLMs also show substantial reductions in weight traffic, since state-of-the-art implementations often replicate weights to lower compute complexity and accommodate rotation-heavy execution. The results for VQ1 and VQ2 are conservative because we evaluated 10K dataset entries, which is much smaller than real-world deployment scales.

Comparison with Previous ISP Design

Figure 11 compares INSPIRE [44] and Rosemary on PIR workload with various batch sizes. Overall, across all dataset and batch size combinations, INSPIRE achieves a GM speedup of $20.6\times$ over the CPU baseline, whereas Rosemary achieves a $2.7\times$ higher GM speedup than INSPIRE. Here, we re-normalize both systems under the CPU baseline. The speedups of both systems are more conservative compared to the original results in [44], as our CPU has a higher frequency and is associated with PCIe4x4 instead of PCIe3x4. We do not directly compare against SmartPIR because its reported results are obtained under a different system stack, which SmartPIR combines protocol-level and CSD-level optimizations on a commercial CSD array, including zero-skipping for variable-length entries and internal peer-to-peer communication support. Rosemary outperforms INSPIRE more significantly at larger batch sizes. The speedup grows from $2.4\times$ at batch size 8 to $3.1\times$ at batch size 32. The reason is that Rosemary sustains higher internal processing throughput and can absorb larger batches without substantial slowdown, whereas INSPIRE degrades as more queries become active because each processing engine has limited buffer capacity.

Ablation Studies

We perform an ablation study to isolate the benefits of the two main compiler optimizations in Rosemary: TDAP and CLCAO. Figure 12 compares three variants. Bare disables both optimizations, TDAP enables only heterogeneous partitioning, and TDAP+CLCAO enables both. Overall, enabling TDAP alone improves performance by a geometric mean of $1.37\times$ over Bare, and the full TDAP+CLCAO configuration improves performance by 1.75× on average, corresponding to an additional 1.28× gain over TDAP alone.

TDAP benefits more for workloads with substantial cross-device communication or sophisticated execution phases, where our baseline allocation manually hints to the compiler and assigns all non-linear FHE segments to the FHE Accel and linear segments to RosemarySSD. For example, TDAP provides 1.62× and 1.21× speedup on VQ_S and VQ_L, and 1.81× and 1.85× on BERT and LLAMA3-8B, respectively. These gains show that cost-aware placement avoids unfavorable offloadings and unnecessary host–SSD transfers. CLCAO further improves efficiency by refining the SSD-resident segments selected by TDAP. Across the evaluated workloads, the full configuration reaches up to 2.35× speedup over Bare. The additional benefit is especially large for RESNET110-EW, where CLCAO increases performance from no gain under TDAP alone to 1.84×. Without CLCAO, the convolutional matrix multiplications and weight-input HMult operations repeatedly fetch new keys and evict recently used ones. RESNET workloads see little benefit from TDAP, as the manual strategy is already well explored and tested. In contrast, for LLM workloads, the full stack achieves 2.30× speedup on BERT and 2.35× on LLAMA3-8B.

Architectural Analysis

Utilization

1. Utilization: Figure 13 shows the utilization of the host, NAND, LPDDR DRAM, and FHE engine. Overall, the high utilization of NAND or DRAM bandwidth indicates that efficient data movement and buffering are critical to end-to-end performance. For compute-light workloads such as PIR and HEVEC, NAND is the primary bottleneck, reaching 99.2% and 99.8% utilization, while FHE-engine utilization remains low at 14.8% and 7.6%, reflecting their data-dominated behavior. For DB workloads, VQ1 and VQ2 place the highest pressure on LPDDR DRAM, both reaching 98.2% utilization, with host utilization also high at 60.8% and 90.2%. Their moderate FHE-engine utilization suggests that performance is limited more by intermediate ciphertext movement than by computation. Neural-network workloads are relatively more compute-intensive. Unencrypted RESNET110 achieves the highest FHE-engine utilization at 77.3%, while encrypted RESNET110 reaches 59.9%. BERT-BASE and LLAMA3-8B still show high NAND and DRAM utilization but moderate engine utilization, indicating that weight and key movement remain a major bottleneck.

Scratchpad size

2. Scratchpad size: Increasing eDRAM improves performance by buffering more intermediate ciphertexts. Compared to the design without eDRAM, 32MB, 64MB, 96MB, and 128MB scratchpads improve performance by 1.53×, 1.66×, 1.72×, and 1.75× on average, respectively. The gain saturates beyond moderate capacities. For example, BERT already achieves 1.86× speedup at 32MB and improves only marginally to 1.89× at 128MB.

FHE engine

3. FHE engine: We further evaluate Rosemary’s sensitivity to ISP FHE-engine size by varying the number of arithmetic units (AUs). With 4, 8, 16, 32, and 64 AUs, Rosemary achieves geometric-mean speedups of 2.4×, 3.5×, 4.1×, 4.3×, and 4.3×, respectively, over the HA baseline. Performance scales substantially up to 16 AUs, but the gains diminish beyond 32 AUs as execution becomes increasingly constrained by the available NAND bandwidth and other components.

4. Scalability: Figure 16 evaluate Rosemary scalability with 16- and 64-AU engines. The Small, Medium, and Large SSDs provide 8, 16, and 32 channels at 1.8, 2.4, and 2.4 GB/s per channel, respectively, with the Large configuration reaching 76.8 GB/s aggregate bandwidth and using LPDDR6 DRAM. Smaller SSDs substantially degrade performance for both engine sizes, especially for PIR, which nearly saturates NAND bandwidth. The Large SSD improves

Component	Area ($\mathrm{mm}^2$)	Power (W)
NTTU	6.5	4.8
MODU	3.3	2.7
OT & KeyGen	0.075	0.063
SRAM	7.4	3.3
Scratchpad	17.4	1.9
Interconnect & Others	10.9	3.9
Total	45.6	16.7

geometric-mean performance by about 38%.

Area and Power Overhead

Area Overhead

Table V summarizes the area and power breakdown of Rosemary. At 7nm, Rosemary occupies $45.6\ \mathrm{mm}^2$ and consumes 16.7W, only 2.3% of the total area of a Samsung 990 Pro [63]. This is comparable in scale to prior ISP designs [67, 68], with Beacongnn employs $27.7\ \mathrm{mm}^2$ and NDSEARCH employs $43.09\ \mathrm{mm}^2$ total area of the customized logic. The area and power employment is much smaller than SHARP [35] ($149.2\ \mathrm{mm}^2/66.2$W), excluding their HBM PHY overhead. SmartSSD [41], by comparison, requires about $800\ \mathrm{mm}^2$ of logic area alone. NTTU and MODU account for 21.1% of the area and 44.9% of power. SRAM and scratchpad contribute 16.2%/19.8% and 38.2%/11.4% of total area/power, respectively. The interconnect occupies a notable area to support generic NTT data movement, as AUs need to support for complex NTT data patterns across generic parameter sets to maintain high utilization for different schemes. The mProgram dispatcher, descriptor lookup, command queues, and arbitration logic together occupy less than $0.1\ \mathrm{mm}^2$.

Power Budget and Energy Efficiency

ISP accelerators are bounded by the PCIe power budget, about 55W [68, 67]. Our total power consumption of 16.7W stays within this budget. Recent server-oriented EDSFF E3.S devices support power envelopes up to 25W for standard form factors and 40W for thicker variants, including computational-storage and accelerator devices [37]. Their enclosure and heatsink designs are optimized for efficient heat transfer to server airflow [37, 58]. At 16.7W, Rosemary remains below the standard 25W E3.S envelope, leaving 8.3W of headroom and fitting within existing server cooling capabilities.

As shown in Figure 17, Rosemary improves energy efficiency by up to $3.9\times$. The energy efficiency improvement is mainly from the decrease in PCIe data movement and overall latency reduction. Relative to HA, Rosemary eliminates substantial SSD I/O by reducing feature-vector transfers. We also evaluate the cost of Rosemary Energy-Delay-Area-Product (EDAP). Rosemary reduces EDAP ranging from $6.71\times$ to $16.48\times$. Overall, Rosemary demonstrates substantial advantages in both cost and energy efficiency, making it a practical and sustainable solution for large-scale FHE deployments.

Case Study: Private ML Inference

Figure 18 shows host-accelerator, Rosemary SSD, and PCIe utilization during end-to-end private ML inference under TDAP. For ResNet, TDAP keeps compute-intensive nonlinear activations on the host while offloading data-intensive linear layers to ISP. The host is active for 45.0% and 80.2% of execution for ResNet110-EW and ResNet110-UW. The higher utilization for UW arises when adjacent-weight multiplications avoid key switching. For BERT-Base, TDAP executes LayerNorm on the host and offloads large attention and feed-forward linear layers to ISP, where their large weight and ciphertext footprints make near-storage execution advantageous.

Related Work

FHE Acceleration: Prior FPGA, GPU, and ASIC accelerators substantially improve FHE latency and throughput [23, 32, 31, 3, 57, 35, 72, 30], while compiler frameworks optimize program generation and bootstrapping placement [39, 22]. These efforts primarily target computation, whereas Rosemary addresses the storage I/O bottleneck of large-scale, data-intensive FHE workloads.

Near-Data Processing for HE: Memory-centric accelerators reduce main-memory traffic but remain capacity-limited [53, 36]. In/near-storage designs reduce I/O for specialized workloads such as PIR, PSI, and string matching [44, 17, 65, 34], while SmartSSD-style platforms are constrained by limited on-device compute [69, 41, 64]. Rosemary instead combines ISP with host-side heterogeneous compute to support general FHE workloads with reduced data movement.

Conclusion

This work presents Rosemary, an efficient and adaptable in-storage FHE acceleration system for large-scale applications. Rosemary combines a novel ISP architecture, Rosemary SSD, with hardware–software co-design through Compiler-Level Ciphertext-Aware Optimizer (CLCAO) and Throughput-Data-Aware Program Allocator (TDAP). Together, they enable efficient offloading of data-intensive FHE stages and reduce PCIe data movement. Rosemary achieves gmean speedups of 185.7× and 3.7× over state-of-the-art CPU/GPU implementations and the UFC [72] baseline, respectively, while improving energy efficiency by up to 3.9× and EDAP by 16.5×.

ACKNOWLEDGEMENTS

The authors used the generative AI tool (ChatGPT) solely to polish and improve the readability of the initial draft. All technical content, experimental results, and interpretations were produced and verified by the authors.

References

Biographies

Xuan Wang

Xuan Wang received her B.S. degree from the University of California at San Diego, La Jolla, CA, in 2023. She has been pursuing the Ph.D. degree in Computer Science and Engineering at the University of California at San Diego, La Jolla, CA, since 2023. Her research interests include hardware-software co-design, computer architecture, fully homomorphic encryption, and privacy-preserving computing.

Tianqi Zhang

Tianqi Zhang received the B.S. degree from the University of Electronic Science and Technology of China, Sichuan, China. He is currently pursuing the Ph.D. degree in computer science and engineering with the University of California at San Diego, La Jolla, CA, USA, since 2023. His research interests include algorithm and hardware co-design, neuromorphic computing, and domain-specific accelerators.

Gabrielle De Micheli

Gabrielle De Micheli is a Staff Cryptography Research Scientist at LG Electronics, North America, conducting research focusing on fully homomorphic encryption and more generally post-quantum cryptography. She also has an affiliated research appointment as Visiting Scholar at UC San Diego in the Department of Electrical and Computer Engineering. She completed her PhD at INRIA, France, in 2021, and was a postdoctoral scholar at UC San Diego from 2021-2024.

Yujin

Yujin received the BS degree in electrical and computer engineering from Seoul National University in 2020. She is currently working toward the PhD degree in computer science and engineering with the University of California, San Diego. Her research focuses on system security and data privacy. Especially, she works on privacy-preserving machine learning (PPML) with applications of cryptographic technologies like fully homomorphic encryption.

Keming Fan

Keming Fan received the B.E. degree from ShanghaiTech University, Shanghai, China. She is currently pursuing the Ph.D. degree in electrical and computer engineering with the University of California at San Diego, La Jolla, CA, USA, in 2022. Her research interests include hardware-software co-design, mixed-signal circuit design, and in-memory computing.

Augusto Vega

Augusto Vega is a Senior Research Scientist in AI hardware and computer architecture. His work centers on the co-design of machine learning systems, accelerators, and scalable computing platforms, with an emphasis on performance, efficiency, and deployment at scale. His research interests include AI infrastructure, workload-driven architecture design, system optimization, and emerging technologies for next-generation intelligent computing systems. He holds a Ph.D. degree from Polytechnic University of Catalonia (UPC), Spain.

Minxuan Zhou

Minxuan Zhou (Member, IEEE) received his Ph.D. degree from University of California San Diego, CA, USA, in 2023. He is an Assistant Professor of Computing at Illinois Institute of Technology, Chicago, IL, USA. His research interests include computer architecture, software-hardware co-design, machine learning acceleration, and privacy-preserving computing.

Tajana Rosing

Tajana Rosing (Fellow, IEEE) received her Ph.D. degree from Stanford University, Stanford, CA, USA, in 2001. She is a Professor, a Holder of the Fratamico Endowed Chair, and the Director of System Energy Efficiency Laboratory, University of California at San Diego, La Jolla, CA, USA. She is leading a number of projects, including efforts funded by DARPA/SRC JUMP 2.0 PRISM program with focus on design of accelerators for analysis of big data, DARPA and NSF funded projects on hyperdimensional computing, and SRC funded project on IoT system reliability and maintainability. Her current research interests include energy-efficient computing, cyber–physical, and distributed systems.