PQC Hardware Acceleration

“Accelerating PQC” is not one problem. Each algorithm spends its time in a different place, and an accelerator only helps if it speeds up that place — and if moving the work there costs less than it saves.

Hardware rarely accelerates “an algorithm”. It accelerates the primitives underneath:

• Montgomery reduction — computes “mod N” with multiplications and a shift instead of a slow division (Montgomery, 1985; FIPS 204 Appendix A). Inside RSA, ECC and every ML-DSA coefficient multiply.
• NTT (Number-Theoretic Transform) — turns polynomial multiplication from 65,536 products into about 3,300 for 256 coefficients. ML-DSA runs a full 8-layer NTT; ML-KEM’s modulus 3,329 only allows 7 layers.
• Keccak-f[1600] — a 24-round shuffle of a 1,600-bit state using only XOR, AND, NOT and rotate (FIPS 202). Constant-time by nature and cheap in hardware.
• SHA-3 — Keccak in a “sponge”: absorb the message into the 1,088-bit rate, keep a 512-bit capacity sealed, output a fixed 256 bits (SHA3-256).
• SHAKE — the same sponge with an output tap you can leave open. SHAKE128 (capacity 256) grows ML-DSA’s and ML-KEM’s matrices; SHAKE256 is every hash in SLH-DSA-SHAKE.

Workshop step 2 explains each one in plain English, with a worked Montgomery example you can check by hand and an animated NTT butterfly network.

From closest-to-the-CPU to furthest away: scalar code; SIMD vector units (Arm NEON/SVE, x86 AVX2/AVX-512); dedicated crypto instructions (AES, SHA-256, SHA-512, SHA-3); GPUs; FPGAs; ASICs and secure elements; and NPUs. The further from the CPU, the more raw speed is available — and the more you pay to move data there and back.

We run the same Rust PKCS#11 engine on three Arm platforms: an Apple M4 Pro laptop (Armv9.2-A, with SHA-3, SHA-512 and SME2), an NXP i.MX 95 appliance (6× Cortex-A55, Armv8.2-A) and an AMD Kria KV260 appliance (4× Cortex-A53, Armv8.0-A, plus FPGA fabric). The A55 and A53 both have AES and SHA-256 instructions and neither has SHA-3 or SHA-512.

Workshop step 3 lets you compare every algorithm across the three platforms.

Every acceleration below is real work in our engine or appliance images, with the measured before → after. The coloured tag says which acceleration model it is — and notice how many of the biggest wins are plain software engineering, not new hardware.

Container and M4 Pro figures isolate one change at a time; the boards only have bundled before/after figures (e.g. KV260 SLH-DSA-SHA2-128s 9.4 s → 191 ms, SHAKE-128s 12.3 s → 2.12 s, all CPU changes together). Items marked “merged” reach the boards with the next image build.

An FPGA is a grid of small programmable parts: LUTs (6-input truth tables that make up all logic), flip-flops (1-bit registers), DSP slices (hard multipliers) and block RAM. The KV260 has 117,120 LUTs, 1,248 DSPs and 144 block-RAM tiles. Four limits decide what it can do:

1. Area. Our ML-DSA design used 81% of the LUTs and 95% of the block RAM. Each SLH-DSA Keccak lane cost about 14k LUTs after a redesign, so eight lanes (~130k) would not fit on the whole chip.
2. Clock. The clock can tick only as fast as the longest logic path allows, and that path grows as the design grows. Our 4-lane engine missed 250 MHz by 10 picoseconds and ships at 240 MHz.
3. The bus. Data must be copied into the fabric and back, with cache flushes on both sides. Our first Keccak engine cost 1,481 µs per call before doing any work.
4. Sharing. One engine serves every core. Four threads got the same 14.3/s as one, and threads that fell back to ARM pushed p99 latency to 2.7 s.

Reprogramming. Unlike an ASIC, the fabric can be rewritten in the field. Our KV260 ships one complete image; we also tested swapping whole images at runtime (“profiles”: ML-DSA signers ⇄ SLH-DSA hash engine, live on the board, with the crypto services restarting). AMD’s modular alternative — partial reconfiguration, which swaps one slot while the rest keeps running — we documented but did not use.

Workshop steps 4 and 5 turn these into interactive labs.

A real system never runs one algorithm. It runs ML-KEM and ML-DSA for new sessions, SLH-DSA for long-lived signatures, RSA and ECC for everything not yet migrated, and AES and SHA-2 for the traffic — and the list will change as standards evolve. Acceleration has to follow that list without being rebuilt every time.

GPUs win on throughput, not latency. Every launch has a fixed cost, lanes run in lock-step groups, and memory delays are hidden only when thousands of independent operations are in flight — perfect for signing 50,000 certificates, poor for one TLS handshake.

ASICs share the FPGA’s limits — bus transfers, one engine shared by many cores, a fixed area budget — and add their own: the design is frozen at tape-out, takes years and a large up-front investment, and cannot follow a new parameter set or a revised standard. Their reward is the highest clock and lowest power of any option.

NPUs are arrays of 8-bit multiply-accumulate units fed a pre-compiled neural-network graph, designed to tolerate rounding. PQC needs exact arithmetic on 23-bit (ML-DSA) and 12-bit (ML-KEM) numbers, and Keccak is bitwise logic with no multiplication at all.

The practical checklist: find where the time actually goes; check which instructions the core really has and that the build uses them; prefer acceleration inside the CPU for small, latency-sensitive operations; offload only whole operations; and measure end to end, under concurrency, against the best CPU path — not the reference code.