How to Evaluate PQC Signature Algorithms for Your Network

Post-quantum cryptography (PQC) refers to cryptographic algorithms designed to be secure against attacks from both classical and quantum computers. The threat stems from Shor's algorithm, which can efficiently break the integer factorization and discrete logarithm problems underpinning today's widely used signatures like ECDSA and EdDSA. For blockchain networks, where digital signatures secure transactions and validator identities, migrating to PQC is a critical long-term security requirement. This guide outlines a framework for evaluating PQC signature candidates based on performance, security, and integration complexity.

Begin your evaluation by defining your system's specific requirements. Key parameters include signature size, public key size, signing speed, and verification speed. For a high-throughput blockchain, verification time is often the most critical bottleneck. Compare these metrics against your current baseline (e.g., a 64-byte ECDSA secp256k1 signature). The NIST PQC standardization process has selected CRYSTALS-Dilithium as the primary signature algorithm, with Falcon and SPHINCS+ as alternates. Dilithium offers a balance of small signatures and fast verification, making it a strong candidate for many blockchain use cases.

Security assessment goes beyond theoretical analysis. Rely on the NIST standardization process and the broader cryptographic community's scrutiny. Review the algorithm's security assumptions, such as the hardness of lattice problems for Dilithium and Falcon, or hash-based security for SPHINCS+. Examine the concrete security levels defined by NIST (e.g., Security Level 1, 3, or 5). For maximum future-proofing, consider algorithms that offer cryptographic agility—the ability to swap out the underlying algorithm without major system changes. This can be achieved through abstracted signing interfaces and modular library design.

Integration complexity is a major practical hurdle. Evaluate the availability and maturity of audited libraries in your stack's language (e.g., liboqs, PQClean). Test the performance in your environment, as PQC operations are generally more computationally intensive than classical ECDSA. A signature from Dilithium2 is about 2,420 bytes, significantly larger than ECDSA's 64 bytes. This impacts transaction size and, consequently, gas costs on networks like Ethereum. Consider hybrid schemes that combine classical and PQC signatures during a transition period, providing defense-in-depth while the PQC algorithms undergo further real-world testing.

Develop a phased testing and deployment strategy. Start with a testnet implementation to gather performance data and identify integration issues. Use this phase to benchmark block propagation times and validator performance. Engage your community or stakeholders through educational initiatives about the upgrade. The transition to PQC is not imminent—current estimates suggest large-scale quantum computers are years away—but the planning and evaluation process is complex and should begin now. Proactive evaluation ensures your network remains secure in the post-quantum era without a last-minute, rushed migration.

The first prerequisite is a clear definition of your evaluation criteria. This goes beyond just performance. You must consider your network's unique constraints: transaction throughput, block size limits, signature verification latency, and hardware capabilities of validators or miners. For example, a high-throughput Layer 2 rollup has different priorities than a resource-constrained IoT blockchain. Document these requirements as they will directly influence your algorithm selection.

Next, establish a testing environment that mirrors your production architecture as closely as possible. This includes the target hardware (CPUs, HSMs), operating systems, and the specific cryptographic library or framework you intend to use, such as OpenSSL 3.0+ with its provider model or the liboqs library from the Open Quantum Safe project. Containerize this environment using Docker to ensure reproducibility. You will need to compile and install the chosen PQC implementations, which often reside in GitHub repositories like open-quantum-safe/openssl or the NIST PQC standardization project's pqc-forum.

Your evaluation setup must include a benchmarking suite. Create scripts to measure the core metrics: signature generation time, verification time, public key size, and signature size. Use a high-resolution timer library for your language (e.g., perf in Linux, time.process_time() in Python). Run each algorithm for thousands of iterations to get statistically significant results. Crucially, test under realistic conditions—signing actual transaction data or block headers, not just random bytes.

Security analysis is a non-negotiable component. While you may not perform cryptanalysis yourself, you must review the security assumptions and attack vectors for each candidate. Rely on the NIST standardization process and academic literature. Pay attention to side-channel resistance—some lattice-based schemes may be vulnerable to timing attacks. Evaluate whether the implementation you are testing includes constant-time code and other mitigations. This step is about understanding the risk profile you are adopting.

