What ML-KEM and ML-DSA Cost on a Chip: Gates, SRAM, Cycles and Years

Post-quantum cryptography usually reaches a chip team as a line in a requirements document: add ML-KEM and ML-DSA. The algorithms have been fixed since NIST published FIPS 203 and FIPS 204 in August 2024, so the open questions are now engineering ones. How many gates, how much SRAM, how many cycles, and what happens to a boot ROM that has to outlive the current signing scheme?

Published numbers now answer much of this, although they use different scopes, libraries and parameter sets. This post puts them side by side, shows where the cost lands, and works through a small budget and a lifetime check you can redo with your own figures.

Key takeaways

• On a large SoC, logic area is rarely the hard part. In the one 5 nm figure published for Adams Bridge, SRAM takes about 73% of the block.
• Average latency is the wrong number for signing. ML-DSA retries until a check passes, so plan for the tail and not only the mean.
• Protection is uneven. Verification handles public data, while signing and decapsulation need masking, and masking's price can appear as area, memory or time.
• The urgent decision is the root of trust. A ROM verifier cannot be patched, and many products will still be in the field after NIST's 2035 date.

Start with the bytes

Everything downstream follows from these sizes, taken from the standards. The P-384 row is the raw encoding. The LMS row is our calculation from the RFC 8554 formats, using one single-tree parameter choice from SP 800-208.

Scheme	Public or encapsulation key (bytes)	Private or decapsulation key (bytes)	Signature or ciphertext (bytes)
ECDSA P-384	96	48	96
ML-KEM-768	1,184	2,400	1,088
ML-KEM-1024	1,568	3,168	1,568
ML-DSA-87	2,592	4,896	4,627
SLH-DSA-SHA2-256s	64	Not shown	29,792
LMS SHA-256/192, height 20, W4	48	Held in the signing module	1,740

Against P-384, an ML-DSA-87 public key is 27 times larger and a signature about 48 times larger. Choosing a parameter set is a market decision too. FIPS 203 recommends ML-KEM-768 as the default, while the CNSA 2.0 list names only ML-KEM-1024 and ML-DSA-87. A block fixed at the top level, as Adams Bridge is, serves the second group but cannot interoperate with a peer that insists on 768.

Area: look at the memory column

These entries differ in scope, library and protection, so they cannot be ranked. They do show the range and the shape.

Design	Scope	Logic	Memory	Status of the figure
Adams Bridge 3.0, unmasked	ML-DSA-87 and ML-KEM-1024	428,497 GE	481,105 GE	Project documentation
Adams Bridge 3.0, masked core and Keccak	Same	648,230 GE	749,814 GE	Project documentation
CAST KiviPQC-Box Fast	All sets, results for the largest	74k gates, 28 nm HPC, 400 MHz	232 KB including ROM	Vendor claim, pre-layout
CAST KiviPQC-Box Tiny	Same	31k gates, 28 nm HPC, 400 MHz	238 KB including ROM	Vendor claim, pre-layout
PQShield PQPerform-Lattice	Typical configuration with both	About 380k gates, GF12LP	Excluded from the figure	Vendor claim, July 2024
Ruhr University Bochum core	ML-KEM decapsulation only	54.1 kGE unmasked, 125.4 kGE first order, NanGate45	Not stated in the abstract	Preprint, 2026

Logic varies by a factor of several for the same algorithms, depending on how much moves to firmware and how much is masked, yet memory stays large. The Adams Bridge specification gives its 5 nm result for the core-masking build as 12,387 µm² of standard cells plus 33,500 µm² of SRAM, about 0.0459 mm² in total. So SRAM takes roughly 73%, and a gate count that excludes memories leaves out most of the silicon.

These figures age quickly too: the same table lists Adams Bridge 2.x at 2,976,864 GE, so the default 3.0 build at 1,398,044 GE is 53% smaller. Our note on balancing PPA trade-offs is a reminder that area is only one axis.

A third route is to extend a crypto coprocessor you already own. The OpenTitan work presented at IEEE S&P 2025 reports a 6 to 9 times speed-up for less than 17% more OTBN cells, and less than 3% across the Earl Grey design. A programmable path costs cycles but keeps room for algorithms that are not finished, such as FIPS 206 and the HQC standard, both still in development at NIST in early November 2026.

Latency: the mean flatters signing

Operation	Adams Bridge 3.0, protected (cycles)	At 600 MHz	pqm4 Cortex-M4, speed build (average cycles)
ML-KEM-1024 key generation	7,441	12 µs	1,018,976
ML-KEM-1024 encapsulation	8,815	15 µs	1,031,565
ML-KEM-1024 decapsulation	11,986	20 µs	1,094,008
ML-DSA-87 key generation	17,428	29 µs	4,275,859
ML-DSA-87 signing	126,937 (four rounds)	212 µs	7,947,380
ML-DSA-87 verification	18,252	30 µs	4,193,104

Adams Bridge cycles come from RTL simulation and exclude loading inputs and reading results back. The pqm4 figures are a microcontroller benchmark, a guide to software cost, not a masked build.

