CTRU-Light and Hybrid-KEM-MQTT

• Title: Lightweight Post-Quantum KEM and Hybrid MQTT Protocol for 8-bit AVR Sensors
• Authors: Yifan Dong, YoungBeom Kim, Jieyu Zheng, Zhichuang Liang, Boyue Fang, Seog Chung Seo, Maire O’Neill and Yunlei Zhao1

Repository Structure

CTRU-Light-and-PQC-on-AVR
├── LICENSE
├── README.md
├── crypto_kem
│   ├── CTRU-Light
│   ├── kyber
│   └── saber
├── hybrid-kem-mqtt
│   ├── CMakeLists.txt
│   ├── auto.sh
│   ├── avr-plugins
│   ├── plugins
│   ├── src
│   └── tests
├── ntt
└── linux

The file structure is illustrated above. The crypto_kem directory contains several versions of CTRU-Light as well as the proposed implementations of Kyber and Saber. The hybrid-kem-mqtt directory contains the security code implementing the KEM and ECC schemes. The ntt directory includes implementations of the basic arithmetic modules. The linux directory includes some build file example for linux environment.

Artifact

This repository contains the artifact accompanying our paper submitted to CHES 2026.
It includes the complete source code, AVR assembly implementations, and benchmark data for CTRU-Light and the Hybrid KEM–MQTT protocol.

The artifact demonstrates:

• Design and implementation of CTRU-Light, a lightweight lattice-based KEM for 8-bit AVR microcontrollers.
• Optimized AVR assembly routines for modular arithmetic, NTT, and inverse NTT.
• Integration of CTRU-Light with ECDH to form a hybrid post-quantum MQTT framework for IoT sensor nodes.
• Experimental results including cycle counts, stack usage, and code size, validated on ATmega1284p and ATmega4808 devices.
• The Hybrid-KEM-MQTT code is tested on x86/64. Due to licensing restrictions, the full porting code for 8-bit AVR is not provided.

All materials are provided to ensure reproducibility, transparency, and practical validation of our results for the CHES 2026 artifact evaluation.

Abstract

The emergence of quantum computing threatens existing public-key cryptosystems, driving the development of post-quantum cryptography (PQC). However, standardized PQC schemes remain too resource-intensive for ultra-constrained platforms such as 8-bit AVR-based wireless sensor nodes in Wireless Sensor Networks (WSNs).

This work presents a comprehensive study toward practical lightweight PQC for such devices, covering scheme design, implementation optimization, and protocol integration. Our contributions are threefold:

1. CTRU-Light (a lattice-based KEM tailored for IoT sensor nodes.)

   • It employs small moduli, low polynomial dimensions, and NTT-friendly arithmetic for efficiency, along with ASCON for lightweight symmetric operations.

2. A general NTT-friendly technique to accelerate modular multiplication.

   • Based on this approach, we introduce NTT-friendly Montgomery and Barrett multiplication.
   • We also formally demonstrate the first equivalence between K-REDX2 and Montgomery multiplication under NTT-friendly moduli, enabling further optimization for small moduli.
   • Applying the NTT-friendly approach to Kyber yields 1–13% performance improvements across KeyGen, Encaps, and Decaps stages while reducing code size by 72.2%.
   • For Saber, the same optimization achieves 24–32% performance gains with a 14.7% reduction in code size.
   • The optimized AVR assembly implementation of CTRU-Light improves KeyGen, Encaps, and Decaps by 2.51×, 1.70×, and 2.52×, respectively.
   • Importantly, CTRU-Light achieves these results without any stack-saving optimization that sacrifices speed, yet still maintains stack usage below 2 KB for KeyGen/Encaps and within 4 KB for Decaps. Hence, our scheme is suitable for deployment on 8-bit sensor nodes.
   • Compared with existing PQC KEMs (Kyber and Saber), CTRU-Light achieves superior performance in both speed and memory efficiency.

