Portable Acceleration of Learning With Errors KEMs for Post-Quantum Cryptography

Abstract: The transition to post-quantum cryptography (PQC) is driving demand for implementations that can meet the computational requirements of real-world applications. Among the proposed PQC constructions, Learning With Errors (LWE) based key encapsulation mechanisms (KEMs) are particularly attractive due to their strong security foundations, but they incur substantial computational costs from matrix operations and large-scale cryptographically secure random number generation. These characteristics position GPU acceleration as an effective approach for lowering the computational overhead of lattice based cryptographic schemes. In this work, we present a portable GPU implementation of a plain LWE based KEM using OpenMP Target offloading. Unlike most existing GPU implementations, which rely on CUDA specific optimizations, our approach uses a single source code base that executes on both NVIDIA and AMD accelerators. We evaluate the proposed implementation on different accelerator architectures, analyzing performance benchmarking, runtime profiling, scalability analysis, and energy to solution measurements. Experimental results show that OpenMP Target offloading delivers substantial acceleration over a multicore CPU baseline while preserving source level portability across heterogeneous GPU ecosystems. Cross platform analysis identifies NVIDIA GH200 and AMD MI300X as the most effective platforms for this memory bound workload, while profiling indicates that memory system organization and CPU GPU interaction play a more critical role than peak compute capability alone. These findings demonstrate that portable GPU acceleration can significantly reduce the computational overhead of PQC while avoiding vendor lock in, thereby facilitating the deployment of quantum resistant cryptographic infrastructures.

• The paper demonstrates a unified C++ implementation using OpenMP Target that achieves over 100× acceleration for dense, memory-bound LWE-KEM workloads across both NVIDIA and AMD GPUs.
• The methodology integrates on-GPU random number generation and persistent device allocation to minimize host-device transfers and optimize performance.
• Implications include improved energy efficiency and cross-vendor portability, underscoring the critical influence of memory architecture and data transfer management on post-quantum cryptography deployments.

Portable Acceleration of LWE-KEMs for Post-Quantum Cryptography: A Performance-Portable OpenMP GPU Implementation

Introduction

The transition to post-quantum cryptography (PQC) necessitates significant advances in cryptographic kernels due to the computational demands of lattice-based primitives. Learning With Errors (LWE)-based key encapsulation mechanisms (KEMs) are prominent candidates owing to their security reductions and broad acceptance. However, their practical deployment is challenged by dense, memory-bound matrix-vector arithmetic and the requirement for large-scale cryptographically secure random number generation. While GPU acceleration is a natural fit for these operations, most prior works are limited by vendor-specific programming models such as CUDA, thereby fragmenting codebases and reducing performance portability. This paper presents a unified C++ implementation for LWE-KEM using OpenMP Target offloading, supporting both NVIDIA and AMD GPUs and integrating HIP-enabled on-GPU random number generators. The investigation demonstrates how performance portability can be achieved in real PQC workloads and elucidates the architectural factors that affect practical acceleration (2607.09541).

LWE-KEM Cryptosystem: Algorithmic Structure and Parallelism

The security of LWE-based schemes is rooted in the hardness of solving noisy modular linear equations. KEM operations—key generation, encapsulation, and decapsulation—are each dominated by $O(n^2)$ matrix-vector multiplications with modular arithmetic and the generation of pseudorandom elements on demand. These computations are naturally parallelizable at the level of independent rows, ciphertext components, and noise samples.

Key generation begins with GPU-resident sampling of the secret and error vectors, followed by dense modular matrix-vector multiplication to form the public key. Encapsulation and decapsulation involve batched, per-bit encryption/decryption and the generation of comparatively large random matrices. The workflow leverages the RNGonGPU library for AES-based CSPRNG on both CUDA and HIP backends.

The OpenMP Target design centers on persistent device allocation and explicit data transfer minimization. All large buffers are placed in device memory through target enter data map(alloc:...) directives, keeping nearly the entire computation GPU-resident. Host-device communication is tightly managed: only those components required for CPU-side FO transform (e.g., SHA3 hashing during decapsulation) traverse the interconnect. Parallel regions and reductions are mapped to teams and SIMD execution as appropriate for the underlying platform.

Experimental Platforms and Methodology

Benchmarks target four modern GPU architectures:

1. NVIDIA A100 (PCIe 4.0, HBM2e)
2. NVIDIA GH200 Grace Hopper (NVLink-C2C, HBM3)
3. AMD MI300X (PCIe 5.0, HBM3)
4. AMD MI300A (Unified CPU-GPU HBM3 pool)

Identical source code is compiled with the vendor-specific OpenMP offload toolchains (NVHPC for NVIDIA, ROCm LLVM for AMD), ensuring that any performance differentials are due to hardware/runtime characteristics rather than source fragmentation. Timings are taken using in-source steady_clock measurements for $N=100$ runs at multiple $n$ values, scaling up to $n=16384$.

Performance Characterization and Portability

GPU offloading yields speedups exceeding two orders of magnitude over multicore OpenMP baselines for large $n$. For example, at $n=4096$, OpenMP Target on GH200 is approximately $120\times$ faster than CPU (see Table~\ref{tab:performance_openomp_target}). As $n$ increases, the workload moves deeper into the memory-bound regime, and both encapsulation and decapsulation dominate runtime.