The row to study is signing. FIPS 204 gives expected repetitions of the signing loop as 4.25, 5.1 and 3.85 for ML-DSA-44, 65 and 87. In pqm4's 1,000 runs of ML-DSA-87, the speed build averaged 7,947,380 cycles, but ranged from 4,880,711 to 29,357,607, so the slowest was about 3.7 times the mean.

If each attempt succeeds independently with probability 1 in 3.85, which is our simplifying assumption, the chance of needing more than 16 rounds is 0.81%, and more than 15 is 1.10%. So the 99th percentile is 16 rounds. Adams Bridge lists 29,634 further cycles per protected round, which gives 126,937 + (12 × 29,634) = 482,545 cycles, or about 804 µs at 600 MHz. That is 3.8 times its four-round figure.

Watch the wording on headline numbers as well. PQShield's brief quotes 11,250 cycles for signing, but that is a minimum latency at ML-DSA-44. The Adams Bridge paper's abstract gives three ML-DSA phases of 26, 61 and 31 µs at 600 MHz. The project's own table lists its earlier protected build at 36,700 cycles for one signing round, which is 61 µs, against 146,800 cycles, or 245 µs, for its average. So we read the abstract's 61 µs as one round.

Software offers a memory trade as well. On pqm4, the low-stack ML-DSA-87 build signs with 8,144 bytes of stack instead of 107,892, which is 13 times less, but it averages 33,357,899 cycles, about 4.2 times slower. On the same board, ML-KEM-1024 needs only 7,500 bytes or less, so ML-DSA signing is what sizes the RAM.

Side-channel protection: pay where the secrets are

The Adams Bridge documents state that verification uses no masked operations and is unchanged by protection. That is why a verify-only boot path is so much cheaper than a block that also signs. FIPS 204 notes one exception: verifying confidential messages and signatures needs additional care. Decapsulation and signing are the expensive cases. FIPS 203 treats the implicit-rejection flag as secret, to be destroyed before decapsulation ends, and FIPS 204 warns against its deterministic signing variant on platforms where side-channel attacks are a concern and cannot be otherwise mitigated. Default hedged signing therefore adds a dependency on a random bit generator.

Where the masking bill lands depends on the design:

• Area and memory. In Adams Bridge, core masking raises the total by 43%, and masking Keccak as well brings it to 54%. From the published memory tables, we calculate SRAM capacity rising from about 50 KB to about 89 KB, because a second set of instances holds the other share.
• Time. Adams Bridge says arithmetic masking adds no ML-DSA cycles and at most 2 for ML-KEM, while masked Keccak adds 9% to 11% to signing and 8% to 11% to ML-KEM operations.
• Elsewhere. The Bochum decapsulation core grows 2.3 times in area at first order. A 2024 Nanyang Technological University preprint reports a first-order masked ML-DSA design on FPGA with 1.127 times the LUTs, 1.2 times the flip-flops and 378 times the execution time.

So never quote a masking overhead without saying what it measured. Evidence needs the same care. Adams Bridge reports first-order TVLA leakage from about 5,000 traces for unprotected ML-DSA multiplication, and none up to 1 million traces with masking and shuffling on, though ML-DSA showed minor excursions from about 275,000. That is the project's own testing, on an FPGA at 10 MHz. The Bochum authors report TVLA at first and second order with 10 million traces each. TVLA is a leakage screen, so a pass is not proof against a determined attack.

Read the threat model as closely as the numbers. Adams Bridge states that its ML-KEM protection assumes an ephemeral decapsulation key, used once or with bounded reuse and rotation, and that long-term keys exposed to attacker-chosen ciphertexts are outside the model. The hardware does not enforce this, so the firmware team inherits it. Check this for any IP you license.

A worked budget

The product, die sizes, die costs, volumes, density, clock speeds and flash speed below are illustrative assumptions, not data from any company. Cycle counts and sizes are the published figures above.

The chip boots through three signed stages, then signs one attestation and completes one ML-KEM-1024 exchange using a fresh key pair.

Item	Hardware, 600 MHz	Software, 100 MHz, not masked
3 × ML-DSA-87 verification	54,756 cycles	12,579,312 cycles
1 × signature, average	126,937 cycles	7,947,380 cycles
ML-KEM-1024 key generation	7,441 cycles	1,018,976 cycles
ML-KEM-1024 decapsulation	11,986 cycles	1,094,008 cycles
Total	201,120 cycles, 335 µs	22,639,676 cycles, 226 ms

With the slowest signature pqm4 saw, the software total becomes 44,049,903 cycles, or 440 ms, and that column still lacks masking.

Storage and transfer. Three stages each carry a signature and a public key: 3 × (4,627 + 2,592) = 21,657 bytes, against 576 bytes for P-384. At an assumed 20 MB/s from flash, that is 1.08 ms instead of 0.03 ms. With the accelerator, three verifications take 91 µs, so moving the bytes takes about 12 times longer than checking them.

Silicon. Take the masked-core Adams Bridge build at 1,304,438 GE.