3. Hybrid KEM–MQTT protocol.

   • We design a hybrid protocol that integrates classical ECDH with post-quantum KEMs and present the first implementation of hybrid KEM–MQTT.
   • Experiments show that CTRU-Light is the only scheme supporting both pure PQ and hybrid KEM–MQTT on WSNs, with substantially lower handshake latency than Kyber-512 and LightSaber.
   • This highlights that lightweight design is crucial for the practical migration of PQC into WSN communication protocols.

Benchmark Setup

• The code was developed and benchmarked on a Windows environment using Microchip Studio (formerly Atmel Studio).

• All benchmarks were executed using the built-in simulator provided by Microchip Studio. To reproduce the results, open Microchip Studio and create a new project (“New Project”).

• Select the target devices as ATmega4808 (6 KB SRAM) or ATmega1284p (16 KB SRAM), and then include the provided source files in the project. The code is compiled using avr-gcc 14.1.0 with the optimization flag -O3.

• For smooth execution of the full project, we recommend selecting ATmega1284p as the target device due to its larger SRAM.We use an 8-bit AVR version of keccak implementation provided by XKCP-LINK library. For Ascon, we use this Ascon-LINK

  • avr-gnu-toolchain (the results reported in the paper were obtained using the version 14.1.0 available here)

    • If your Microchip Studio installation does not support this toolchain yet, follow the steps here:
    • 1: Scan for Build Tools – scan the environment path and list the language tools installed on the computer.
    • 2: Add – manually add the tool to the list by entering the path to the directory containing the tool executable(s), i.e., base directory. Typically, this is the bin subdirectory in the tool installation directory.
    • 3: If you have more than one version of a compiler available, select one from the list.
    • 4: To change the path of a tool, enter the new path or browse for it.

  • We use the same stack measurement method as described at 2025 CHES-Artifact

• In Properties → Toolchain → AVR/GNU C Compiler → Debugging, we added the flag -fstack-usage under Other debugging flags.
• This generates .su files, which we analyzed using a small Python script stack.py in Debug folder.
• We directly reported the stack consumption for each KEM api.
• For example, in Kyber's keypair, the largest stack is consumed by matacc, so the deepest call chain is kem_keypair → ind_cpa_keypair → matacc → keccak_absorb.
• In this case, We added it directly because it was not calculated properly when the twiddle factor or LUT was on the stack.
  • For code size, refer to the build log. In particular, it reports the total memory used in the text area.
  • For cycle counts, we follow these steps
• Open the project in Microchip Studio and locate the main function.
• Set breakpoints before and after the following three core functions: kem_keygen(pk, sk); kem_enc(pk, k1, ct); and kem_dec(sk, ct, k2);
• Run the project in simulation mode.
• Monitor the "Cycle Counter" in the Processor Status window.
• By subtracting the value at the starting breakpoint from the value at the ending breakpoint for each function, the exact clock cycles consumed by that specific operation are obtained.

Performance: Scheme

• All benchmarks were measured on 8-bit AVR (ATmega1284p) at 20 MHz using avr-gcc 14.1.0 (-O3).
• Cycle counts are shown in kilo-cycles (k-cycles).
• Stack and Code size are shown in Bytes.
• Schemes in bold are proposed in this work.

CTRU-Light

Scheme	keygen	encaps	decaps	keygen stack	encaps stack	decaps stack	code size
Kred-ascon	1514.7	1247.3	2574.7	2351	2463	3028	26572
Montgomery-opt-stack-ascon	1623.2	1277.0	2634.0	2607	2705	3270	27434
Montgomery-opt-flash-ascon	1623.8	1277.7	2635.3	2351	2449	3014	28236
Kred-sha3	1563.1	1236.4	2760.5	2495	2309	2878	42686
Montgomery-opt-flash-sha3	1664.3	1263.8	2798.7	2495	2309	2878	41770
Montgomery-opt-stack-sha3	1663.8	1263.1	2797.4	2751	2565	3134	41008
Montgomery-flash-sha3	1835.7	1332.7	2936.4	2495	2309	2878	43436
C-ref(SHA3)	3688.4	2264.6	5081.9	2351	2321	2886	55998

