In the domains of digital currency, blockchain, and cloud data encryption, traditional software-based encryption and decryption methods face significant challenges including slow computation speeds, high host resource consumption, and substantial power requirements. While Field Programmable Gate Array (FPGA) implementations using Verilog/VHDL offer hardware acceleration, they suffer from extended development cycles and difficulties in maintenance and upgrades. This paper addresses these limitations by proposing a novel FPGA accelerator design for the 3DES algorithm utilizing the OpenCL framework.
The proposed design implements a 48-iteration pipeline parallel structure. Optimization strategies include data storage adjustment and data bit-width improvement in the data transmission module to enhance kernel bandwidth utilization, along with instruction stream optimization in the algorithm encryption module to form an efficient pipeline parallel architecture. Additional performance gains are achieved through kernel vectorization and compute unit replication.
Peak Throughput on Intel Stratix 10 GX2800
Performance gain vs. Intel Core i7-9700 CPU
Energy Efficiency gain vs. CPU
Performance & Efficiency gain vs. NVIDIA GTX 1080 Ti GPU
The Triple Data Encryption Standard (3DES) algorithm is built upon the DES algorithm, enhancing security through three successive DES operations. While DES uses a 56-bit key and 16 iterations, 3DES employs a 168-bit key and 48 iterations.
The DES algorithm operates on 64-bit blocks of plaintext. Its core function, the Feistel network, can be represented as: $L_i = R_{i-1}$ $R_i = L_{i-1} \oplus F(R_{i-1}, K_i)$ Where $L_i$ and $R_i$ are the left and right halves of the data block in round $i$, $K_i$ is the round key, and $F$ is the round function involving expansion, S-box substitution, and permutation.
3DES applies DES three times with either two or three independent keys (EDE mode): $Ciphertext = E_{K3}(D_{K2}(E_{K1}(Plaintext)))$. This structure significantly increases resistance to brute-force attacks compared to single DES.
The accelerator leverages OpenCL's heterogeneous computing model, allowing kernel programs to be compiled and executed on FPGA devices. This approach bridges the gap between the flexibility of software and the performance of hardware.
The architecture consists of a host (CPU) managing control flow and data transfer, and a device (FPGA) executing the computationally intensive 3DES kernel. The FPGA kernel is designed with a deeply pipelined structure to process multiple data blocks concurrently.
The core of the design is a 48-stage pipeline corresponding to the 48 iterations of 3DES. Each stage is carefully balanced to ensure high clock frequency and full utilization of the pipeline, hiding the latency of individual operations.
This module handles data movement between host memory and FPGA global memory. Strategies like burst transfers and aligned memory accesses are employed to achieve near-peak theoretical bandwidth. The use of wider AXI interfaces (e.g., 512-bit) is a key factor in improving effective bandwidth.
This module implements the 3DES Feistel rounds. The S-boxes, which are traditionally implemented as lookup tables (LUTs), are optimized for the FPGA's logic elements. The permutation and expansion operations are hardwired into the datapath.
The overall throughput $T$ of the accelerator can be modeled as: $T = f_{clk} \times W \times N_{CU} \times \eta$ Where $f_{clk}$ is the operating frequency, $W$ is the processed bit-width per cycle, $N_{CU}$ is the number of compute units, and $\eta$ is the pipeline efficiency factor (close to 1 for a well-balanced design).
The accelerator was implemented on an Intel Stratix 10 GX2800 FPGA. The primary results are:
vs. CPU (Intel Core i7-9700): The FPGA accelerator demonstrates a 372x performance improvement and a staggering 644x improvement in energy efficiency (Performance/Watt). This highlights FPGA's superiority for fixed, compute-intensive kernels.
vs. GPU (NVIDIA GeForce GTX 1080 Ti): The FPGA achieves a 20% higher throughput and a 9x better energy efficiency. While GPUs excel at massive parallelism on regular data, FPGAs can achieve higher efficiency on bit-level operations and custom pipelines, as seen in cryptographic algorithms.
The design efficiently utilizes FPGA resources. Key metrics include:
Framework for Evaluating Hardware Crypto Accelerators:
Case Study - Cloud Data Encryption Gateway: Imagine a secure cloud storage service that encrypts all data at rest using 3DES. A software-only solution on a Xeon server might become a bottleneck. By offloading the 3DES encryption to an FPGA accelerator card (like an Intel PAC with Stratix 10), the service can achieve higher overall throughput, lower latency for individual requests due to hardware pipelines, and reduce server power consumption and CPU load, freeing resources for other tasks.
This paper isn't just about making 3DES fast; it's a strategic blueprint for reclaiming efficiency in a post-Moore's Law era. While the industry has been hypnotized by the raw FLOPs of GPUs for acceleration, the authors deliver a stark reminder: for specific, well-defined kernels like cryptographic primitives, the deterministic, bit-level programmability of FPGAs can outmaneuver the general-purpose, power-hungry architectures of CPUs and GPUs. The 644x energy efficiency gain over a modern CPU isn't an incremental improvement—it's a paradigm shift for data center operators where power is the ultimate cost center. This work aligns with a broader trend observed in hyperscalers like Microsoft and Amazon, who deploy FPGAs (and now ASICs) at scale for tasks like network virtualization and video transcoding, prioritizing performance-per-watt over peak theoretical throughput.
The authors' logic is compelling and methodical. They correctly identify the dual problem: software is too slow and inefficient, while traditional HDL-based FPGA development is too slow and rigid. Their solution, using OpenCL as a High-Level Synthesis (HLS) tool, elegantly attacks both fronts. The optimization strategies follow a clear hierarchy: first, ensure data can flow to the compute units efficiently (data storage, bit-width). Second, ensure the compute units themselves are maximally utilized (instruction optimization, pipelining). Finally, scale out (vectorization, replication). This mirrors the optimization process for GPU kernels but is applied to a fabric where the "cores" are custom-built for the exact task. The comparison to the GTX 1080 Ti is particularly telling—it shows that even against a highly parallel processor, a custom data path on an FPGA can win on both performance and, decisively, efficiency.
Strengths: The performance and efficiency results are exceptional and rigorously quantified. The use of OpenCL provides crucial developer accessibility and future-proofing, as noted in the Khronos OpenCL specifications which enable portability across vendors. The focus on 3DES, a legacy but still widely deployed standard (e.g., in financial systems), addresses a real-world need for modernization rather than a purely academic exercise.
Flaws & Critical Gaps: The paper's Achilles' heel is its narrow scope. 3DES is being phased out in favor of AES-256 for new systems, as per NIST guidelines. The work would be far more impactful if it demonstrated the agility of the OpenCL approach by also implementing AES or a post-quantum candidate, showing the framework's value beyond one algorithm. Furthermore, the analysis lacks a discussion on side-channel vulnerability. A hardware implementation, especially one aiming for high throughput, could be susceptible to timing or power analysis attacks. Ignoring this security dimension is a significant oversight for a cryptography paper. The work of researchers like Mangard et al. on hardware side-channel resistance is essential context missing here.
For Product Managers in cloud or security appliance companies: This research is a proof-of-concept for deploying FPGA-based accelerator cards for offloading cryptographic workloads (TLS termination, storage encryption). The energy savings alone justify a pilot project. For Security Architects: Push your vendors. Demand that hardware accelerators, whether FPGA or ASIC, include side-channel resistant designs as a standard feature, not an afterthought. For Researchers & Developers: Don't stop at 3DES. Use this OpenCL methodology as a foundation. The next critical step is to build a library of open-source, optimized, and side-channel resistant OpenCL kernels for a suite of algorithms (AES-GCM, ChaCha20-Poly1305, SHA-3, Kyber, Dilithium). The community needs portable, efficient, and secure building blocks, not just one-off demonstrations. The toolchain maturity highlighted by Intel's oneAPI and Xilinx Vitis is finally making this feasible. The race isn't just for speed; it's for secure, efficient, and adaptable acceleration.