Figure 1: HBM bandwidth, HBM capacity, and LWE-KEM execution time across platforms for $N=100, n=16384$: MI300X attains the shortest runtime despite identical HBM bandwidth with MI300A.

Figure 2: OpenMP Target scalability across architectures; strong scaling is shown up to $n=16384$. The MI300A exhibits marked overhead at the highest dimensions.

Critically, performance portability is achieved for the largest memory-bound workloads, but with nuanced architectural effects:

• Best performance: NVIDIA GH200 and AMD MI300X, with near-equivalent execution times for large $N=100$0.
• Intermediate: NVIDIA A100, limited by HBM2e bandwidth and higher host-device transfer overhead.
• Worst case: AMD MI300A, slowed by CPU-GPU contention inside the unified HBM3 pool, despite nominal HBM parity with MI300X.

  Figure 3: Total LWE-KEM execution time for all four GPUs. GH200 and MI300X are nearly competitive; MI300A lags, confirming the cost of unified memory contention.

For the most extreme configuration ($N=100$1), GH200 achieves $N=100$2s total runtime, MI300X $N=100$3s, A100 $N=100$4s, and MI300A $N=100$5s. The normalized slowdowns indicate that peak HBM bandwidth is a strong but not exclusive predictor of actual throughput due to host/device interactions and runtime overheads.

Profiling and Architectural Insights

Profiling exposes both expected and emergent bottlenecks:

• On NVIDIA GH200, NVLink-C2C reduces device-host transfer latency by almost $N=100$6 compared to PCIe (9ms vs. 51ms for ciphertext transfer), and separate CPU/GPU memories obviate contention.

  Figure 4: Nsight timeline for GH200 reveals minimal communication overhead and clear CPU-GPU compute separation.

• AMD MI300X yields the shortest kernel durations, matching its high HBM3 bandwidth, though HIP runtime introduces a small overhead through repeated hipMallocs in the RNG adapter, affecting only a minority of iterations.

  Figure 5: MI300X timeline; kernel execution is optimal but RNG adapter introduces runtime allocation events.

• The AMD MI300A's unified memory results in the most severe performance degradation. CPU-based SHA3 and FO transform substantially overlap with ongoing GPU kernels, leading to measurable contention in elapsed time for batch encryption and decryption stages (247ms and 202ms, respectively, versus 177ms and 146ms on MI300X).

  Figure 6: MI300A; overlay of CPU-side cryptographic hashing and GPU kernel execution causes HBM3 contention and runtime stretching.

• NVIDIA A100 is fundamentally bounded by less effective HBM and higher PCIe latency, though clear separation of CPU/GPU resources avoids multicomponent contention.

Overall, although source-level OpenMP portability is technically straightforward, actual performance depends on the organization of host-GPU memory, the parallel execution of CPU/GPU-side cryptography routines, and runtime library maturity. For cryptosystems with high communication-to-computation ratios, memory architecture and interconnect selection are as decisive as theoretical bandwidth figures.

Energy and Utilization Analysis

Energy consumption profiles (based on direct integration of power samples at 1Hz during execution) indicate that GH200 is also superior in energy-to-solution, achieving $N=100$7 higher energy efficiency than MI300X for the largest benchmarks, largely due to reduced execution time and lower dynamic power draw.

Figure 7: GH200 utilization, frequency, power, and temperature throughout the benchmark; high, stable occupancy is characteristic.

Implications and Future Directions

The results evidence that OpenMP Target offloading enables source-level performance portability for heavily memory-bound cryptographic applications, even as runtime behavior is modulated by deeper levels of system architecture. Avoiding the vendor lock-in associated with CUDA preserves maintainability and reproducibility for quantum-resilient cryptographic libraries, supporting the urgent migration to PQC.

Strong claims substantiated by the data include:

• OpenMP Target GPU offloading reaches speedups $N=100$8 over high-end CPUs for real LWE-KEM workloads.
• Performance for large-scale LWE-KEM is governed more by HBM subsystem design and host-GPU memory mapping than by raw peak flop rates.
• Unified memory architectures (as on MI300A) can substantially degrade memory-bound workload throughput due to CPU-GPU contention.
• Practical runtime overheads (such as RNG HIP allocation and library interoperability) are non-negligible and require attention for maximal efficiency.

Practical adoption of cryptographic PQC protocols at scale will depend on portable, high-throughput implementations like those demonstrated in this work. The public release of source-code covering both NVIDIA and AMD platforms ensures reproducibility and provides a model for future optimizations and cross-vendor interoperability research.

Conclusion

This work establishes that portable and efficient GPU acceleration of LWE-based post-quantum KEMs is viable using a unified OpenMP Target codebase supporting both NVIDIA and AMD devices. The effective acceleration of dense, memory-bound cryptographic workloads is contingent on device memory hierarchy and system integration, not merely theoretical bandwidth, and that unified CPU-GPU memory architectures may introduce new bottlenecks even when raw bandwidth is maximal. The provided implementation and profiling serve as a foundation for further exploration of runtime- and hardware-aware PQC deployment and underscore the necessity of portable acceleration models in contemporary post-quantum security engineering (2607.09541).