Comparative Performance Analysis of NIST PQC Standards: From STM32 Software Limitations to FPGA-SoC Acceleration

This paper demonstrates that while NIST-standardized post-quantum signature schemes like SPHINCS+ and Dilithium are impractical for resource-constrained ARM Cortex-M4 microcontrollers due to severe performance and memory limitations, a hardware-software codesign approach utilizing an FPGA-accelerated NTT core on a Zynq-7000 SoC enables efficient, millisecond-level execution suitable for quantum-resistant embedded systems.

The Gist

Imagine the world of digital security as a giant vault. For decades, the locks on this vault (like RSA and ECC) have been incredibly strong, but a new kind of thief is emerging: the Quantum Computer. This thief has a master key that can pick these old locks in seconds. To stop them, scientists at NIST (the US standards body) have designed new, super-complex locks called Post-Quantum Cryptography (PQC).

This paper is a report card on trying to install these new, heavy-duty locks on two very different types of "doorframes": a small, budget-friendly microcontroller (like the brain inside a smart thermostat) and a powerful, high-tech computer chip (like the brain inside a modern server or advanced drone).

Here is the breakdown of their experiment using simple analogies:

1. The Two New Locks

The researchers tested two specific types of new locks:

• Dilithium (The Math Puzzle): This lock is based on complex lattice math. It's like trying to solve a massive, multi-dimensional jigsaw puzzle where the pieces are huge polynomials. It requires a lot of workspace (memory) to hold all the pieces while you solve it.
• SPHINCS+ (The Hash Tree): This lock is based on hashing (scrambling data). It's like building a massive tree where every branch is a tiny signature. To sign a message, you have to climb up and down this tree thousands of times, doing a lot of heavy lifting (hashing) at every step.

2. The First Attempt: The "Tiny Workshop" (STM32 Microcontroller)

The researchers first tried to install these locks on a standard, low-cost chip called the STM32. Think of this chip as a tiny, one-room workshop with a very small workbench (192 KB of memory) and a single, slow worker.

• The Dilithium Failure: When they tried to bring the "Math Puzzle" into this tiny workshop, the puzzle pieces were simply too big. The worker tried to lay them out on the workbench, but the bench was too small. The worker's head hit the ceiling, and the whole system crashed. In technical terms, the chip ran out of memory (stack overflow) immediately.
• The SPHINCS+ Failure: The "Hash Tree" didn't crash the workshop, but it was agonizingly slow. Because the worker had to climb the tree thousands of times without any help, it took about 10 minutes just to sign a single message. By the time they tried to verify the signature, the system gave up entirely. It was too slow to be useful in real life.

The Lesson: Trying to run these new, heavy quantum-proof locks on a standard, small microcontroller is like trying to build a skyscraper in a garden shed. It just doesn't have the space or the speed.

3. The Second Attempt: The "Super-Factory" (FPGA-SoC)

Realizing the tiny workshop couldn't handle the job, the researchers moved to a Zynq-7000 SoC. Think of this as a massive, high-tech factory that has two distinct parts working together:

• The Manager (Processor System): A standard computer brain that handles the paperwork, organizes the messages, and tells the workers what to do.
• The Specialized Robots (FPGA Fabric): A custom-built area where they can build specialized machines specifically designed for the job.

The Solution: Hardware-Software Co-Design
Instead of asking the Manager to do the heavy lifting, they built custom robots (accelerators) inside the factory to do the hard math:

• They built a Robot specifically for the "Math Puzzle" (NTT) to spin the polynomials instantly.
• They built another Robot specifically for the "Hash Tree" (Keccak) to scramble data at lightning speed.

The Result:

• The Manager just handed the data to the Robots.
• The Robots did the heavy lifting in parallel (all at once).
• The results came back in milliseconds instead of minutes.
  • Key Generation: ~1 millisecond.
  • Signing: ~6 milliseconds.

The Bottom Line

The paper concludes that while the "Tiny Workshop" (standard microcontrollers) is great for simple tasks, it is completely unprepared for the heavy math required by future quantum-proof security.

To make these new locks work in the real world, you can't just rely on software; you need Hardware-Software Co-Design. You need a system where a standard computer brain manages the process, but specialized hardware robots (FPGAs) do the heavy lifting. Without these specialized robots, the new locks are too slow or too big to use on everyday devices.

Technical Summary

Technical Summary: Comparative Performance Analysis of NIST PQC Standards on Embedded Hardware

