DEV Community

Quantum Sequrity
Quantum Sequrity

Posted on • Originally published at quantumsequrity.com

Why Hybrid Encryption Matters Blog

Security

Why Hybrid Encryption Matters

13 min read

Why Use Two Locks When One Should Be Enough?

The front door of your house probably has one lock. That works fine for everyday life. But the vault at a bank has a time-lock mechanism, a combination dial, and a physical key requirement. Nuclear missile silos require two officers to turn their keys simultaneously. Airplane cockpit doors have multiple independent locking mechanisms.

The more important something is, the more layers of protection it gets. Cryptographers apply the same principle through something called hybrid encryption: using two completely independent encryption algorithms at the same time, so that an attacker must break both to access the data.

QNSQY combines two key encapsulation algorithms in every encryption operation:

  • ML-KEM: A post-quantum algorithm standardized by NIST as FIPS 203 in August 2024. Based on lattice mathematics that quantum computers cannot efficiently solve.
  • X25519: A classical elliptic curve algorithm designed by Daniel Bernstein in 2006. Used by billions of devices every day for TLS, SSH, Signal, and WhatsApp. Extensively studied for nearly two decades.

The encryption key that protects your file depends on both algorithms. An attacker who breaks ML-KEM but not X25519 still cannot read your data. An attacker who breaks X25519 but not ML-KEM still cannot read your data. Both must fall simultaneously.

The Honest Reason We Need Both

ML-KEM passed one of the most rigorous evaluation processes in cryptographic history: eight years of public scrutiny by the global cryptography community, coordinated by NIST. Hundreds of published papers analyzed its security. Multiple research teams attempted to break it. It survived everything.

X25519 has been deployed in production systems since approximately 2014. It protects a significant fraction of all HTTPS traffic on the internet. Every major browser, operating system, and messaging application uses it. Twelve years of real-world deployment across billions of devices is an extraordinary track record.

So why not just use one of them?

The answer is that cryptography has a history of surprises. Algorithms that appeared secure for years have occasionally fallen to unexpected mathematical breakthroughs. MD5 was considered secure for over a decade before collision attacks were discovered. SHA-1 was used for 15 years before practical collision attacks rendered it obsolete. The NIST Dual_EC_DRBG random number generator was a published standard that turned out to contain a deliberate backdoor.

Nobody expects ML-KEM to have such a flaw. But nobody expected those earlier problems either. And ML-KEM is built on lattice mathematics that, while extensively studied, has been in widespread cryptographic use for a much shorter time than the mathematical foundations of RSA or elliptic curves. There is a nonzero chance, however small, that a breakthrough in lattice cryptanalysis could weaken ML-KEM.

Conversely, X25519 is known to be vulnerable to quantum computers. Shor's algorithm can solve the elliptic curve discrete logarithm problem efficiently. When a sufficiently powerful quantum computer exists, X25519 will be broken. This is not speculation; it is mathematical certainty.

The hybrid approach eliminates both risks:

If ML-KEM Has an Unforeseen Classical Weakness

X25519 still protects your data against classical attackers. This is the scenario where a cryptographer discovers a mathematical shortcut that makes lattice problems easier to solve than expected. Even in this worst case, your data remains protected by a proven algorithm with two decades of analysis behind it.

If a Quantum Computer Breaks X25519

ML-KEM still protects your data. This is the expected scenario: quantum computers will break elliptic curve cryptography. But ML-KEM was specifically designed and evaluated for quantum resistance. Your data remains safe.

How Hybrid Key Combination Actually Works

The technical details of how two key encapsulation results are combined matter, because doing it wrong could undermine the security of the whole construction. QNSQY uses a carefully designed process:

  1. ML-KEM encapsulation runs. This produces a shared secret (let us call it SS1, a 32-byte random value) and a ciphertext that gets stored in the encrypted file.
  2. X25519 key exchange runs independently. This produces a second shared secret (SS2, another 32-byte value) and an ephemeral public key that gets stored in the file.
  3. Your password is processed through Argon2id. This produces a third key component (SS3) derived from your password and a random salt. Argon2id uses 128 MB of memory per iteration, making brute-force attacks against your password economically infeasible.
  4. All three secrets are fed into HKDF-SHA3-256. HKDF (HMAC-based Key Derivation Function) is a standard construction defined in RFC 5869. It takes multiple input key materials and produces a single output key. The critical property: the output is at least as strong as the strongest input. If any one of the three inputs is secure, the output key is secure.
  5. The HKDF output becomes the AES-256-GCM key. This key encrypts the actual file contents. AES-256-GCM provides both confidentiality (nobody can read the data) and authenticity (any modification to the encrypted file is detected).

The mathematical guarantee of this construction is important. Because the final key is derived through HKDF from all three components, an attacker cannot compute the key without knowing all three inputs. Breaking ML-KEM gives them SS1 but not SS2 or SS3. Breaking X25519 gives them SS2 but not SS1 or SS3. Guessing your password gives them SS3 but not SS1 or SS2. They need all three.

The AND Construction vs. the OR Construction

