FPGA based cryptographic acceleration means moving encryption, decryption, hashing and signature work from a general-purpose processor into custom logic on a field-programmable gate array. The FPGA wins when the work is regular and highly parallel, such as AES on a 100 Gbit/s link or SHA-256 over a storage stream, because it can pipeline the algorithm and process a new block every clock cycle. It also stays reprogrammable, so the design can follow new standards, including the post-quantum algorithms NIST published in 2024, without new silicon.
Image courtesy: Hackster.io
In this blog post, we will explore how FPGAs can be used to accelerate some common cryptographic operations, starting with a quick introduction to cryptographic acceleration itself.
Key takeaways
- Cryptographic acceleration is the use of dedicated hardware for encryption, decryption, hashing or signature verification, to gain speed, efficiency and isolation.
- FPGAs suit algorithms built from fixed rounds of simple operations (AES, SHA-2, SHA-3, ChaCha20), which pipeline well.
- Public-key work (RSA, ECC and the new lattice schemes) maps onto the FPGA's DSP multiplier blocks.
- Throughput depends as much on the mode of operation as on the cipher: CTR and GCM parallelise, CBC encryption does not.
- An FPGA is not secure by default. Side-channel protection, key storage and bitstream protection have to be designed in.
What cryptographic acceleration is
Cryptographic acceleration is the use of dedicated hardware to perform cryptographic operations, such as encryption, decryption, hashing, or digital signature verification. It can improve the speed, security and efficiency of applications such as secure communication (TLS, IPsec, MACsec), data protection (disk and storage encryption) and blockchain.
Modern CPUs already include some acceleration, for example the AES-NI and SHA instruction extensions on x86 and the cryptography extensions on Arm. A dedicated accelerator becomes worthwhile when the data rate is high enough that even these instructions would consume many cores, when latency must be fixed and predictable, or when keys should never be visible to host software.
Why use an FPGA
One way to implement cryptographic acceleration is with field-programmable gate arrays. FPGAs are integrated circuits that the user configures to perform specific functions. They bring several advantages for this work:
- FPGAs are flexible and adaptable. They can be reprogrammed to support different cryptographic algorithms, protocols or standards without physical changes to the hardware. This lets a deployed system keep up as algorithms are retired and new ones standardised, and lets one board serve applications with different needs.
- FPGAs are parallel and scalable. They can execute many operations at once, which raises throughput. A design can instantiate one cipher core or several, depending on the bandwidth needed and the logic available, and systems can scale further by adding FPGA cards.
- FPGAs can be built to be secure and reliable. Keys and algorithms can stay inside the device, away from host software, and current FPGAs offer bitstream encryption and authentication, secure key storage and tamper sensors. Error detection and redundancy can be added for fault resistance. These protections are features to be used carefully, not guarantees: see the security section below.
How common algorithms map onto an FPGA
| Operation | Example algorithms | FPGA structure that fits |
|---|---|---|
| Symmetric encryption | AES (FIPS 197), ChaCha20 (RFC 8439) | Unrolled, pipelined rounds; S-boxes in LUTs or block RAM |
| Hashing | SHA-2 (FIPS 180-4), SHA-3 (FIPS 202), BLAKE2 | Iterative or unrolled round logic, one or more blocks per cycle |
| Classical public key | RSA, ECC (ECDSA, ECDH, Ed25519) | Montgomery multipliers built from DSP blocks |
| Post-quantum public key | ML-KEM (FIPS 203), ML-DSA (FIPS 204) | Number-theoretic transform (NTT) butterflies on DSP blocks |
Symmetric encryption
Symmetric encryption encrypts and decrypts data with the same secret key. Examples are AES, the older and now withdrawn DES, and ChaCha20. FPGAs can implement these algorithms as parallel pipelines that process several blocks of data at the same time, and can optimise the key expansion, round function and mixing operations with dedicated logic and lookup tables.
AES-128 uses 10 rounds on a 128-bit block. An iterative core reuses one round circuit ten times, so it needs about ten clock cycles per block but very little logic. A fully unrolled core lays out all ten rounds with pipeline registers between them, so after the pipeline fills it accepts a new block every cycle.
Worked example (illustrative numbers). A fully pipelined AES-128 core clocked at 250 MHz processes 128 bits per cycle: 128 x 250 million = 32 Gbit/s. Four such cores in parallel give 128 Gbit/s, enough for a 100 Gbit/s Ethernet link with headroom. The iterative version at the same clock gives about 3.2 Gbit/s using roughly a tenth of the round logic. The right choice depends on the line rate, not on the cipher.
The mode of operation matters just as much. In counter mode (CTR) and in GCM, each block can be encrypted independently, so pipelining works. In CBC encryption, each block depends on the previous ciphertext, so a single stream cannot be pipelined and the core sits idle between blocks unless it interleaves several independent streams. GCM also needs a GF(2^128) multiplier for its authentication tag, which is a further good fit for FPGA logic.
Asymmetric encryption
Asymmetric encryption uses a pair of public and private keys. Examples are RSA, ECC and ElGamal. FPGAs implement these with arithmetic units such as multipliers, adders and shifters, and accelerate the modular arithmetic at their core, such as modular exponentiation and modular inversion, with specialised hardware modules or coprocessors.
The workhorse is modular multiplication of very large numbers: 2048 or 3072 bits for RSA, 256 to 521 bits for elliptic curves. Montgomery multiplication avoids slow division, and its inner loops map well onto the hard DSP multiplier blocks in a modern FPGA. Elliptic curve operations are built from many such multiplications in a fixed sequence, so a small controller plus a multiplier array forms an effective ECC coprocessor.
In August 2024 NIST published its first post-quantum standards: FIPS 203 (ML-KEM, for key exchange), FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA), both for signatures. The lattice schemes rely heavily on the number-theoretic transform over small moduli, which is a regular butterfly structure that FPGAs handle well. Reprogrammability is a real advantage here, since products shipped today may need these algorithms added in the field.
Hashing
Hashing produces a fixed-length output from a variable-length input. Examples are SHA-2, SHA-3 and BLAKE2. FPGAs implement hashing with feedback loops or unrolled structures that process one or more input blocks per clock cycle, and can optimise the compression function, message expansion and padding with custom logic and memory blocks.
SHA-256 runs 64 rounds per 512-bit block, and each round depends on the previous one, so a single message cannot be pipelined across rounds. Throughput comes either from processing several independent messages at once or from unrolling a few rounds per cycle at a lower clock. SHA-3, built on the Keccak permutation with a 1600-bit state and 24 rounds, uses only XOR, AND, NOT and rotations and was chosen partly for its efficiency in hardware.
A small example: the ChaCha20 quarter round in Verilog
ChaCha20 is built from a "quarter round" of 32-bit additions, XORs and fixed rotations. Rotations by a constant are free in hardware (they are just wiring), so the quarter round is cheap. The module below is combinational; a full core runs 20 rounds (80 quarter rounds) per 64-byte block and adds pipeline registers to reach the required clock rate.
// ChaCha20 quarter round (RFC 8439, section 2.1), purely combinational
module chacha_qr (
input wire [31:0] a_i, b_i, c_i, d_i,
output wire [31:0] a_o, b_o, c_o, d_o
);
function [31:0] rotl;
input [31:0] x;
input integer n;
rotl = (x << n) | (x >> (32 - n));
endfunction
wire [31:0] a1 = a_i + b_i;
wire [31:0] d1 = rotl(d_i ^ a1, 16);
wire [31:0] c1 = c_i + d1;
wire [31:0] b1 = rotl(b_i ^ c1, 12);
wire [31:0] a2 = a1 + b1;
wire [31:0] d2 = rotl(d1 ^ a2, 8);
wire [31:0] c2 = c1 + d2;
wire [31:0] b2 = rotl(b1 ^ c2, 7);
assign a_o = a2;
assign b_o = b2;
assign c_o = c2;
assign d_o = d2;
endmodule
// Test bench: RFC 8439 section 2.1.1 test vector
module tb;
reg [31:0] a, b, c, d;
wire [31:0] a2, b2, c2, d2;
chacha_qr dut (.a_i(a), .b_i(b), .c_i(c), .d_i(d),
.a_o(a2), .b_o(b2), .c_o(c2), .d_o(d2));
initial begin
a = 32'h11111111; b = 32'h01020304; c = 32'h9b8d6f43; d = 32'h01234567;
#1;
if (a2 == 32'hea2a92f4 && b2 == 32'hcb1cf8ce &&
c2 == 32'h4581472e && d2 == 32'h5881c4bb)
$display("PASS a=%h b=%h c=%h d=%h", a2, b2, c2, d2);
else
$display("FAIL a=%h b=%h c=%h d=%h", a2, b2, c2, d2);
$finish;
end
endmoduleThe test bench applies the quarter-round test vector from RFC 8439 and prints PASS when the outputs match the published result.
FPGA compared with other options
| Option | Strengths | Limits |
|---|---|---|
| CPU with crypto instructions | No extra hardware, easy software support | Uses cores; latency varies with load |
| GPU | High throughput on large batches | Batch latency; keys sit in host-visible memory |
| FPGA | Line-rate pipelines, fixed latency, field updates | Longer design effort, lower clock than an ASIC |
| ASIC or hard IP block | Best power and cost at volume | Algorithm fixed at tape-out |
Bitcoin mining showed this progression in public: it moved from CPUs to GPUs, briefly to FPGAs, and then to ASICs once the SHA-256 workload was fixed and the volume justified custom chips. Where the algorithm may change, or volume is modest, the FPGA remains the practical choice.
Security: what an FPGA does not give you for free
- Side-channel leakage. Power consumption and electromagnetic emissions can reveal keys. Published research has recovered bitstream decryption keys from several FPGA families by power analysis, and the 2020 "Starbleed" work showed a bitstream attack on one widely used family. Countermeasures such as masking and hiding must be designed in.
- Key storage. Keys should live in battery-backed RAM, eFuses or a physically unclonable function, never in the bitstream in plain form.
- Bitstream protection. Use the vendor's encryption and authentication so the design cannot be read back, copied or modified.
- Constant-time design. The accelerator's timing should not depend on secret data, for example in modular exponentiation.
- Fault attacks. Glitching the clock or supply can cause faulty outputs that leak keys; detection logic and redundancy help.
Common mistakes
- Benchmarking the cipher core alone and ignoring the PCIe or DMA path, which often limits real throughput.
- Choosing CBC mode and then wondering why a pipelined core runs at a tenth of its rated speed.
- Assuming an algorithm is secure because it is in hardware, without side-channel testing.
- Rolling a custom cipher or mode instead of a standard one with published test vectors.
- Not running the official test vectors (NIST and RFC) in simulation and again on the board.
FAQ
Is an FPGA faster than a CPU for AES?
For a single short message, often not, because the CPU's AES instructions have low start-up cost. For sustained line-rate traffic, a pipelined FPGA core can deliver tens of Gbit/s per core with fixed latency and without consuming CPU cores.
Can an FPGA run post-quantum cryptography?
Yes. The NIST lattice schemes (ML-KEM and ML-DSA) map well onto FPGA DSP blocks, and many research and commercial implementations exist. Reprogrammability lets fielded systems add them.
Why are hashes harder to pipeline than block ciphers?
Each round of SHA-2 needs the result of the previous round on the same message, so throughput comes from working on several messages in parallel rather than from a deep pipeline on one.
Where are FPGA crypto accelerators used?
In network security appliances (IPsec, MACsec, TLS offload), storage encryption, cloud SmartNICs, hardware security modules and defence communications.
Your comments will be moderated before it appears here.