Testing TLS 1.3 PQC on constrained devices and microcontrollers

Abstract

The UK, EU and US governments have set timelines for post-quantum cryptography migration of critical systems, with deadlines ranging from 2028 to 2035. This paper focuses on IoT-class devices and microcontrollers and the viability of using PQC to connect these devices in secure TLS 1.3 connections. Using wolfSSL, we benchmark a 36-combination TLS 1.3 algorithm matrix, pairing ML-KEM-512/768/1024 and X25519/ECC P-256 key exchange with ML-DSA-44/65/87, Ed25519, ECDSA, and RSA-PSS authentication, across four devices (Raspberry Pi Pico W & Pico 2 W, ESP32, and a Raspberry Pi Zero), measuring both handshake latency and energy consumption. We found that in capable devices, all choices in the TLS matrix gave similar results, but that in IoT-class devices, PQC performance is highly implementation- and architecture-dependent: the common assumption that elliptic-curve key exchange must be cheaper than post-quantum lattice-based key exchange does not hold in this wolfSSL-based implementation, where the best full-PQC combination (ML-KEM-512 + ML-DSA-44) completes TLS handshakes 41% faster than the equivalent classical-modern pairing (X25519 + RSA-PSS) on the Pico W (up to 2.12x as energy-efficient, depending on the paired authentication algorithm), and 8.9x faster on the ESP32. Full-PQC, ML-KEM-512/ML-DSA-44, is not only possible but energy-competitive with or superior to Hybrid or Elliptic Curve alternatives on the most constrained devices, though ML-DSA's variable signing time means applications with strict latency-predictability budgets must accept this variance as the cost of full quantum-safe authentication. We further show that the IETF's draft-specified X25519+ML-KEM-768 hybrid incurs approximately the combined cost of its two components, rather than offering a performance compromise, making pure ML-KEM the more practical choice on hardware lacking Curve25519 assembly support.

Abstract: arXiv descriptive metadata (CC0). Thank you to arXiv for use of its open access interoperability. This service was not reviewed or approved by, nor does it necessarily express or reflect the policies or opinions of, arXiv.