Security engineers distinguish between two types of multi-algorithm constructions, and the difference is critical:

AND construction: The attacker must break Algorithm A AND Algorithm B to succeed. Security is at least as strong as the stronger of the two.

OR construction: The attacker can break Algorithm A OR Algorithm B to succeed. Security is only as strong as the weaker of the two.

QNSQY always uses the AND construction. Both ML-KEM and X25519 must be broken for the key to be compromised. This is the maximum security approach.

An example of the wrong way to do hybrid encryption would be to encrypt the data once with ML-KEM's key and then separately encrypt it again with X25519's key, where either key alone could decrypt the data. That would be an OR construction, and it would actually be less secure than using the stronger algorithm alone, because an attacker only needs to break the weaker one.

The HKDF key combination method used by QNSQY ensures AND semantics. The final AES key depends on all input components. There is no way to "short circuit" the derivation by knowing only one input.

What the Major Security Organizations Say

Hybrid encryption is not a novel idea from any single company. It is the recommended approach from every major security standards body and intelligence agency that has published guidance on the post-quantum transition:

  • NIST (United States): Published SP 800-227 "Recommendations for Key-Encapsulation Mechanisms," which specifically addresses hybrid key establishment combining post-quantum and classical algorithms. NIST acknowledges that hybrid approaches provide "defense in depth during the transition to post-quantum cryptography."
  • NSA (United States): The CNSA 2.0 guidance for National Security Systems recommends a phased transition that begins with hybrid configurations. The NSA recognizes that organizations need the insurance of classical algorithms while post-quantum algorithms accumulate real-world deployment experience.
  • ENISA (European Union): The European Union Agency for Cybersecurity recommends hybrid modes for the transition period, specifically combining NIST-standardized post-quantum algorithms with established classical algorithms.
  • BSI (Germany): Germany's Federal Office for Information Security published Technical Guideline TR-02102, which recommends hybrid key exchange using post-quantum and classical algorithms during the transition period. The BSI is notably conservative; their recommendation of the hybrid approach carries significant weight.
  • ANSSI (France): France's national cybersecurity agency also endorses hybrid approaches, emphasizing that post-quantum algorithms should supplement, not replace, classical algorithms during the transition.

The consensus is unanimous. Every major security authority in the Western world recommends the hybrid approach. The reasoning is always the same: post-quantum algorithms provide quantum resistance, classical algorithms provide decades of proven security, and combining both ensures that a failure in one does not compromise the entire system.

Real-World Hybrid Deployments

Hybrid post-quantum cryptography is not just a theoretical recommendation. It is already deployed in production systems used by billions of people:

Google Chrome and ML-KEM in TLS

In 2024, Google enabled hybrid ML-KEM + X25519 key exchange in Chrome for TLS 1.3 connections. When you visit a website that supports this configuration, your browser performs both a classical X25519 key exchange and a post-quantum ML-KEM key encapsulation. The two shared secrets are combined to produce the TLS session key. Google reported that the ML-KEM operation adds roughly 0.4 milliseconds to the TLS handshake, an amount invisible to users. The larger public key (1,184 bytes for ML-KEM-768 compared to 32 bytes for X25519) adds a small amount to the data transmitted during the handshake but does not measurably affect page load times.

Cloudflare's Post-Quantum Deployment

Cloudflare, which handles a significant percentage of global web traffic, began supporting post-quantum key exchange in its edge network. Their engineering blog documented the deployment of hybrid ML-KEM + X25519 across their infrastructure. Their measurements confirmed that the performance impact is negligible for real-world web browsing, with the slight increase in handshake size offset by the complete absence of additional round-trips.

Signal Messenger

Signal updated its protocol (PQXDH) to include a post-quantum key exchange layer alongside its existing X25519-based protocol. Every new Signal session now uses post-quantum protection, with X25519 providing the classical fallback.

These deployments demonstrate that hybrid encryption is not a theoretical concept or a performance burden. It works at massive scale with no user-visible impact.

Performance: Does Running Two Algorithms Slow Things Down?

This is a reasonable concern, and the answer is: no, not in any way you would notice.

The key encapsulation operations (ML-KEM + X25519) happen once per file, at the very beginning of the encryption process. On a modern computer:

  • ML-KEM-768 key generation + encapsulation takes approximately 70 microseconds total
  • X25519 key exchange takes approximately 120 microseconds
  • HKDF key combination takes approximately 1 microsecond
  • Total hybrid key establishment: under 200 microseconds (0.2 milliseconds)

For context, 200 microseconds is about one five-thousandth of a second. A human blink takes roughly 300,000 microseconds (300 milliseconds). The hybrid key exchange is 1,500 times faster than a blink.

The actual data encryption using AES-256-GCM is where time is spent. AES-256-GCM on modern hardware (with AES-NI instruction set support) processes data at several gigabytes per second. A 100 MB file takes about 30 milliseconds to encrypt. A 1 GB file takes about 300 milliseconds. In both cases, the 0.2 millisecond hybrid key exchange is a negligible fraction of the total time.

