How to Architect a Hybrid Classical/PQC System

A hybrid cryptographic system integrates a classical algorithm (like ECDSA or RSA) with a Post-Quantum Cryptography (PQC) algorithm, running them in parallel. The core architectural principle is algorithm combination, where both algorithms must validate a signature or complete a key exchange for the operation to succeed. This approach, often called hybrid mode, provides cryptographic agility and maintains security against both classical and future quantum computer attacks. Major protocols like TLS 1.3, SSH, and X.509 certificates are adopting this pattern through drafts like RFC 8784 and draft-ietf-tls-hybrid-design.

The most common pattern is hybrid signatures. Here, a single message is signed independently by two algorithms, and the resulting signatures are concatenated into a composite signature. For verification, both component signatures must be valid. For key exchange (KEM), a hybrid KEM pattern is used: the initiator encapsulates two shared secrets—one classical, one PQC—and sends both ciphertexts. The recipient decapsulates both to derive a single shared key, typically using a Key Derivation Function (KDF) like HKDF on the concatenated secrets. This ensures the combined key is secure if either algorithm remains unbroken.

Implementing hybrid cryptography requires careful key management. You must generate, store, and potentially certify two separate key pairs. Libraries like OpenSSL 3.0+ (via providers), liboqs from the Open Quantum Safe project, and AWS libcrypto offer building blocks. A typical flow in a TLS library involves modifying the handshake to negotiate hybrid cipher suites, then using a hybrid callback function to perform the dual signing or KEM operations. Performance is a key consideration, as PQC algorithms like CRYSTALS-Dilithium or FrodoKEM have larger key sizes and slower operations than their classical counterparts.

For developers, the integration points are in the cryptographic primitive layer. Instead of calling sign(ecdsa_key, message), you would call a hybrid signer: hybrid_sign(ecdsa_key, dilithium_key, message). The Open Quantum Safe's OpenSSL integration provides a concrete example, offering hybrid cipher suites such as ECDHE-secp384r1-with-FrodoKEM-1344-SHA384. When architecting your system, plan for algorithm agility: store metadata with keys and signatures to identify the PQC algorithm used, enabling future migration if an algorithm is compromised.

A hybrid PQC system integrates traditional algorithms like ECDSA or RSA with new post-quantum algorithms (e.g., CRYSTALS-Kyber, CRYSTALS-Dilithium) to provide security against both classical and quantum attacks. The primary prerequisite is a cryptographic agility framework. Your system must be designed to support multiple algorithm suites simultaneously, allowing for runtime negotiation, seamless updates, and phased migration. This requires abstracting cryptographic operations behind a well-defined API or service layer, rather than hardcoding specific algorithms.

Key system requirements include access to PQC libraries and development tools. For prototyping and production, you should integrate libraries such as liboqs (Open Quantum Safe) or provider modules from major projects like BoringSSL or OpenSSL 3.0+. Ensure your development environment supports the necessary compilers (e.g., GCC, Clang) and build systems. Performance is a critical consideration; PQC algorithms often have larger key sizes, signature lengths, and higher computational overhead. Benchmark potential algorithms for your specific use case—latency, throughput, and memory usage—on your target hardware, which may range from cloud servers to resource-constrained IoT devices.

Your architecture must define a clear hybrid mode. The most common approach is algorithm combination, where a single operation uses both a classical and a PQC algorithm. For example, a hybrid signature might concatenate an ECDSA signature and a Dilithium signature. Alternatively, you could implement algorithm negotiation via protocols like TLS 1.3, using extensions such as key_share and signature_algorithms to agree on a hybrid suite. You must also plan for key management: generating, storing, and potentially rotating dual key pairs adds complexity to your key lifecycle procedures.

Security and compliance prerequisites are non-negotiable. Your design must adhere to relevant standards from NIST, which is finalizing PQC standards through its Post-Quantum Cryptography Standardization project. Follow their recommendations for approved algorithms and hybrid construction guidelines. Implement robust cryptographic testing, including known-answer tests (KATs) and side-channel analysis where applicable. Furthermore, establish a rollback and disaster recovery plan. If a vulnerability is discovered in a PQC algorithm, your system must be able to gracefully revert to classical-only operations without service interruption.

Finally, consider the operational overhead. You will need monitoring to track the adoption rate of hybrid algorithms and performance metrics. Prepare documentation for internal developers and external auditors that clearly explains the hybrid scheme, its security properties, and failure modes. By addressing these prerequisites—cryptographic agility, library integration, performance profiling, hybrid mode definition, security compliance, and operational planning—you establish a robust foundation for building a future-proof hybrid cryptosystem.

