Overview
NIST published its post-quantum standards in August 2024 (FIPS 203, 204 and 205), and its draft transition plan deprecates RSA and ECC at the 112-bit level by 2030. We think IoT is where the switch will be hardest: devices have little memory and power, stay installed for 10 to 15 years, and often talk over IEEE 802.15.4, where a frame is only 127 bytes. Our project asks a simple question: can a small IoT device realistically run the new standards, and what does it cost to switch?
The new algorithms are fast, but what they send is much bigger. An ML-DSA-44 signature is 2,420 bytes against 64 for ECDSA P-256, so a signature that used to fit in one radio frame now needs around 25. Most embedded benchmarks also compare against ECC in software, even though many current chips have ECC in hardware. Our proposal targets both gaps.
Technologies
- - ML-KEM-512/768 (FIPS 203)
- - ML-DSA-44/65 (FIPS 204)
- - ECDH / ECDSA P-256, RSA-2048
- - PSA Crypto API
- - Cortex-M0+ / M4F / M33 boards
- - Python (collection, analysis)
Title slide
The first cost is in bytes
One signature, twenty-five 802.15.4 frames
Three classes of device
What we measure
Timeline
Year
2026
Type
Course Project (CY5120)
Team
Team Online (5)
Role
Team Member
Highlights
We wrote a full research proposal with 21 references and a 20-slide deck covering the threat, the standards, the gap in prior work and a 12-week plan.
We picked one board per constrained-device class: a tiny Cortex-M0+ (STM32L0 class), a mid-range Cortex-M4F (nRF52840 class) and an accelerated Cortex-M33 with CryptoCell (nRF5340).
My part of the work covers the boards and hardware setup, plus SLH-DSA as a stretch goal.
Plan
5 tasks, 12 weeks
Metrics
Memory, speed, bytes, energy
Research Plan
Baseline, then migrate: we first build ECDH P-256, ECDSA P-256 and RSA-2048 on every board behind the PSA Crypto API, then swap in ML-KEM-512/768 and ML-DSA-44/65 behind the same interface so the algorithm is the only thing that changes. Each build has to pass NIST known-answer tests on the board, cross-checked with a Python reference, before anything is timed.
Measure and analyse: many runs per operation, reporting median and 99th percentile, with memory from the linker map, speed from the cycle counter and a hardware timer, bytes and frame counts for the wire, and energy from a power monitor. Python scripts turn the raw output into ratios, charts and a per-device scorecard: fits, tight, or does not fit. HKDF and HMAC are timed as a control; if they differ by more than 3% between builds, we rerun.
Back-up plans: if ML-DSA signing does not fit in the tiny board's RAM, we try a stack-optimised Dilithium or give that device a verify-only role. If an SDK bug blocks a build, we patch and document it. Without a power monitor, we estimate energy from cycle counts and datasheet current. If time runs short, the accelerated and mid-range boards come first and the tiny board becomes a stretch goal.