Hybrid Cryptography: Risk vs. Reward

Many regulators recommend the use of hybrid cryptography as a transitional phase in quantum migration. This would layer post-quantum algorithms on top of classical ones to balance the risks associated with each.

In theory, this can dramatically decrease cryptographic risk exposure. In reality, the situation is more complicated.

Why Hybrid Cryptography is Best Practice

Hybrid cryptography is recommended because it allows organizations to balance two potential risks:

• Broken PQC: Post-quantum cryptographic (PQC) algorithms are in their relative infancy, with far less cryptanalysis than established algorithms like RSA or X25519. Since NIST PQC candidates have been broken with non-quantum hardware, it's possible that ML-KEM and other PQC algorithms will too.
• Quantum Threat: The quantum migration is designed to address the pending threat of cryptographically-relevant quantum computers. When a CRQC becomes available, Shor's algorithm means that classical algorithms like RSA and ECDH will be completely insecure.

Hybrid cryptography provides a level of protection against each of these risks. Data is only at risk if both CRQCs exist and a PQC is broken, assuming correct implementation and a good combiner.

The Downside of Hybrid Cryptography

Hybrid cryptography is designed to address the mathematical risks of the quantum transition. However, the mathematics and logic are rarely where standardized cryptography falls apart. Most algorithms are extensively reviewed before standardization to reduce the risk of this type of break.

In practice, the majority of cryptographic hacks involve custom algorithms (not a concern here) or implementation errors (e.g. the KyberSlash and PQShield timing leaks in ML-KEM implementations). Hybrid cryptography limits the impact of some risks while introducing others, including:

• Higher Bug Likelihood: Cryptography is fragile, and small implementation errors can destroy its effectiveness. Implementing and integrating two algorithms increases the opportunities for logical and implementation errors, since it requires both algorithms and the combiner to be correct, secure, and compatible.
• Insecure Combiners: Hybrid cryptography requires code to combine the two shared secrets, yet this is often left as an exercise for the user (TLS is an exception). Combiners are prone to logical errors, such as XOR combiners introducing dependent key vulnerabilities.
• Side Channel Management: Side channel analysis involves analyzing the runtime, energy usage, and other profiles of a cryptographic algorithm to try to extract sensitive data. Cryptographic code is commonly designed to minimize these clues, but running two algorithms in parallel introduces additional hardening obligations.
• Expanded Dependencies: Cryptographic code should always be implemented using a trusted library to avoid implementation errors and side channel emissions. Hybrid cryptography introduces additional dependencies (OpenSSL, Liboqs, etc.), increasing the difficulty of patch management.
• Bandwidth and Latency: Running two cryptographic algorithms requires sending multiple public keys and ciphertexts over the network, and post-quantum keys and ciphertexts tend to be large. This increases packet sizes, latency, and the risk of dropped connections or denial-of-service (DoS) attack vectors.

Securing the Quantum Transition

Hybrid cryptography is designed to manage the fear that PQC algorithms are quantum-vulnerable or fundamentally flawed. To be fair, algorithms that reached late stages of the NIST PQC contest did turn out to be flawed.

However, this approach also introduces significant risks. Hybrid cryptography introduces new security risks and attack vectors. For example, hybrid signature schemes can be vulnerable to stripping attacks and hybrid key exchange to downgrade attacks, either of which can eliminate the benefits of hybrid cryptography.

To manage the risk, organizations should treat hybrid cryptography as a temporary state, planning a migration to full PQC before CRQCs exist and classical cryptography becomes useless. Additionally, implementations should use trusted libraries and standardized combiners for the integration and perform constant-time testing and end-to-end verification to reduce the risk of implementation flaws.

Educational content, not legal, financial, investment, or professional security advice. Terms