Problem Statement
The advent of large-scale quantum computing threatens current public-key cryptographic infrastructure, specifically RSA and ECC, which are vulnerable to Shor's algorithm. This necessitates a transition to Post-Quantum Cryptography (PQC), led by NIST standardization efforts. However, a significant gap exists between the mathematical complexity of these new standards and the capabilities of resource-constrained embedded systems. This paper investigates the feasibility of implementing two NIST-standardized signature schemes—CRYSTALS-Dilithium (lattice-based) and SPHINCS+ (hash-based)—on standard microcontrollers. The study highlights that the high-degree polynomial multiplications required by Dilithium and the hypertree structures of SPHINCS+ create computational and memory bottlenecks that exceed the limits of general-purpose microcontrollers like the ARM Cortex-M4.

Methodology
The research employed a dual-phase experimental approach to evaluate performance across different hardware architectures:

1. Software-Only Baseline (STM32F407G):

   • Platform: STM32F407G-DISC1 board featuring a 32-bit ARM Cortex-M4 core (168 MHz) with 192 KB SRAM and 1 MB Flash.
   • Approach: Reference implementations of CRYSTALS-Dilithium and SPHINCS+ were ported to the bare-metal environment without hardware-specific optimizations or algorithmic simplifications.
   • Objective: To establish a standard-compliant baseline and identify specific failure points (memory overflow, timing constraints) in a typical embedded setting.

2. Hardware-Software Co-Design (Xilinx Zynq-7000 SoC):

   • Platform: ZedBoard (XC7Z020) featuring a dual-core ARM Cortex-A9 Processing System (PS) and an Artix-7 FPGA Programmable Logic (PL) fabric.
   • Approach: Utilizing the CityUHK-CALAS architecture, the study offloaded computationally intensive primitives to the FPGA.
   • Implementation Details:
     • Offloading: The Number Theoretic Transform (NTT), Inverse NTT (INTT), and Keccak-based hashing (SHA-3) were implemented as dedicated hardware accelerators in the PL.
     • Control: The PS managed high-level protocol logic, message formatting, and state machines.
     • Communication: AXI4-Lite was used for control signals, while AXI4-Stream interfaces with Direct Memory Access (DMA) handled bulk data transfer (keys, messages, signatures) to prevent bottlenecks.

Key Contributions

• Empirical Validation of Limitations: The study provides concrete evidence that unmodified PQC reference implementations are practically unusable on standard 32-bit microcontrollers due to severe memory and timing constraints.
• Architectural Solution: It demonstrates a successful migration strategy using a heterogeneous SoC approach, partitioning cryptographic workloads between the processor and FPGA fabric.
• Performance Benchmarking: The paper offers a direct comparative analysis of execution times between a pure software implementation on an MCU and a hardware-accelerated implementation on an SoC.

Results
The experimental results revealed a stark contrast in performance between the two platforms:

• STM32F407G (Software-Only):

  • CRYSTALS-Dilithium: Failed to execute entirely. The algorithm caused a stack overflow during key and signature generation because the required intermediate buffers for polynomial coefficients exceeded the 192 KB SRAM limit.
  • SPHINCS+: Executed but with prohibitive latency. Key and signature generation took approximately 10 minutes each. The verification process, requiring thousands of hash evaluations, caused the system to collapse due to the lack of hardware hashing acceleration.

• Zynq-7000 SoC (HW-SW Co-Design):

  • By offloading NTT and Keccak operations to the FPGA, the system achieved successful execution with millisecond-level performance.
  • Key Generation: ~1.109 ms
  • Signature Generation: ~5.94 ms
  • Verification: ~1.17 ms

Significance and Claims
The paper concludes that for real-time embedded applications, hardware acceleration is not merely an optimization but a functional necessity for deploying NIST PQC standards. The findings indicate that:

1. Pure software implementations of PQC on standard microcontrollers are insufficient for next-generation security requirements due to memory overflows and excessive latency.
2. A hardware-software co-design approach, specifically leveraging FPGA acceleration for mathematical primitives (NTT, Keccak), effectively mitigates these bottlenecks.
3. Heterogeneous computing architectures are essential for the efficient and secure deployment of post-quantum cryptographic algorithms in embedded systems.

The authors position their work as a demonstration that while the transition to PQC is critical, the underlying hardware infrastructure must evolve from general-purpose microcontrollers to specialized, accelerated SoC platforms to support these complex algorithms.