Lightweight Post-Quantum Key Exchange for IoT
ISEF Category: Systems Software
Ready to Turn This Idea Into a Real Project?
This guide was put together with the help of AI research tools to give you a solid starting point. But a competitive science fair project lives in the details: refining your research question, fine-tuning your variables, analyzing your data, and presenting your findings like a seasoned scientist.
For next steps tailored to your interests, skill level, and timeline, work one-on-one with a MehtA+ mentor. Learn more about MehtA+ Science & Engineering Research Mentorship →
Subcategory: Cybersecurity · Difficulty: Advanced · Setup: University Lab · Time: Full Year
The Hook
A tiny sensor node cannot afford a heavy security handshake. Every extra byte and every extra millijoule matters. That makes IoT security a weird race, you need protection that is strong now and still works when quantum computers get better. Your project asks a sharp question, can you build something safer without making tiny devices choke?
What Is It?
This project explores post-quantum key exchange, which is the part of secure communication that lets two devices agree on a shared secret. In simple terms, key exchange is like two people agreeing on the same lock code without sending the code itself in the open. Post-quantum means the method aims to stay safe even if future quantum computers can break many current cryptography schemes.
IoT devices, like sensors and small controllers, have tight limits. They have little memory, small batteries, and slow processors. That means a security method that works fine on a laptop can fail on a microcontroller. Your project tests whether a lightweight design, built from ideas like CSIDH-lite or HQC-style variants, can fit those limits better than standard post-quantum finalists while still giving strong security properties.
The Rust no_std part matters because it strips away the full operating system layer. That can make code smaller and more predictable on embedded hardware. In this project, you are not trying to prove the math from scratch. You are measuring how well a design behaves on real hardware, which is exactly the kind of question systems security research asks.
Why This Is a Good Topic
This is a strong science fair topic because you can measure real tradeoffs, not just read about them. You can compare code size, energy use, run time, and memory footprint, all of which matter for tiny devices. The topic connects to a real problem, securing smart sensors, wearables, and other low-power devices against future attacks. You can learn embedded benchmarking, cryptographic implementation review, and fair comparison design without needing to invent new mathematics.
Research Questions
- How does a lightweight post-quantum key exchange affect code size on a Raspberry Pi Pico?
- What is the effect of using Rust no_std on memory use compared with a fuller embedded build?
- Does a CSIDH-lite style design use less energy than selected NIST PQC finalist implementations on the same board?
- To what extent does key exchange speed change when you switch between algorithm families with similar security goals?
- Which implementation has the best tradeoff between energy cost and code size for IoT devices?
- How does compiler optimization level change the runtime and flash footprint of each key exchange?
- To what extent do repeated handshakes reveal stability differences in timing and energy use?
Basic Materials
- Raspberry Pi Pico or similar microcontroller board
- USB cable and stable power source
- Computer for coding and flashing firmware
- Rust toolchain with embedded support
- Logic analyzer or USB power meter for basic timing or power checks
- Serial monitor for logging benchmark results
- MicroSD card or notebook for organized data recording
Advanced Materials
- Raspberry Pi Pico or similar Cortex-M microcontroller
- Professional power analyzer or high-resolution current probe
- JTAG or SWD debugger
- External crystal oscillator or precision timing source if needed
- Rust embedded benchmarking setup
- Open-source post-quantum cryptography implementations for comparison
- Code size analysis tools from the compiler toolchain
- Test harness for repeated handshake measurements
Software & Tools
- Rust: Builds no_std embedded firmware and lets you measure how implementation choices affect size and speed.
- Cargo: Manages builds, feature flags, and benchmark variants for each cryptography implementation.
- arm-none-eabi toolchain: Compiles and inspects code size for the microcontroller target.
- ImageJ: Can help if you capture current waveform screenshots and want to compare plotted traces by image analysis.
- Python: Cleans benchmark logs, computes summary statistics, and makes plots for energy and runtime comparisons.
Experiment Steps
- Define the exact security and hardware target you will compare, including which key exchange families count as your baseline.
- Choose one primary outcome measure first, then add secondary measures like code size, handshake time, and energy use.
- Build a fair benchmark plan that keeps the board, compiler settings, and test conditions as consistent as possible.
- Decide how you will separate protocol cost from measurement noise, especially for repeated runs on small hardware.
- Plan a comparison table that turns raw measurements into a clear tradeoff view for security, speed, and footprint.
- Predefine the tests that will decide whether one design is better for IoT, so your conclusion does not depend on a single flattering metric.
Common Pitfalls
- Mixing different compiler settings across algorithms, which makes code size and speed comparisons unfair.
- Treating one-off benchmark runs as real evidence, which hides large timing and power variation on embedded hardware.
- Comparing algorithms with different security levels or handshake goals, which weakens the whole conclusion.
- Ignoring flash and RAM limits on the Pico, which can make a method look good until it fails to deploy.
- Measuring energy with a noisy power setup, which can swamp the small differences you are trying to detect.
What Makes This Competitive
A stronger version of this project does more than report which algorithm is fastest. It explains why the tradeoff exists, using fair controls, repeated measurements, and clear statistics. You can stand out by comparing more than one lightweight design, separating code size from runtime, and testing whether your result holds under different compiler settings. A thoughtful embedded systems story plus careful measurement makes the work feel like real research.
Project Variations
- Compare CSIDH-lite style exchange against an HQC-based handshake on the same microcontroller and measure flash size plus energy use.
- Test how different Rust no_std feature flags change the footprint of one post-quantum key exchange implementation.
- Benchmark the same handshake on two embedded boards, then ask how processor architecture changes the tradeoff profile.
Learn More
- NIST Post-Quantum Cryptography Project: Find finalist and standardization documents on the NIST site for algorithm background and performance context.
- Rust Embedded Book: Learn no_std embedded development and find guidance for building firmware on small boards.
- MIT OpenCourseWare, Introduction to Cryptography: Use this for free background on key exchange and modern cryptographic goals.
- PubMed: Search review articles on cryptographic implementation side channels and embedded security constraints.
- arXiv: Search for preprints on post-quantum cryptography, CSIDH, HQC, and IoT-focused benchmarking.
- IEEE Xplore abstracts and author manuscripts: Search for papers on embedded post-quantum cryptography and compare methods reported by researchers.
Systems Software Category Guide
How to Do Real Systems Software Research at Home: A High School Student’s Guide to Free Tools, Affordable Kits, and Public Databases →For next steps tailored to your interests, skill level, and timeline, work one-on-one with a MehtA+ mentor. Learn more about MehtA+ Science & Engineering Research Mentorship →
To discover more projects, visit the MehtA+ Science Fair Project Discovery Hub →
