FALCON vs Dilithium:
Choosing the Right Post-Quantum Signature

NIST selected multiple post-quantum signature algorithms to address different use cases. CRYSTALS-Dilithium (ML-DSA) and FALCON are the two primary choices. Understanding their trade-offs helps you select the right algorithm for your application.

Algorithm Overview

Both algorithms are lattice-based but use different mathematical approaches:

• Dilithium: Based on Module-LWE and Module-SIS problems using "Fiat-Shamir with Aborts"
• FALCON: Based on NTRU lattices using GPV framework with fast Fourier sampling

The distinction matters. Module-LWE and NTRU are both lattice problems, but they rely on different hardness assumptions. A breakthrough against one does not automatically compromise the other, which is precisely why NIST standardized both. Dilithium generates a signature candidate, checks whether it leaks information about the secret key, and aborts if it does. FALCON uses a trapdoor sampler over NTRU lattices with Gaussian distributions in floating-point arithmetic -- producing compact signatures at the cost of implementation complexity.

Key and Signature Sizes

One of the most significant differences is size:

FALCON offers significantly smaller signatures -- roughly 5x smaller than Dilithium at comparable security. This makes FALCON attractive for bandwidth-constrained applications like blockchain transactions or IoT devices. For a certificate chain with three signatures, the cumulative difference is substantial: approximately 9,879 bytes with Dilithium3 versus just 1,998 bytes with FALCON-512.

Performance Characteristics

Performance varies by operation:

• Key Generation: Dilithium is faster (FALCON requires complex precomputation of its NTRU trapdoor basis)
• Signing: Dilithium is faster and more consistent
• Verification: FALCON is faster due to simpler verification arithmetic

Dilithium's signing time is predictable, while FALCON's can vary due to its rejection sampling. This matters for real-time applications with strict latency requirements.

Why Signing Variance Matters

FALCON's Gaussian sampling during signing follows a probabilistic process where each attempt has roughly a 30% success rate. The expected number of iterations is about 3.3, but worst-case signing can take significantly longer. In a high-throughput authentication pipeline processing millions of requests per second, this variance introduces tail latency that complicates SLA guarantees. Dilithium's rejection sampling converges faster, with tighter bounds on the worst case because each iteration is less expensive.

Implementation Complexity

Dilithium is significantly easier to implement correctly:

• Dilithium: Uses simple modular arithmetic over integers, easier constant-time implementation
• FALCON: Requires double-precision floating-point arithmetic and complex tree-based Gaussian sampling, harder to secure against side-channel attacks

For organizations implementing their own cryptographic code, Dilithium presents fewer pitfalls. The entire Dilithium signing algorithm can be expressed in terms of NTT polynomial multiplication, modular addition, and hashing -- operations with well-understood constant-time implementations. FALCON requires a recursive fast Fourier sampler operating in floating-point, where even small precision errors can leak secret key material through timing variations.

Side-Channel Resistance

Side-channel attacks extract secrets by analyzing timing, power consumption, or electromagnetic emissions:

• Dilithium: Designed with side-channel resistance in mind; constant-time implementations are straightforward
• FALCON: More challenging to protect; floating-point operations are notoriously difficult to make constant-time across different CPU microarchitectures

FALCON's reliance on floating-point sampling means that different CPU families (x86, ARM, RISC-V) can produce subtly different timing profiles for the same operation -- a property that makes portable constant-time code exceptionally difficult to write and verify.

NIST Standardization Status

As of early 2026, Dilithium has been finalized as FIPS 204 (ML-DSA) and is the primary NIST recommendation for general-purpose digital signatures. FALCON is standardized as FIPS 206 (FN-DSA), with NIST noting its suitability for applications where signature size is the dominant constraint. Both are approved for federal use, but NIST's guidance explicitly recommends ML-DSA as the default unless there is a specific, documented reason to prefer FN-DSA.

Use Case Recommendations

Based on these trade-offs:

Choose Dilithium when:

• Implementation simplicity is important
• Signing performance and consistency matter
• Side-channel resistance is critical
• Bandwidth isn't severely constrained
• You need FIPS compliance with the primary NIST recommendation

Choose FALCON when:

• Signature and key size are paramount
• Verification speed is more important than signing
• Using well-audited library implementations
• Applications like blockchain or certificates where size matters
• You have access to a hardened, platform-specific implementation

What H33 Uses

H33 uses Dilithium3 (ML-DSA-65) for all authentication attestation signatures in our production pipeline. The reasons align directly with the trade-offs outlined above:

• Predictable latency: Our full-stack authentication -- BFV FHE encryption, ZKP lookup, and Dilithium attestation -- completes in ~42µs per auth on Graviton4. Signing variance from FALCON would introduce unpredictable tail latency at this scale.
• Throughput at scale: H33 sustains 2,172,518 auth/sec on a single c8g.metal-48xl instance. At that rate, each batch of 32 users gets one Dilithium sign+verify cycle taking approximately 244 microseconds -- amortized to under 8 microseconds per user for the signature alone.
• Simpler side-channel protection: Our production pipeline runs on ARM Graviton4 (Neoverse V2). Dilithium's integer-only arithmetic avoids the floating-point side-channel surface that FALCON would introduce on ARM, where FP unit behavior can vary across core revisions.
• NIST's primary recommendation: For general-purpose authentication, ML-DSA is the default standard. We follow NIST guidance unless a compelling technical reason dictates otherwise.

We may add FALCON support for specific use cases where signature size is critical, such as on-chain blockchain attestations where each byte of calldata has a gas cost. For our nested hybrid signature scheme (H33-3-Key), FALCON-512 is already used alongside Dilithium-5 and Ed25519 to provide multi-algorithm resilience -- combining the strengths of both approaches.

Practical Migration Considerations

If you are migrating from classical signatures (RSA or ECDSA) to post-quantum, the choice between Dilithium and FALCON should be driven by three questions:

1. What is your signing volume? High-throughput systems benefit from Dilithium's consistent latency. If you sign fewer than a few thousand messages per second, either algorithm works.
2. What is your transport budget? If you transmit signatures over constrained links (LoRaWAN, Bluetooth LE, satellite), FALCON's 5x smaller signatures can be the deciding factor.
3. Do you control the implementation? If you are using a library (libpqcrypto, liboqs, pqcrypto-rs), either algorithm is safe. If you are implementing from scratch or porting to embedded hardware, Dilithium's simpler arithmetic reduces the risk of subtle bugs.

Future Considerations

Both algorithms are strong choices with different strengths. The cryptographic community continues to analyze both, and neither shows signs of weakness. Your choice should be driven by your application's specific requirements around size, performance, and implementation constraints. For most teams building authentication, API security, or document signing systems, Dilithium is the safer default. For teams optimizing certificate chains, blockchain proofs, or bandwidth-constrained IoT deployments, FALCON earns its place.