Assumption or result	Server SoC	Low-cost controller
Die area	400 mm²	25 mm²
Block area	0.0459 mm² (published, 5 nm)	0.435 mm² at an assumed 3 MGE/mm²
Share of die	0.011%	1.74%
Die cost and share	$300, so about $0.034	$4, so about $0.070
Yearly volume and total	100,000 units, about $3,400	10 million units, about $696,000

The same block is a rounding error on one product and about 200 times the yearly money on the other. That is the case for a smaller, firmware-heavy design on cost-sensitive parts.

One boundary to design for: FIPS 204 lets implementations cap the signing loop, with a limit of 814 for its loop so that a correct run is not expected to reach it. At 29,634 cycles a round, that is about 24.1 million cycles, or about 40 ms at 600 MHz. Decide what your watchdog and failure path do well before that point.

Migration: count years, not features

NIST IR 8547, finalised in October 2026, says NIST will deprecate quantum-vulnerable public-key algorithms after 2030 and disallow them under its standards and guidelines after 2035. It also records 2030 and 2031 deadlines for the most sensitive US federal systems, for key establishment and signatures respectively. Separately, a March 2026 RSA Conference deck on CNSA 2.0 by Morgan Stern says new National Security System acquisitions must be quantum resistant from 2027, all equipment on those systems should be quantum-resistant capable by 2030, and all such systems should be quantum resistant by 2031, while noting that specific product lines may have their own timelines. The deck adds that new hardware should at least be upgradable, which likely requires a quantum-resistant signature for the root of trust.

A simple check is to add up your own dates. These product timelines are illustrative.

Product type	Tape-out	Last shipment	Field life	Last unit retires	Years past 2035
Data centre accelerator	2027	2031	6 years	2037	2
Automotive SoC	2028	2038	15 years	2053	18
Industrial controller	2028	2039	15 years	2054	19

Urgency differs by job. Key establishment faces harvest now, decrypt later today, as IR 8547 stresses. Signatures only need to resist a forger once one can exist, so they can look less urgent. Silicon reverses that logic, because a root of trust set at tape-out cannot change. For a long-lived chip, the signature decision comes first. If your market includes the EU, set this alongside the Cyber Resilience Act's demands on chip and module makers.

In our reading, these are the decisions to close before tape-out:

1. The ROM verifier. SP 800-208 aims stateful hash-based signatures at long-lived implementations that cannot practically change scheme later, such as firmware authentication, and the CNSA 2.0 list names LMS or XMSS for software and firmware. Verification is built from hashes you probably already accelerate, and the signature in our table is small. The cost moves to the signer: state must be managed carefully, and private keys may not leave the module. ML-DSA-87 and SLH-DSA need no such state but bring more bytes, and ML-DSA a larger verifier.
2. Key slots. Size OTP for a digest of each public key, and reserve spare slots for a second scheme and for revocation.
3. Boot storage and timing. Rework flash layout, mailbox widths and boot budgets, including transfer time.
4. Parameter sets. Write down your target buyers, then check that the block supports what they require.
5. Protection scope. List every secret that passes through the block, whether keys are static or ephemeral, and the attack level you must pass, then require evidence covering that scope.
6. Upgrade path. Keep algorithms changeable in firmware outside the ROM. Standards are still arriving, and FPGA-based cryptographic acceleration is one way to try a new scheme before committing silicon.

Our SoC lifecycle on The Semiconductor Hub shows where these architecture and sign-off decisions fall in a programme.

Sources

• NIST, FIPS 203, FIPS 204 and FIPS 205, 13 August 2024.
• NIST, SP 800-208, "Recommendation for Stateful Hash-Based Signature Schemes", October 2020.
• NIST, IR 8547, "Transition to Post-Quantum Cryptography Standards", October 2026, and the NIST PQC Standardization project page, updated 27 October 2026.
• IETF, RFC 8554, "Leighton-Micali Hash-Based Signatures", April 2019.
• Morgan Stern, "CNSA 2.0 and New Security Requirements", RSA Conference slides, 17 March 2026.
• CHIPS Alliance, Adams Bridge hardware specification, ML-DSA and ML-KEM specifications and side-channel document, version 3.0 documents, repository read 7 November 2026.
• Bisheh-Niasar et al. (Microsoft), "Adams Bridge (V2.0) Accelerator: Bridging the Post-Quantum Transition", IACR ePrint 2026/256, abstract, revised 4 November 2026.
• Buschkowski et al., "A Billion Hard CRYSTALS", IACR ePrint 2026/1265, abstract, revised 16 October 2026.
• Raj et al., "Improved ML-DSA Hardware Implementation With First Order Masking Countermeasure", IACR ePrint 2024/1817, abstract, November 2024.
• Abdulrahman et al., "Towards ML-KEM & ML-DSA on OpenTitan", IEEE S&P 2025, ePrint 2024/1192, abstract.
• mupq, pqm4 benchmarks and README, read 7 November 2026.
• PQShield, PQPerform-Lattice product brief R24.3.1, 12 July 2024 (vendor claims).
• CAST, KiviPQC-Box product page, read 7 November 2026 (vendor claims).

The worked example and product timelines use illustrative numbers. Vendor and project figures are their own claims, as published on the dates shown. This post is engineering planning, not legal or compliance advice.