The only measurable cost of hybrid encryption is the additional storage space for the ML-KEM ciphertext in the encrypted file header. An ML-KEM-768 ciphertext is 1,088 bytes. An X25519 public key is 32 bytes. The total overhead is roughly 1,120 bytes added to the file. For a 1 MB file, that is 0.1% overhead. For a 100 MB file, it rounds to zero.

What Happens If One Algorithm Is Eventually Broken?

This is the entire point of the hybrid approach, and it is worth spelling out the scenarios explicitly.

Scenario 1: ML-KEM is broken by a classical attack in 2032. A mathematician discovers a shortcut for solving lattice problems. ML-KEM keys can now be recovered in minutes. However, your file is still protected because the AES-256-GCM key was derived from both ML-KEM and X25519. The attacker knows the ML-KEM shared secret but not the X25519 shared secret. Without both, they cannot compute the AES key. Your data remains safe against all classical computers.

Scenario 2: A quantum computer breaks X25519 in 2035. This is the expected outcome. A quantum computer running Shor's algorithm recovers the X25519 shared secret. However, the AES key also depends on the ML-KEM shared secret, which quantum computers cannot recover (that is the entire purpose of ML-KEM). Your data remains safe against quantum computers.

Scenario 3: Both are broken simultaneously. This would require a quantum computer that breaks X25519 AND a classical mathematical breakthrough that breaks ML-KEM, happening at the same time. This is an extraordinarily unlikely combination. But even in this worst case, your password (processed through Argon2id) provides a third independent key component. An attacker would need all three.

Hybrid for Signatures Too: ML-DSA + Ed25519

Hybrid encryption is not only about key encapsulation. Digital signatures face the same quantum threat, and the same hybrid principle applies.

QNSQY uses hybrid signatures for file signing and integrity verification. Every signed file gets two independent signatures:

  • ML-DSA (FIPS 204): A post-quantum lattice-based signature. Resistant to Shor's algorithm.
  • Ed25519: A classical elliptic curve signature. Used by SSH, TLS, and major software distribution systems for over a decade.

A forger must produce valid signatures for both algorithms to fool the verification. If ML-DSA were broken, the Ed25519 signature would still catch the forgery. If a quantum computer breaks Ed25519, the ML-DSA signature would still catch the forgery. The verification only passes when both signatures are valid.

This mirrors the AND construction used for key encapsulation. Just as the encryption key depends on both ML-KEM and X25519, the signature verification depends on both ML-DSA and Ed25519. The security philosophy is consistent across all operations.

When Will We Stop Needing Hybrid?

Hybrid encryption is a transitional strategy. At some point, the cryptographic community will have enough confidence in post-quantum algorithms that the classical component becomes unnecessary overhead. When will that be?

The honest answer is: probably 10 to 20 years from now. Consider the precedent. AES was standardized in 2001. By 2010, it was used everywhere, but many systems still supported older algorithms like 3DES as a fallback. By 2020, most systems had fully transitioned to AES-only. The complete lifecycle from standardization to universal confidence took roughly 20 years.

ML-KEM was standardized in 2024. Following the AES precedent, universal confidence might arrive around 2040 to 2045. Until then, the hybrid approach provides insurance that costs nothing in terms of security and very little in terms of performance.

NIST's guidance explicitly frames hybrid as a transition mechanism. Once post-quantum algorithms have accumulated sufficient deployment experience (measured in years of real-world use at scale), organizations may choose to use post-quantum algorithms alone. But during the transition period, there is no downside to hybrid, and significant upside.

NIST SP 800-227: The Official Hybrid Guidance

NIST addressed hybrid key establishment directly in Special Publication 800-227, "Recommendations for Key-Encapsulation Mechanisms." This document provides specific guidance on how to combine post-quantum and classical algorithms safely.

Key points from the guidance:

  • Hybrid key establishment should combine the shared secrets from both algorithms using a secure key derivation function (like HKDF).
  • The combined key should depend on both components so that compromise of one does not compromise the final key (the AND property).
  • Organizations should maintain hybrid configurations during the transition period until sufficient confidence in post-quantum algorithms has accumulated from real-world deployment.
  • The hybrid approach does not introduce new security weaknesses. The combined system is at least as strong as the stronger individual component.

QNSQY's implementation follows these recommendations exactly: two independent key encapsulations, HKDF combination, AND construction security.

Sources

  1. NIST SP 800-227: Recommendations for Key-Encapsulation Mechanisms (Hybrid Guidance)
  2. Cloudflare: Post-Quantum Cryptography deployment blog
  3. Chromium Blog: ML-KEM deployment in Chrome
  4. Signal: PQXDH (Post-Quantum Extended Diffie-Hellman) Specification
  5. RFC 5869: HMAC-based Extract-and-Expand Key Derivation Function (HKDF)

Related Articles

Double Protection, Zero Hassle

QNSQY automatically uses hybrid ML-KEM + X25519 encryption. You don't need to configure anything.


Originally published at quantumsequrity.com.

Top comments (0)