Kyber512

Scheme	keygen	encaps	decaps	keygen stack	encaps stack	decaps stack	code size
LUT-flash [KS25]	5274	7371	6739	2132	2206	2761	79010
LUT-stack [KS25]	5238	6390	6682	3668	3742	4297	77306
Montgomery	5231	6381	6670	2132	2206	2761	21988

Light-Saber

Scheme	keygen	encaps	decaps	keygen stack	encaps stack	decaps stack	code size
Barrett-flash [HKS25]	9564	13503	14215	10602	11262	11261	62956
Montgomery-flash	7258	10045	9598	10602	11262	11261	55632
Montgomery-stack	7248	10029	9576	11370	12030	12029	53700
Montgomery-speed	5357	7382	7496	10614	11266	11265	28144

Performance: NTT-based Polynomial Multiplication

• All benchmarks were measured on 8-bit AVR (ATmega1284p) at 20 MHz using avr-gcc 14.1.0 (-O3).
• Cycle counts are shown in kilo-cycles (k-cycles).
• † LUTs/zetas placed in flash memory, ‡ LUTs/zetas placed in stack

CTRU-Light

Ring	Implementation	NTT	iNTT	Base Mult	Base Inv
𝑍₇₆₉[x]/(x⁵¹²+1)	Montgomery†	131.1	161.5	117.3	621.4
𝑍₇₆₉[x]/(x⁵¹²+1)	NTT-friendly†	115.0	140.8	101.5	518.9
𝑍₇₆₉[x]/(x⁵¹²+1)	NTT-friendly‡	114.7	140.5	101.6	518.9
𝑍₇₆₉[x]/(x⁵¹²+1)	K-RED2X†	108.1	127.2	99.7	439.4

Ring	Implementation	NTT	iNTT	Base Mult	Base Inv
𝑍₃₃₂₉[x]/(x⁵¹²+1)	Montgomery†	136.3	250.9	144.0	–
𝑍₃₃₂₉[x]/(x⁵¹²+1)	NTT-friendly†	115.0	193.3	102.5	–
𝑍₃₃₂₉[x]/(x⁵¹²+1)	NTT-friendly‡	114.7	193.0	102.5	–

Kyber-512

Ring	Implementation	NTT	iNTT	Base Mult
𝑍₃₃₂₉[x]/(x²⁵⁶+1)	Montgomery‡ [KS25]	67.1	119.3	95.6
𝑍₃₃₂₉[x]/(x²⁵⁶+1)	Signed LUT† [KS25]	62.2	72.4	43.3
𝑍₃₃₂₉[x]/(x²⁵⁶+1)	Signed LUT‡ [KS25]	58.4	67.8	41.2
𝑍₃₃₂₉[x]/(x²⁵⁶+1)	NTT-friendly‡ (This work)	58.1	70.0	38.6

LightSaber

Ring	Implementation	NTT	iNTT	Base Mult
𝑍₃₃₂₉[x]/(x²⁵⁶+1)	Barrett‡ [HKS25]	60.0	163.5	353.7
𝑍₃₃₂₉[x]/(x²⁵⁶+1)	NTT-friendly† (This work)	58.3	80.0	43.2
𝑍₃₃₂₉[x]/(x²⁵⁶+1)	NTT-friendly‡ (This work)	58.1	70.0	38.7

Ring	Implementation	NTT	iNTT	Base Mult
𝑍₇₆₈₁[x]/(x²⁵⁶+1)	Barrett† [HKS25]	70.3	188.7	197.5
𝑍₇₆₈₁[x]/(x²⁵⁶+1)	NTT-friendly† (This work)	67.7	89.6	21.9
𝑍₇₆₈₁[x]/(x²⁵⁶+1)	NTT-friendly‡ (This work)	67.2	91.5	24.3