Finally, integrate protocol compatibility checks. A PQC signature must work within your existing blockchain protocol's serialization, networking, and state validation logic. Write integration tests to ensure the new signatures can be correctly encoded in transactions, propagated across the peer-to-peer network, and validated by nodes running different client software. This often reveals practical issues with signature size impacting gossip protocol efficiency or changes to the Merkle tree structure for state commitments.

Post-quantum cryptography (PQC) is no longer theoretical; NIST has standardized algorithms like CRYSTALS-Dilithium (lattice-based) and SPHINCS+ (hash-based), while multivariate schemes like Rainbow offer alternative approaches. Evaluating these for your network requires analyzing three core families: Lattice-based signatures (e.g., Dilithium, Falcon) rely on the hardness of problems like Learning With Errors (LWE), offering small signatures and fast verification. Hash-based signatures (e.g., SPHINCS+, XMSS) use cryptographic hash functions and are considered highly secure with minimal assumptions, but often produce larger signatures. Multivariate-based signatures (e.g., Rainbow, GeMSS) are based on solving systems of multivariate quadratic equations and can have very small public keys.

Your evaluation must start with concrete security requirements. For most blockchain applications, targeting NIST security levels 1, 3, or 5 is standard, corresponding to classical security equivalent to AES-128, AES-192, and AES-256. Consider the adversary model: are you protecting against a future quantum adversary, or a classical one today? Next, benchmark the performance characteristics critical to your use case:

• Signature size: Impacts on-chain storage and gas costs (e.g., Dilithium2 ~2.5KB, Falcon-512 ~0.9KB, SPHINCS+-128s ~8KB).
• Verification speed: Crucial for high-throughput networks or light clients.
• Key generation and signing speed: Important for wallet operations and validator nodes.

Integration complexity is a major practical hurdle. Assess the cryptographic agility of your stack—can it support swapping signature schemes later? Review available library support in your language (e.g., liboqs, PQClean) and audit their production readiness. For smart contracts, calculate the real gas cost of signature verification; a large SPHINCS+ signature may be prohibitively expensive on Ethereum Mainnet. Also, consider standardization status: NIST-standardized algorithms (Dilithium, Falcon, SPHINCS+) benefit from wider scrutiny and interoperability, while multivariate schemes are less mature but may offer niche advantages in key size.

Finally, create a decision matrix. For a Layer 1 blockchain prioritizing verification speed and moderate signature size, CRYSTALS-Dilithium is a strong, conservative choice. For high-value, long-lived signatures where size is less critical than proven security, SPHINCS+ is a robust hash-based option. If you need extremely small public keys for identity systems, explore multivariate schemes, but be aware of potential cryptanalytic advances. Always prototype with your exact stack, measure performance under load, and plan for a migration path as the PQC landscape evolves. Your evaluation is not a one-time task but an ongoing component of your network's security posture.

The first step is to establish the performance metrics you will measure. For blockchain networks, latency and throughput are paramount. Key metrics include: signature generation time, signature verification time, public key size, and signature size. For example, the NIST-standardized Dilithium algorithm offers strong security but has a signature size of ~2.5 KB, which directly impacts transaction data overhead. You must also define computational resource metrics like CPU cycles, memory usage, and energy consumption, especially for resource-constrained environments like validators or hardware wallets.

