Future-proofing embedded systems: Why Post-Quantum Cryptography matters.
For a broader introduction to the quantum threat read this blog post.
Digital signatures are used to verify the authenticity and integrity of software, firmware, documents, messages and other data. Today, many digital signature systems rely on RSA or elliptic-curve cryptography such as ECDSA.
ML-DSA (Module-Lattice-Based Digital Signature Algorithm) is a post-quantum digital signature scheme derived from CRYSTALS-Dilithium and standardized by NIST in FIPS 204. FIPS 204 defines the three parameter sets ML-DSA-44, ML-DSA-65 and ML-DSA-87 as well as algorithms for key generation, signing and signature verification.
This article focuses on ML-DSA itself: what the algorithm is, how it works, how the parameter sets differ and what its characteristics mean for embedded, FPGA and SoC-based systems.
1. Why do we need ML-DSA?
Today's digital signatures commonly rely on RSA or elliptic-curve cryptography. A sufficiently powerful quantum computer could use Shor's algorithm to break the mathematical foundations of these schemes.
Post-quantum cryptography addresses this threat with algorithms designed to remain secure against attacks using both classical and quantum computers. ML-DSA is NIST's standardized module-lattice-based algorithm for post-quantum digital signatures.
The transition is already moving from standardisation towards migration planning. In the United States, the current transition proposal from NIST provides for selected traditional digital signature schemes at the 112-bit security level to be classified as obsolete after 2030, and for the RSA, ECDSA and EdDSA signatures mentioned in the proposal, which are vulnerable to quantum attacks to be banned after 2035. Earlier migration milestones apply to selected high-value systems operated by US federal agencies.
Europe is following a similar path. The EU's coordinated PQC roadmap calls for Member States to start transitioning to post-quantum cryptography by the end of 2026, while critical infrastructures should transition as soon as possible and no later than the end of 2030.
These timelines do not mean that every embedded product must implement ML-DSA by a particular date. They do show that PQC migration has moved from a theoretical security discussion toward concrete technology planning.
2. What is ML-DSA?
ML-DSA stands for Module-Lattice-Based Digital Signature Algorithm. It is a public-key digital signature scheme based on mathematical problems involving module lattices.
The underlying mathematics differs substantially from RSA or ECDSA, but the fundamental principle of a digital signature remains the same:
- Private key → Sign
- Public key → Verify
The signer uses a private key to generate a digital signature for a message or data object. The verifier uses the corresponding public key to determine whether the signature is valid. A valid signature provides assurance that the signed data has not been modified after signing and that it was signed by the holder of the corresponding private key.
This makes ML-DSA suitable for many applications currently using conventional digital signatures, including software signing, secure communication and authentication.
In embedded systems, typical use cases include:
- secure boot,
- firmware and software updates,
- FPGA configuration authentication,
- signed configuration data,
- device authentication,
- and authenticated commands and messages
3. ML-DSA vs. CRYSTALS-Dilithium
ML-DSA is derived from CRYSTALS-Dilithium, which was selected by NIST during its PQC standardization process. The names are therefore closely related, but they should not be used interchangeably when specifying an implementation.
NIST FIPS 204 defines the standardized ML-DSA algorithm. NIST made several changes compared with the earlier Dilithium submission, including changes to some variable sizes, domain separation and support for randomized signing. For new implementations that need to conform to the NIST standard, NIST FIPS 204/ ML-DSA should therefore be the relevant reference rather than an earlier CRYSTALS-Dilithium specification.
4. How does the ML-DSA algorithm work?
NIST FIPS 204 defines three primary operations: key generation, signature generation and signature verification.
- Key generation: ML-DSA key generation creates a public/private key pair. Internally, the algorithm uses pseudorandom generation, SHAKE-256 and operations on polynomial vectors and matrices over a polynomial ring. The public and private keys are encoded as byte strings. The private key is used for signing and must remain secret. The public key is used for verification. It does not need to remain secret, but a verifier must be able to establish that it is trustworthy.
- Signing: The signing operation combines the message with private-key material to generate an ML-DSA signature. The cryptographic process involves hashing and polynomial arithmetic and includes a rejection-sampling process: candidate signatures that do not meet the required conditions are discarded and the process is repeated. For many embedded applications, signing does not need to take place on the embedded device itself. Firmware or FPGA configurations can instead be signed in a controlled development, manufacturing or release environment.
- Verification: The verifier processes Message + Signature + Public Key → ML-DSA Verify → Valid/Invalid. The verification algorithm reconstructs and checks the mathematical relationship between the message, signature and public key. In an embedded system, this cryptographic result is typically only one part of the overall trust decision. Secure boot, for example, may additionally need to check firmware versions, rollback policies or the trustworthiness of the public key.
ML-DSA (NIST FIPS 204) defines three primary operations: KeyGen, Sign and Verify. Key generation creates the key pair, signing stays in the trusted environment, while verification can run on the embedded device. The signature workflow is familiar, but the underlying computation is different from RSA or ECDSA.
5. ML-DSA-44 vs. ML-DSA-65 vs. ML-DSA-87
NIST FIPS 204 defines three ML-DSA parameter sets corresponding to NIST security categories 2, 3 and 5. The categories are standardized security levels that indicate the computational effort required to break a cryptographic algorithm. A higher category represents a higher security level. The parameter sets differ not only in security strength but also in key and signature sizes.
|
Parameter Set |
ML-DSA-44 |
ML-DSA-65 |
ML-DSA-87 |
|
NIST security category |
2 |
3 |
5 |
|
Public Key |
1,312 bytes |
1,952 bytes |
2,592 bytes |
|
Private Key |
2,560 bytes |
4,032 bytes |
4,896 bytes |
|
Signature |
2,420 bytes |
3,309 bytes |
4,627 bytes |
The parameter number should therefore not simply be interpreted as a performance setting such as small, medium and large. The appropriate parameter set is primarily determined by the required security category.
But for embedded developers the resulting sizes matter. Moving from ML-DSA-44 to ML-DSA-87 approximately doubles the signature size and also increases public- and private-key storage requirements. These differences can affect storage, communication protocols, firmware packages, memory usage and hardware resource requirements.
6. What does ML-DSA change for embedded systems?
At application level, ML-DSA performs the same fundamental task as RSA or ECDSA signatures. At implementation level, the differences can be significant.
- Compute architecture: ML-DSA relies heavily on hashing and polynomial arithmetic. This produces a different workload from RSA modular exponentiation or elliptic-curve point arithmetic. Whether software execution is sufficient depends on the processor, verification frequency and required latency. A device that verifies a signature only during a firmware update has very different requirements from a system that continuously authenticates signed data.
- Memory and data sizes: The ML-DSA key and signature sizes shown above are particularly relevant for embedded systems. Larger signatures can affect update packages and communication bandwidth. Larger keys and intermediate values can affect RAM and storage requirements. The important question is therefore not simply: Can the CPU execute ML-DSA? but also: Can the complete system handle its compute, memory and data-movement requirements efficiently?
- Data movement: This becomes particularly relevant when cryptographic operations are accelerated in FPGA or dedicated hardware. Core execution time is only one part of system performance. Memory access, bus transfers, interfaces, DMA setup and synchronization can contribute to end-to-end latency. A faster cryptographic core therefore does not automatically produce the same improvement in overall verification time.
- Crypto agility: Embedded products can remain deployed for many years. PQC migration therefore also raises an architectural question: how easily can algorithms, parameter sets or cryptographic implementations be changed during the product lifetime? Building crypto agility into the system can reduce the impact of future algorithm transitions.
7. How should ML-DSA be implemented?
ML-DSA can be implemented in software, accelerated with dedicated hardware, or implemented as a pure RTL cryptographic function. The appropriate choice depends on the target processor, available memory and FPGA resources, verification frequency, latency requirements, data movement and the required degree of processor independence.
8. When does verification-only make sense?
A separate decision is whether the embedded device needs all three ML-DSA operations at all. Many devices only need to verify digital signatures.
Consider secure boot: firmware can be signed in a separate trusted environment before it reaches the device. The embedded system then only needs the public key and the verification functionality. The same model applies to firmware updates, FPGA configurations, configuration files and authenticated data objects.
A verification-only implementation eliminates key generation and signing functionality from the embedded device. This reduces implementation scope and can reduce the attack surface by removing functionality and interfaces that are not required.
Most importantly, the private signing key does not need to reside on the embedded device. Verification-only is independent of the implementation architecture: verification itself can run in software, be hardware-accelerated or be implemented as a pure RTL cryptographic function.
9. Implementing ML-DSA on FPGA: KiviPQC-DSA
For systems where dedicated ML-DSA hardware is appropriate, KiviCore provides the KiviPQC-DSA IP core family for FPGA- and SoC-based systems. The cores support the ML-DSA parameter sets defined in NIST FIPS 204 and are available in different implementation architectures.
- KiviPQC-DSA Tiny is an area-oriented HW/SW architecture. Dedicated cryptographic processing is combined with a lightweight hardware/software interface, with the architecture designed to reduce the FPGA resources required for ML-DSA acceleration. Whether hardware acceleration improves overall system performance ultimately depends on the complete data path and target platform.
- KiviPQC-DSA Fast implements ML-DSA as a pure RTL architecture. The cryptographic algorithm therefore does not rely on software execution on a host processor. This architecture targets applications where higher cryptographic performance, processor independence or dedicated cryptographic processing is required.
Both architectures can also be provided as verification-only variants for applications such as secure boot and authenticated firmware updates.
10. Conclusion
ML-DSA is one of the key standardized algorithms for the transition to post-quantum digital signatures. NIST FIPS 204 defines three parameter sets ML-DSA-44, ML-DSA-65 and ML-DSA-87 for key generation, signing and verification.
For developers encountering ML-DSA for the first time, its basic purpose is straightforward: it provides the authenticity and integrity properties expected from a digital signature while using a cryptographic construction designed for the post-quantum era. For embedded developers, the next question goes deeper.
Larger keys and signatures, different computational operations, working-memory requirements and data movement mean that ML-DSA may affect more than the cryptographic library itself.
The transition therefore involves two important decisions. Which ML-DSA parameter set provides the required security level and how ML-DSA should be integrated into the target system’s compute, memory and trust architecture.