💻 computer science

QSecureMail: A QKD-Enhanced Email System with Adaptive Security Policy Engine and Hybrid QKD⊕PQC Encryption

This paper presents QSecureMail, a quantum-safe email system that integrates QKD and post-quantum cryptography within an Adaptive Security Policy Engine to dynamically manage encryption levels, ensure resilience against harvest-now-decrypt-later attacks, and provide transparent security attestation.

Original authors: Swayam Kothekar

Published 2026-08-11

📖 5 min read🧠 Deep dive

CC BY 4.0

Original authors: Swayam Kothekar

Original paper licensed under CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine the internet as a giant, bustling library where everyone sends letters to each other. For decades, we've locked these letters in metal safes using mathematical keys that are so complex, even the smartest computers in the world would take millions of years to crack them. But a new kind of computer is being built—one that uses the weird, magical rules of tiny particles called atoms (quantum mechanics) to think. This new "quantum computer" is like a master locksmith who can pick those old metal safes in the blink of an eye. If someone steals your locked letter today and waits until they have this super-computer, they can unlock it and read your secrets. This is the scary "harvest-now, decrypt-later" problem.

To stop this, scientists are building two new types of locks. The first is a "Post-Quantum" lock, which uses a new kind of math that even the super-computer can't break. The second is a "Quantum Key" system, which uses the laws of physics themselves to create a secret. It's like sending a key inside a fragile glass bubble; if a thief tries to peek at it while it's flying, the bubble shatters, and the sender knows immediately that someone is watching. The big question is: how do we use these new, expensive, and sometimes finicky locks to protect our everyday emails without the system crashing?

Enter QSecureMail, a clever new email system designed by Swayam Kothekar that acts like a smart, adaptive security guard for your digital letters. Instead of forcing every email to use the same heavy-duty lock, QSecureMail uses a special "Adaptive Security Policy Engine" (ASPE) that checks the health of its secret key supply in real-time. Think of the system's secret keys as a bucket of water. If the bucket is full, the system uses the most secure, water-intensive lock (a One-Time Pad) that is mathematically unbreakable. But if the bucket is running low, the ASPE instantly switches to a slightly different, more efficient lock that still keeps your secrets safe but uses less water.

The paper introduces three specific ways to lock your email, depending on how much "water" (keys) is available:

Level 1 (The Super-Lock): This uses a "One-Time Pad," where the key is as long as the message itself. It's the gold standard of security, but it guzzles keys. The system adds a special "tamper-proof seal" (HMAC) to make sure no one can sneakily change the message while it's locked.
Level 2 (The Efficient Lock): If the key bucket is getting a bit low, the system switches to a standard, strong lock (AES-256) that is seeded by a single quantum key. It's fast and uses very few keys.
Level 3 (The Hybrid Lock): This is the paper's big innovation. It combines the quantum key with a "Post-Quantum" math lock (ML-KEM-1024) into a single, fused key. It's like locking a door with two different keys at the same time: even if a thief breaks one of the locks (either the physics one or the math one), the other one still holds. This provides a "defense-in-depth" safety net.

The researchers built a working prototype of this system and ran it through simulations to see how it performed. They found that the "Adaptive Security Policy Engine" works exactly as intended: it successfully manages the key supply, preventing the system from running out of keys during high traffic. In their tests, the system could handle sending emails at different speeds, automatically downgrading from the super-secure Level 1 to the efficient Level 2 or 3 when the key pool got low, and upgrading back when the pool was full.

The results showed some interesting trade-offs. The super-secure Level 1 is incredibly fast for small messages but slows down significantly for large ones because it needs to grab a new key for every tiny chunk of data. In contrast, the new Hybrid Level 3 adds a tiny, fixed amount of time (about 2.5 milliseconds for a small message) to the process, but it uses the same amount of keys regardless of how big the email is. This makes the Hybrid approach very practical for sending lots of emails without draining the quantum key supply.

The paper also highlights that while the system works beautifully in their simulation, it currently relies on a software "simulator" for the quantum hardware rather than a physical machine. The author is clear that this is a proof-of-concept; the real magic will happen when this software is connected to actual quantum key distribution hardware in the real world. They also note that the system currently works best when both the sender and receiver are on the same server, though they have a plan to fix this for the future.

Ultimately, QSecureMail suggests that we don't have to choose between "super-secure but slow" and "fast but risky." By using a smart engine that adapts to the available resources and combining different types of locks, we can build an email system that is ready for the quantum future, keeping our secrets safe from both today's hackers and tomorrow's super-computers.

Technical Summary: QSecureMail

Problem Statement

The advent of quantum computing poses a fundamental threat to classical public-key cryptography, rendering current email systems vulnerable to "harvest-now-decrypt-later" (HNDL) attacks. While Quantum Key Distribution (QKD) offers information-theoretic security and Post-Quantum Cryptography (PQC) offers algorithmic resilience, practical deployment faces a critical bottleneck: resource management. QKD systems generate keys at limited, variable rates, whereas email traffic is unpredictable in volume and size. Existing solutions often fail to bridge the gap between the physical constraints of quantum hardware and the dynamic requirements of email systems, leading to potential service interruptions or inefficient key consumption.

Methodology

The author proposes QSecureMail, an email client system designed to operate over existing infrastructure while integrating QKD and PQC. The system is built on a three-layer architecture: a React/Vite frontend, a Node.js/Express backend, and an ETSI GS QKD 014-compliant Key Management (KM) infrastructure.

