Overview
Earlier studies found post-quantum crypto faster than elliptic-curve crypto on microcontrollers, but they ran the classical side in software. Many current IoT chips have ECC in hardware. Merlin is a measurement tool that checks whether the earlier result survives that change. It runs on the nRF7002 DK (nRF5340 application core, Cortex-M33) and builds three images from one source tree: P-256 ECDH/ECDSA on the CryptoCell-312 accelerator, P-256 in software (Nordic's Oberon library) as the prior-work condition, and ML-KEM-512/768 with ML-DSA-44/65.
Everything goes through the PSA Crypto API, so the algorithm is the only thing that changes between images. Build-time assertions prove which driver serves each operation, and every image has to pass its known-answer tests on the board before any timing counts.
Technologies
- - C (Zephyr RTOS)
- - nRF Connect SDK v3.4.1
- - PSA Crypto API
- - Arm CryptoCell-312 / nrf_oberon
- - ML-KEM (FIPS 203) / ML-DSA (FIPS 204)
- - DWT cycle counter + TIMER2
- - Python (vector checks, analysis)
Median of 101 timed runs per operation on the nRF5340: CryptoCell ECC vs software ECC vs ML-KEM/ML-DSA
Year
2026
Type
Embedded Research Project
Role
Solo Developer / Researcher
Highlights
Built one firmware tree that compiles into three images (hardware ECC, software ECC, post-quantum) selected only by a config file, with build-time assertions that fail the build if a P-256 operation is routed to the wrong driver.
All three images build with zero warnings and pass their known-answer tests on the real board (SHA-256, HMAC per RFC 4231, HKDF per RFC 5869, and the ML-KEM/ML-DSA vectors), cross-checked on the laptop against two independent Python references.
Found that ML-KEM does not compile through PSA in stock nRF Connect SDK v3.4.1, wrote a contained workaround, and documented it with a Nordic-only reproducer and a bug report.
Board
nRF7002 DK (nRF5340)
Clock
126.6 MHz measured
Runs
5 warm-up + 101 timed
Results
Key establishment: ECDH keygen plus first-use shared secret takes 34.96 ms on CryptoCell and 23.07 ms in software, against 8.48 ms for ML-KEM-512 keygen plus first-use decapsulation. Post-quantum is 4.12× faster than the hardware path and 2.72× faster than software.
Authentication: this is where the accelerator changes the answer. ECDSA P-256 verify takes 11.20 ms on CryptoCell versus 11.39 ms for ML-DSA-44 verify (0.98×, classical slightly faster). Against software ECDSA (25.87 ms) the post-quantum side is still 2.27× faster, so the earlier software-only conclusion does not carry over for signatures.
Whole device workflow: receiving a new key end to end takes 47.70 ms with hardware P-256, 50.55 ms with software P-256 and 22.65 ms with ML-KEM-512 + ML-DSA-44, so post-quantum is still about 2.1× faster overall. A rerun at 64 MHz gave the same ratios.
The cost moves to bytes and memory: one provisioning run sends 346 B on the wire with P-256 and 4,140 B with ML-KEM-512 + ML-DSA-44, and the device stores 149 B versus 1,396 B. Peak stack for the workflow grows from 5,256 B to 12,720 B.
Control check
HKDF/HMAC within 0.3%
Repeat runs
3 power cycles
Method & Lessons from the Hardware
Fairness controls: HKDF-SHA256 and HMAC-SHA256 run identical code in all three images, so their timings must agree within 3%. They agree within 0.3%, which shows the images differ only in the algorithm under test. Each operation reports median, p99, IQR and peak stack, and three power-cycled runs reproduced the device workflow within 0.12%.
Wall time, not just cycles: a TIMER2 wall clock runs next to the DWT cycle counter so that time spent waiting on the accelerator is not undercounted. Early on, the clock was measured while the CPU slept, so it was switched to a busy-wait measurement.
Why CryptoCell loses on ECDH: taking P-256 apart step by step shows CryptoCell spends about 7.3 ms importing and validating each private key, against 16 µs in software, which makes hardware ECDH (20.33 ms) slower than software (11.51 ms). Hardware still wins on ECDSA sign and verify.
Fixes found only on the board: the SDK could not generate ML-KEM or ML-DSA keys through PSA, so Merlin draws a seed and imports it. Console lines were being dropped through the log buffer, and the software image still had P-256 key management on CryptoCell until it was turned off and asserted. ML-DSA signing time also varies widely from run to run (61.06 ms median, 320.59 ms p99 for ML-DSA-44), which is why the headline uses verification.