Next, define your test environment and parameters to ensure consistency. This includes specifying the hardware (e.g., AWS c6i.2xlarge instance, Apple M2 chip), operating system, programming language (e.g., Go 1.21, Rust 1.75), and cryptographic libraries (e.g., Open Quantum Safe's liboqs). You must also standardize the payload being signed, such as a 32-byte transaction hash. Crucially, run tests across a range of security levels as defined by NIST (e.g., ML-DSA-44 for Level 1, ML-DSA-65 for Level 3) to understand the trade-offs between security strength and performance.

Finally, incorporate network-specific constraints into your methodology. For a Layer 1 blockchain, you must model the impact of larger signatures on block propagation times and storage requirements. For a Layer 2 rollup, the cost of posting signature data to the base layer (calldata cost on Ethereum) becomes a critical financial metric. Your methodology should simulate real-world conditions, such as benchmarking under sustained load to identify performance degradation or memory leaks. Documenting this methodology transparently allows for reproducible results and informed decision-making in later steps.

Performance measurement is not about theoretical benchmarks but about operational impact. For a blockchain, this translates to three core metrics: signature verification time, signature size, and key size. Verification time directly affects block validation speed and node hardware requirements. Signature and key sizes inflate transaction payloads, increasing gas costs on L1s like Ethereum and bandwidth consumption for all networks. A large key, like some NIST PQC finalist ML-DSA (Dilithium) uses ~2.5KB, must be stored and transmitted by every participant.

To evaluate, you must test in an environment that mimics your production setup. Use a benchmarking suite like Google's benchmark or liboqs. Measure latency (time per operation) and throughput (operations per second) for key generation, signing, and verification. Crucially, run these tests on hardware representative of your validator nodes—be it cloud VMs or consumer-grade hardware. A 10ms verification time may be trivial for a desktop but catastrophic for a high-throughput L1 aiming for sub-second block times.

Here is a simplified example of how you might structure a C++ benchmark for a hypothetical PQC algorithm using a common framework. This measures the critical path: verification.

cppCopy
#include <benchmark/benchmark.h>
#include "pqc_signature.h" // Your PQC library

static void BM_PQC_Verify(benchmark::State& state) {
    PQC_KeyPair keypair = generate_keypair();
    std::vector<uint8_t> message(32, 0xAB); // 32-byte message hash
    std::vector<uint8_t> signature = sign_message(keypair.private_key, message);

    for (auto _ : state) {
        bool isValid = verify_signature(keypair.public_key, message, signature);
        benchmark::DoNotOptimize(isValid); // Prevent compiler optimization
    }
    state.SetBytesProcessed(state.iterations() * message.size());
}
BENCHMARK(BM_PQC_Verify);

BENCHMARK_MAIN();

Run this across thousands of iterations to get stable average and percentile (p99) timings, which are vital for understanding worst-case performance.

Beyond raw speed, analyze the cryptographic overhead. Calculate the percentage increase in transaction size for your network's typical payload. For example, if your current ECDSA signature is 65 bytes, replacing it with a 2,660-byte ML-DSA signature adds ~4KB per transaction. On Ethereum, this could multiply base layer gas costs by 40x or more. For L2s or alternative L1s, this overhead directly reduces transactions per second (TPS) for a given block size limit. Create a model projecting your network's TPS and storage growth under different PQC candidate choices.

Finally, integrate these metrics into a decision matrix. Weight each metric (e.g., verification speed 40%, signature size 30%, library maturity 30%) based on your network's priorities—a high-speed payment network prioritizes latency, while a storage chain cares more about signature size. Score each algorithm (e.g., ML-DSA, SLH-DSA (SPHINCS+), Falcon) against these weighted criteria. This quantitative approach moves the selection from subjective preference to a data-driven engineering trade-off, ensuring the chosen algorithm aligns with your network's long-term performance envelope and economic model.

The security of a PQC algorithm is defined by its NIST security level. This metric estimates the computational effort required to break the algorithm, measured in classical bits of security. For most blockchain applications, Level 1 (≥ 128-bit) is the minimum acceptable baseline for long-term security, with higher levels (e.g., Level 3, Level 5) recommended for high-value systems. You must verify the claimed security level against the latest cryptanalysis from the academic community, not just the algorithm's specification. Resources like the PQClean project and the NIST PQC Project website provide ongoing updates on security analyses.

Standardization status is a key risk indicator. NIST FIPS 203 (ML-DSA), FIPS 204 (SLH-DSA), and FIPS 205 (Falcon) are the first standardized algorithms, offering the highest confidence for production use. Algorithms still in the NIST standardization pipeline or those only standardized by other bodies (e.g., CRYSTALS-Dilithium via NIST, SPHINCS+ as a NIST candidate) carry more implementation and future-proofing risk. For a blockchain, adopting a non-standardized or less-reviewed algorithm increases the chance of needing a costly and disruptive cryptographic migration in the future if vulnerabilities are discovered or standardization paths diverge.

You must also evaluate implementation maturity and side-channel resistance. A theoretically secure algorithm can be vulnerable in practice due to poor implementations. Look for libraries that have undergone extensive auditing and that provide constant-time execution to prevent timing attacks. For example, the liboqs library from Open Quantum Safe offers production-ready, audited implementations of NIST-standardized algorithms. Review the library's documentation for side-channel claims and check for any published CVEs or security advisories related to the specific implementation you plan to use.

Finally, consider algorithm agility—your system's ability to transition to a new algorithm if the primary choice is compromised. Your design should not hardcode a single algorithm. Instead, use a modular architecture where signature schemes are identified by a type byte or version number, allowing validators to agree on a new standard via governance. This is critical in the evolving PQC landscape, where a future cryptanalytic breakthrough cannot be ruled out. Planning for agility from the start is far simpler than retrofitting it into a live network handling billions in assets.

The first major hurdle is library maturity and audit status. For production use, you need a well-tested, audited implementation in your network's primary language (e.g., Go for Geth, Rust for Substrate). Check the liboqs project for C/C++ bindings, or language-specific ports like oqs-java. An unaudited, research-grade implementation from a GitHub fork introduces significant risk. Prioritize libraries that have undergone formal security audits, such as those conducted for NIST finalist algorithms.

Next, analyze the performance impact on node operations. PQC signatures are larger and slower to compute than ECDSA. You must benchmark: key generation time during wallet creation, signing time for block proposals or transactions, and verification time for block validation. For example, a Dilithium2 signature is ~2.5KB, versus 64-72 bytes for ECDSA. This directly increases block size and network bandwidth requirements. Test these operations in a simulated environment to gauge the impact on block propagation times and overall network throughput.

Integration complexity varies by blockchain architecture. For UTXO-based chains like Bitcoin, signature data is part of the transaction witness, making size increases more manageable. For account-based chains like Ethereum, larger signatures affect the gas costs for signature verification in the EVM and the size of the transaction pool. Smart contract platforms must also consider how to expose new precompiles or native functions for PQC verification, requiring a hard fork. Evaluate whether your consensus protocol (e.g., BFT, Proof-of-Stake) has strict timing constraints that could be broken by slower verification.

Finally, plan for a transition and coexistence period. A hard cutover is impractical. Networks need a dual-signature scheme, where transactions are signed with both the classical algorithm (e.g., ECDSA) and the new PQC algorithm during a migration phase. This requires careful protocol design to handle two valid signatures, update wallet software, and educate validators. The complexity of managing this transition, including defining activation heights or fork blocks, is a critical part of the implementation assessment that many theoretical comparisons overlook.

Your evaluation should culminate in a concrete action plan. Begin by formalizing your findings into a PQC Migration Roadmap. This document should detail the chosen algorithm (e.g., CRYSTALS-Dilithium for general signing, SPHINCS+ for hash-based security), justify the selection against your network's specific threat model and performance requirements, and outline a phased rollout strategy. A common approach is a hybrid signature mode, where transactions are signed with both a classical algorithm (like ECDSA) and the new PQC algorithm during a transition period. This maintains backward compatibility while allowing nodes to validate the new scheme.

Next, focus on implementation and testing. Start with a controlled testnet environment. Use libraries from the Open Quantum Safe project or other vetted sources to integrate the PQC algorithm into your node client or smart contract framework. Conduct rigorous benchmarking for signature size, verification speed, and key generation time under realistic network loads. For blockchain applications, pay special attention to how increased signature sizes impact block propagation times and gas costs on networks like Ethereum, where calldata is expensive.

Finally, establish a long-term governance and maintenance protocol. PQC standards are still evolving; NIST may announce additional rounds of standardization. Assign a team to monitor updates from NIST, IETF, and relevant cryptography research forums. Plan for algorithm agility in your system's design—the ability to deprecate and replace the PQC algorithm without a hard fork should a vulnerability be discovered. Your roadmap is a living document that secures your network against the quantum threat, ensuring its resilience for the next decade and beyond.