A hybrid classical/PQC system uses two independent cryptographic signatures on every transaction: one from a current standard like ECDSA or Ed25519, and one from a post-quantum algorithm like Dilithium or Falcon. This dual-signature architecture ensures immediate compatibility with existing blockchain infrastructure while simultaneously deploying quantum-resistant cryptography. The system validates that both signatures are cryptographically correct for the transaction to be considered valid. This approach, sometimes called cryptographic agility, allows for a seamless transition, as the network can deprecate the classical signature once PQC algorithms are standardized and their security is battle-tested in production environments.

The core challenge is managing the increased data overhead. PQC signature schemes like ML-DSA (Dilithium) can be 2-20x larger than their classical counterparts, directly impacting transaction size and gas costs. Architecturally, this requires optimizing how signatures are serialized, stored, and verified. A common pattern is to use a compact multi-signature wrapper that bundles the two signatures and their corresponding public keys into a single, efficiently encoded data structure. Smart contracts or protocol nodes must then be upgraded with new verification logic that can parse this wrapper and execute the two distinct verification routines.

Fallback logic is the critical safety mechanism that defines what happens if one signature type fails or is deprecated. A robust system should not have a single point of cryptographic failure. The logic can be configured in several ways: it can require both signatures (AND logic), accept either signature (OR logic), or use a time-based or block-height-based schedule to phase out the classical option. For example, a protocol might enforce dual signatures for 3 years, then switch to requiring only the PQC signature after a governance vote. This logic is typically embedded in the smart contract or core protocol validation rules, providing a clear, auditable path for the cryptographic transition.

Implementing this requires careful key management. A user's wallet must generate and securely store two separate key pairs. The mnemonic phrase or seed should derive both the classical and PQC private keys, ensuring a single backup restores full wallet functionality. Libraries like liboqs from the Open Quantum Safe project provide integrations for hybrid signing. In code, the signing process involves creating the transaction message, generating the ECDSA signature, generating the Dilithium signature, and then bundling them.

solidityCopy
// Pseudocode for hybrid signature verification in a smart contract
function verifyHybridSig(bytes memory message, HybridSig memory sig) public view returns (bool) {
    bool classicalValid = ecrecover(message, sig.v, sig.r, sig.s) == expectedAddress;
    bool pqcValid = dilithiumVerify(sig.pqcPubKey, message, sig.pqcSignature);
    // Fallback logic: currently require both
    return classicalValid && pqcValid;
}

Real-world deployment must consider network upgrades and forks. A hard fork is often necessary to introduce the new signature type and validation rules at the protocol level (e.g., in a blockchain's consensus engine). For smart contract platforms, new contract standards (like an ERC-XXXX for hybrid signatures) can facilitate adoption at the application layer. The transition path involves phases: 1) Optional PQC signatures, 2) Mandatory dual signatures, and 3) PQC-only signatures. Projects like QRL (Quantum Resistant Ledger) have implemented such schemes, providing valuable case studies on transaction size inflation and verification performance impacts, which are crucial for scalability planning.

Ultimately, architecting a hybrid system is about risk management. It protects assets against the future threat of a cryptographically-relevant quantum computer while maintaining interoperability today. The design choices around signature algorithms, bundling format, fallback logic, and upgrade path will define the system's security posture and longevity. Developers should prototype with testnets, using libraries from NIST's PQC standardization process, to gather data on costs and performance before committing to a mainnet deployment strategy.

Hybrid cryptographic systems combine established algorithms like ECDSA with post-quantum cryptography (PQC) algorithms such as Falcon-512. This approach provides security against both current and future quantum attacks. The core architecture involves a smart contract that accepts two signatures for verification: one classical and one PQC. The contract logic requires both signatures to be valid for a transaction to be authorized, ensuring backward compatibility while adding a quantum-resistant layer. This is often implemented using a multi-signature pattern where the signer is the same entity proving control over both key types.

We'll implement this using Solidity and the OpenZeppelin library. First, we need to handle the two signature formats. For ECDSA, we can use OpenZeppelin's ECDSA library. For the Falcon-512 signature, we require an off-chain verifier because Solidity cannot natively perform the complex lattice-based math. The contract will accept a pre-verified Falcon signature digest. The workflow is: 1) User signs a message with both their ECDSA and Falcon private keys off-chain, 2) A relayer calls a precompiled verifier (e.g., a zk-SNARK verifier contract) for the Falcon signature, 3) Our main contract checks the ECDSA signature and the verification result from the Falcon verifier contract.

