FN-DSA vs ML-DSA compares the two lattice signature schemes NIST selected in 2022. ML-DSA (from CRYSTALS-Dilithium) became FIPS 204 in August 2024. FN-DSA, NIST's name for Falcon, is being standardized as FIPS 206, which was still a draft in October 2026. Falcon is much more compact; ML-DSA is much easier to implement correctly.
At a glance
| FN-DSA-512 (Falcon-512) | ML-DSA-44 | FN-DSA-1024 (Falcon-1024) | ML-DSA-87 | |
|---|---|---|---|---|
| Security category | 1 | 2 | 5 | 5 |
| Public key | 897 bytes | 1,312 bytes | 1,793 bytes | 2,592 bytes |
| Signature | 666 bytes (padded) | 2,420 bytes | 1,280 bytes (padded) | 4,627 bytes |
| Public key + signature | 1,563 bytes | 3,732 bytes | 3,073 bytes | 7,219 bytes |
| Lattice family | NTRU | Module-LWE / Module-SIS | NTRU | Module-LWE / Module-SIS |
| Signing arithmetic | Floating point (discrete Gaussian sampling) | Integers only | Floating point | Integers only |
| Standard | Draft FIPS 206 | FIPS 204 (final, 2024) | Draft FIPS 206 | FIPS 204 |
| X.509 | Not yet standardized | RFC 9881 | Not yet standardized | RFC 9881 |
Falcon sizes from the Falcon specification (signatures can also use a variable-length compressed encoding of at most 752 and 1,462 bytes); ML-DSA sizes from FIPS 204 Table 2. ML-DSA-65 (category 3) has no Falcon counterpart.
Why size matters
Falcon produces a short vector in an NTRU lattice using a trapdoor and fast Fourier sampling, which yields the smallest public key plus signature of any NIST post-quantum signature: about 1.6 KB at category 1 against 3.7 KB for ML-DSA-44. In a TLS certificate chain, where each certificate carries a public key and a signature and the handshake adds more signatures and SCTs, that difference is the gap between a chain that roughly doubles in size and one that grows fourfold. DNSSEC, where signatures must fit in UDP responses, and blockchains, where every byte costs fees, feel it even more.
Why implementation is the hard part
Falcon's signing algorithm samples from a discrete Gaussian distribution over the lattice using floating-point arithmetic. That creates three problems ML-DSA does not have:
- Constant time. Floating-point operations can take data-dependent time on some CPUs, and emulating them in integers is slow; timing leaks in the sampler have been shown to reveal keys in research attacks.
- Testability. Two correct implementations can produce different signatures for the same input because of rounding, so known-answer tests cannot catch a subtly biased sampler, and a biased sampler still produces valid signatures while leaking key information. In September 2026 NIST's FIPS 206 team proposed a fixed-point signing procedure specifically so that implementations become deterministic and testable.
- Portability. Embedded processors without floating-point units need software emulation, which costs speed and code size.
ML-DSA uses only integer arithmetic modulo 8,380,417 with rejection sampling; it is simple to make constant time and its outputs are fully specified by FIPS 204. Verification is easy for both, and Falcon verifies particularly fast: the Falcon team's reference implementation reports about 27,900 Falcon-512 verifications and 5,900 signatures per second on an Intel Core i5-8259U at 2.3 GHz. On one Apple M4 Max core, OpenSSL 3.6.5's portable ML-DSA-44 code measured about 20,800 verifications and 3,900 signatures per second. The machines differ, so read these as orders of magnitude rather than a head-to-head benchmark.
Standards status
- ML-DSA: final since 13 August 2024 (FIPS 204), with X.509 identifiers (RFC 9881), CMS and OpenPGP profiles, CNSA 2.0 selection (ML-DSA-87) and validated modules.
- FN-DSA: NIST announced it would standardize Falcon in July 2022 and planned FIPS 206 after FIPS 204 and 205. NIST staff said in 2025 that the initial public draft was essentially written and awaiting approval; as of October 2026 no final standard exists, and the September 2026 fixed-point proposal shows the specification is still changing. IETF drafts for FN-DSA in JOSE, COSE and X.509 track the FIPS.
Because FIPS 206 may differ from the Falcon round-3 specification, implementations written today may need changes to match the final standard.
When to choose which
- General-purpose post-quantum signing today: ML-DSA (44 or 65).
- Compliance-driven deployments (FIPS 140-3, CNSA 2.0): ML-DSA; FN-DSA cannot be validated before FIPS 206 is final.
- Certificate-heavy protocols in the future (TLS chains, DNSSEC, constrained IoT updates): track FN-DSA; it is the most likely way to keep signature overhead manageable without changing the protocol structure.
- Hardware without floating point or with strict side-channel requirements: ML-DSA, or Falcon only with a vetted constant-time integer implementation.
- Long-lived roots where size is irrelevant: SLH-DSA, whose security rests on hash functions alone, or ML-DSA; FN-DSA's small signatures buy nothing there.
Migration notes
- Design for algorithm agility: carry algorithm identifiers, avoid fixed signature sizes, and be ready to add FN-DSA as a second post-quantum option next to ML-DSA.
- Prototype with care: use libraries that implement Falcon's sampler in constant time and label their output as pre-standard; do not ship them where a standard is required.
- Measure the size budget of your protocol with ML-DSA today; if it fits, you may never need FN-DSA there.
- Watch the final FIPS 206: parameter names, encodings and the signing procedure may differ from round-3 Falcon, and test vectors will change accordingly.
- Keep hybrids in mind: composite signatures pair a post-quantum scheme with ECDSA or EdDSA during the transition, whichever lattice scheme you pick.