Matt Hilbert, Editor, FPGA Horizons Journal
Ever since 1980 when American physicist Paul Benioff published the first quantum mechanical model of a Turing machine and proved that computation could be described within the laws of quantum mechanics, people have been reading and talking about quantum computing.
No surprise there. It promises to unlock a level of computational power far beyond what today’s computers can achieve by harnessing the unique quantum properties of superposition and entanglement. Instead of processing information in binary bits, quantum computers use qubits that can represent multiple states at once, enabling them to explore vast solution spaces in parallel. The result is the potential to solve problems that are currently intractable, from simulating complex molecules for new medicines, to optimizing global logistics, to breaking the cryptographic codes that underpin digital security everywhere. At its core, the promise of quantum computing is to transform fields where exponential complexity overwhelms classical systems, offering breakthroughs that could reshape science, industry, and security.
That’s the promise and we’re now moving close to reality with major companies investing billions in their efforts. Google, for example, is focusing on error correction as the ultimate milestone and aims to resolve the fragility of qubits and make quantum computing credible at scale. Quantinuum is addressing the fragmentation problem by evolving trapped‑ion machines and algorithms together for end‑to‑end solutions in finance, pharma, and cybersecurity. And rather than racing to build standalone quantum hardware, Alibaba is emphasizing cloud-accessible quantum services, integrating experimental quantum processors into its massive cloud ecosystem.
And that’s the problem. By around 2035, quantum computers with the power to crack current encryption methods are expected to arrive, and the standard cryptographic primitives we rely on today will no longer be sufficient. Public key cryptography approaches such as RSA, ECC, ECDSA and EdDSA which depend on the hardness of integer factorization or discrete logarithm problems will be broken, forcing a shift to post-quantum algorithms. Symmetric crypto and bitstream protection will remain but will need stronger parameters and integration with new quantum-safe standards. The most urgent changes will be in secure boot, firmware signing, and key exchange protocols.
How Shor’s algorithm can help us
Fortunately, we’ve been a step ahead of this challenge since 1994 when American mathematician Peter Shor published an algorithm which showed how a quantum computer could break RSA and ECC cryptography in polynomial time, making current FPGA secure boot and update signatures vulnerable. Shor’s paper sent shockwaves through the cryptographic world and, by 2001, experimental demonstrations of his algorithm factoring small numbers proved the threat was more than academic.
Through the 2000s and 2010s, as quantum hardware steadily advanced, governments and industry realized that RSA and ECC could not be relied upon for long-term protection. In 2016 the US National Institute of Standards and Technology (NIST) responded with a global competition for proposals to standardize new public key cryptographic algorithms resistant to quantum computer attacks. It culminated in 2022 with the selection of lattice-based algorithms such as Kyber for key exchange and Dilithium for digital signatures.
It’s time to rethink every encryption standard you thought you knew
At first glance, it might appear all of this talk is a theoretical exercise that can be left on the shelf until some time in the 2030s. For FPGA engineers, however, it’s not. FPGAs are designed for use over decades and some FPGA families are now guaranteed into the 2040s. Er, after quantum computing lands. The engineering efforts to introduce post-quantum cryptography (PQC) need to start now because they involve more than implementing stronger key exchanges and digital signature schemes in firmware, secure boot processes and other cryptographic routines. It’s also about ensuring the FPGA hardware can handle the new cryptographic primitives efficiently. That could mean adapting the hardware architecture to support larger key sizes, or incorporating dedicated modules designed specifically for quantum‑safe algorithms. It’s a tandem effort, updating the software for new encryption standards and making sure the hardware can run those standards effectively.
Fortunately, the NIST initiative provided a practical entry point into PQC in August 2024 when it published the first three Federal Information Processing Standards (FIPS):
- FIPS 203: ML-KEM – Module-Lattice-Based Key-Encapsulation Mechanism Standard
The primary standard for key encapsulation (secure key exchange) based on the CRYSTALS-Kyber algorithm, with comparatively small encryption keys compared to other PQC alternatives but still significantly larger than RSA/ECC - FIPS 204: ML-DSA – Module-Lattice-Based Digital Signature Standard
The primary standard for protecting digital signatures using the CRYSTALS-Dilithium algorithm - FIPS 205: SLH-DSA – Stateless Hash-Based Digital Signature Standard
A backup method for protecting digital signatures which uses the hash-based Sphincs+ algorithm, should ML-DSA prove vulnerable
These standards come with recommended parameter sets, interoperability guidance and transition advice, providing a path from current systems to quantum-resistant ones. ML‑KEM is directly relevant to FPGA workflows because its polynomial arithmetic and number‑theoretic transforms can be mapped efficiently onto Digital Signal Processing (DSP) slices, Look‑Up Tables (LUTs) and Block RAM (BRAM), enabling hardware‑accelerated quantum‑safe key exchange. ML‑DSA extends this protection to authentication and secure boot, giving FPGA designers a standards‑compliant way to verify bitstreams and firmware. SLH‑DSA offers a conservative, hash‑centric alternative that trades speed for long‑term trust, making it valuable for root‑of‑trust anchors and certification processes.
How this will change the way FPGA engineers approach encryption
The arrival of PQC will reshape FPGA engineering practices in several concrete ways. First, design priorities will need to accommodate the wide variation in key, signature and ciphertext sizes that different PQC schemes impose. Where RSA or ECC implementations often worked within predictable size ranges, PQC can require much larger buffers and different memory layouts, so you’ll need to plan memory and I/O early in board and device selection. Secondly, a new set of computation kernels becomes central: parameterizable, pipelined engines for polynomial multiplication, highly-optimized NTT implementations, modular reduction circuits and Keccak/SHAKE acceleration will move from research prototypes into standard IP libraries.
These kernels demand careful trade-offs between area and throughput. An FPGA implementation for an edge device, for example, will favor compact, low power data paths while a gateway or server accelerator will prioritize parallel lanes and low latency.
Equally important is the imperative for crypto-agility. Because PQC is still evolving and additional parameter sets or algorithms may become recommended over time, FPGA crypto subsystems must be modular, with discrete algorithm blocks behind a clear, upgradeable interface so firmware or secure boot routines can switch algorithms without an entire hardware redesign.
That modularity pairs with lifecycle concerns, so field upgrade mechanisms, secure firmware delivery and robust fallback modes will become standard planning items for devices expected to operate through the 2030s. Side-channel and fault injection countermeasures also gain prominence. PQC primitives have new leakage profiles and you need to design constant time, masked or otherwise hardened implementations rather than rely on purely software mitigations.
Finally, verification and compliance work will expand. Engineers should adopt PQC-ready testbenches which integrate NIST reference vectors and measure PQC-specific metrics such as key-generation cost, encapsulation and decapsulation latency, signer and verifier throughput, and memory footprint. These measurements will inform procurement trade-offs and system-level decisions, and will be necessary to demonstrate interoperability with software stacks and conformance to evolving standards.
Start hybrid, migrate later
We’ve been talking about the need to introduce PQC now, right now, but it’s the long-term destination, not the one we want to reach immediately. Instead, full PQC adoption should be gradual. For FPGA engineers, the need now is hybrid cryptography with protocols that combine classical RSA/ECC with PQC algorithms in the same handshake or signature. This dual‑mode approach ensures backward compatibility with existing infrastructures while introducing quantum‑safe primitives. It also buys time for toolchains, IP libraries, and hardware modules to mature. FPGA crypto subsystems should therefore be designed to support both classical and PQC blocks behind modular interfaces, so that firmware and secure boot routines can switch algorithms without requiring a wholesale redesign.
Over the next decade, hybrid deployments will dominate secure boot, firmware signing, and key exchange, before systems transition fully to PQC standards.
Practical steps to stay ahead
FPGA engineers should begin by logging where public-key cryptography is used in products and assessing which secrets or communications are long-lived. For designs that require PQC acceleration, prioritize building modular, synthesizable IP for the common computational kernels identified across the standards. Think Number‑Theoretic Transform (NTT) engines and polynomial multipliers, optimized hash and Pseudo‑Random Number Generator (PRNG) units, and configurable memory architectures for large coefficient arrays. Boards and FPGA selections should reserve BRAM or Ultra RAM (URAM) capacity and plan Direct Memory Access (DMA) bandwidth for moving larger keys and ciphertexts efficiently. Security engineering must be integrated from the start, selecting and implementing side-channel countermeasures that match the chosen PQC primitive, and developing test harnesses that exercise algorithmic edge cases and validate against official test vectors. Finally, plan for field upgradeability so algorithm swaps and parameter updates can be delivered securely over the product lifecycle rather than requiring hardware recalls.
Conclusion
NIST’s post-quantum standards mark a major, practical step toward preserving cryptographic security when quantum computation moves from Shor’s algorithm to everyone’s in-box. For FPGA engineers this transition is both an opportunity and a challenge. While FPGAs offer excellent acceleration for many PQC kernels, successful adoption requires rethinking memory budgets, adding new arithmetic IP, strengthening side-channel protections and designing for crypto-agility and lifecycle updates. Teams that invest now in modular, parameterized implementations and in measurement-driven design will be best positioned to meet the NIST timelines and deliver post-quantum secure FPGAs.