Here is the skeleton of the hybrid signature verifier contract:

solidityCopy
// SPDX-License-Identifier: MIT
import "@openzeppelin/contracts/utils/cryptography/ECDSA.sol";

contract HybridSigVerifier {
    using ECDSA for bytes32;
    address public falconVerifier; // Address of the precompiled PQC verifier contract

    constructor(address _falconVerifierAddress) {
        falconVerifier = _falconVerifierAddress;
    }

    function verifyHybridSig(
        bytes32 messageHash,
        bytes memory ecdsaSignature,
        bytes memory falconProof,
        address expectedSigner
    ) public view returns (bool) {
        // 1. Verify Classical ECDSA Signature
        address ecdsaRecoveredSigner = messageHash.recover(ecdsaSignature);
        require(ecdsaRecoveredSigner == expectedSigner, "Invalid ECDSA sig");

        // 2. Verify PQC Falcon Signature via external verifier
        (bool falconSuccess, ) = falconVerifier.staticcall(
            abi.encodeWithSignature("verifyFalcon(bytes32,bytes)", messageHash, falconProof)
        );
        require(falconSuccess, "Invalid Falcon PQC sig");

        return true;
    }
}

This contract first recovers the address from the ECDSA signature. It then makes a static call to a separate, pre-deployed falconVerifier contract that contains the logic to validate the Falcon-512 proof. Both checks must pass.

The critical component is the off-chain Falcon-512 signature generation and proof creation. In practice, you would use a library like liboqs or PQClean to generate a Falcon signature over the messageHash. Because this signature cannot be verified directly in the EVM, it must be wrapped into a verifiable proof, such as a zk-SNARK proof generated by a circuit that confirms the Falcon signature is valid. The falconVerifier contract in the example would be the on-chain verifier for that SNARK. This design keeps gas costs manageable by moving the heavy PQC computation off-chain, paying only for the fixed-cost proof verification on-chain.

Key considerations for deployment include key management and migration. Users must securely generate and store both an ECDSA keypair and a Falcon-512 keypair. The contract should also include a mechanism for key rotation, especially for the PQC keys as algorithms and standards evolve. Furthermore, audit the external verifier contract meticulously, as it becomes a single point of failure for the quantum-resistant guarantee. This hybrid pattern is being explored by protocols like EigenLayer for restaking and cross-chain bridges where long-term signature security is paramount.

To test this system, use a local Hardhat or Foundry setup with a mock Falcon verifier. Simulate the complete flow: hash a message, sign it with both algorithms off-chain using test scripts, generate the proof, and submit the transaction to the verifyHybridSig function. Monitor gas costs to optimize. This implementation provides a practical blueprint for integrating PQC today, creating a seamless upgrade path for smart contract security as the quantum computing landscape develops.

A successful hybrid architecture is not just about running two algorithms in parallel. It requires a strategic integration that prioritizes security, performance, and forward compatibility. Your system should be designed to seamlessly transition from classical to post-quantum cryptography (PQC) as standards mature and threat models evolve. The key is to treat PQC not as a replacement, but as a complementary layer that strengthens your overall cryptographic posture against both current and future threats.

For your next steps, begin with a cryptographic inventory. Audit your current system to identify all uses of vulnerable primitives like RSA and ECC for digital signatures and key establishment. For each use case, evaluate the suitability of NIST-standardized PQC algorithms: CRYSTALS-Kyber for key encapsulation and CRYSTALS-Dilithium, Falcon, or SPHINCS+ for signatures. Consider performance characteristics, key/signature sizes, and library maturity (e.g., liboqs, Open Quantum Safe). Prototype the hybrid handshake or signing process in a non-critical environment.

Finally, establish a long-term migration roadmap. Plan for a phased rollout: first deploy hybrid mode in a monitoring-only capacity, then gradually increase reliance on the PQC component while maintaining the classical fallback. Continuously monitor the performance and security landscape, being prepared to update algorithms as newer, more efficient PQC standards are finalized. Resources like the Open Quantum Safe project and NIST's Post-Quantum Cryptography page are essential for staying current. By architecting with agility in mind, you can build systems that are secure for the long term.