Core Components

Adaptive Security Policy Engine (ASPE):
The ASPE acts as the central decision-making layer, dynamically selecting encryption levels based on real-time "pool health" (the ratio of available keys to total pool size). It employs a hysteresis mechanism to prevent rapid oscillation between security levels under fluctuating load conditions. The engine monitors the email send rate ( $\lambda_{email}$ ) and key replenishment rates to calibrate thresholds, ensuring the key pool is not exhausted during high-volume traffic. If the KM system becomes unreachable, the system degrades gracefully to a classical AES-256-GCM mode (Level 4).
Three-Tier Encryption Engine:
The system defines three distinct encryption levels, balancing security guarantees against key consumption:
- Level 1 (Authenticated QKD-OTP): Utilizes a true One-Time Pad (OTP) derived from QKD keys for perfect secrecy, augmented with an HMAC-SHA256 tag for integrity. This level consumes $\lceil|m|/32\rceil + 1$ keys per message, making it highly secure but resource-intensive.
- Level 2 (Quantum-Aided AES-256-GCM): Uses a single 256-bit QKD key to derive an AES session key via HKDF-SHA256. This provides computational security seeded by quantum randomness, consuming exactly one key per email regardless of payload size.
- Level 3 (Hybrid QKD⊕PQC): The novel contribution of the paper. This scheme fuses a QKD-derived key ( $k_{QKD}$ ) with a shared secret from an ML-KEM-1024 (FIPS 203) encapsulation ( $k_{PQC}$ ) using a bitwise XOR operation ( $k_{fused} = k_{QKD} \oplus k_{PQC}$ ). The fused key drives AES-256-GCM encryption. This construction ensures security as long as either the QKD channel remains secure or the PQC algorithm remains unbroken.
Security Attestation:
The system attaches a structured X-QSecureMail-Security-Profile MIME header to every message. This header encodes the encryption level, key identifier fragment, timestamp, and algorithm, enabling transparent auditing of the security posture without requiring decryption.

Key Contributions

The paper identifies four primary contributions:

Adaptive Security Policy Engine (ASPE): An operational layer that manages the trade-off between security and availability. It uses hysteresis and online calibration to prevent key pool exhaustion while preserving Level 1 (OTP) for critical messages when resources permit.
Hybrid QKD⊕PQC Encryption (Level 3): A formalized construction that combines ML-KEM-1024 with ETSI GS QKD 014 keys. The author provides Theorem 1, proving that the fused key is computationally indistinguishable from uniform if at least one of the component keys is uniform, offering defense-in-depth against both mathematical breakthroughs and physical channel attacks.
Authenticated QKD-OTP (Level 1): A construction that resolves the malleability weakness of classical OTPs by authenticating ciphertexts with a separate QKD-derived HMAC key.
Transparent Security Attestation: A mechanism for logging and auditing the quantum security posture of individual emails via standard headers.

Results and Evaluation

The author implemented a reference system and conducted performance evaluations using an in-process KM simulator (simulating QKD hardware via ETSI 014 APIs).

Latency:
- Level 1 (OTP): Latency scales linearly with payload size due to sequential key retrievals. For a 100 KB message, latency averages 1.373 ms.
- Level 2 (QKD-AES): Latency is low and scales minimally with size (0.170 ms for 10 KB), as it requires only one key retrieval.
- Level 3 (Hybrid): Introduces a fixed computational overhead due to ML-KEM-1024 encapsulation. Average latency is approximately 2.2–2.7 ms across all payload sizes (1 KB to 100 KB). This confirms that the hybrid scheme adds a fixed cost rather than a proportional one.
Key Consumption & Pool Sustainability:
- Level 1 consumes approximately 321 keys for a 10 KB email ( $\kappa_1 \approx 321$ ), whereas Levels 2 and 3 consume only 1 key ( $\kappa_{2,3} = 1$ ).
- Simulations show that at a rate of 100 emails/hour, a 1,000-key pool is exhausted in ~1.87 minutes at Level 1, but lasts ~10 hours at Levels 2 and 3. This 321-fold difference validates the necessity of the ASPE's adaptive thresholds.
Correctness: Unit tests confirmed round-trip correctness, ciphertext integrity (tampering detection), key isolation (recipient binding), and the independence of QKD and PQC components.

Significance and Claims

The paper claims that QSecureMail offers a feasible approach to deploying quantum-safe email over existing infrastructure without requiring changes to the underlying email transport protocols (SMTP/IMAP).

Practicality: By decoupling the quantum hardware boundary (ETSI 014 API) from the application logic, the system can integrate with physical QKD hardware as it becomes available.
HNDL Resistance: The use of fresh QKD-derived keys for every message directly addresses the HNDL threat, ensuring that archived ciphertexts cannot be decrypted later even if the adversary eventually acquires a quantum computer.
Defense-in-Depth: The Level 3 hybrid scheme provides a robust fallback; if the PQC algorithm is broken, the QKD component (in hardware configurations) maintains security, and vice versa.
Operational Continuity: The ASPE ensures that the email service remains available even under high load or key scarcity by dynamically downgrading to less resource-intensive encryption levels without compromising the security of critical messages.

The author maintains a modest stance, acknowledging that the current implementation relies on a software KM simulator and that future work must address integration with physical QKD hardware, cross-instance key distribution, and formal verification of the policy engine. However, the architecture demonstrates that a transition to quantum-safe email is achievable using current commodity client hardware and standardized interfaces.