← Back to Blog Research

FIPS 206 (FN-DSA / FALCON): Status

10 min read

Of the four signature schemes NIST chose at the end of the third PQC round, three were finalized as FIPS standards on August 13, 2024. The fourth, FALCON (renamed FN-DSA, the FFT over NTRU lattices Digital Signature Algorithm), has not been published yet: its planned standard, FIPS 206, has not appeared even as a public draft. It is the only one of the four that has not been published, and the reason is interesting: FALCON uses floating-point arithmetic, and floating-point math is hazardous in a security context.

FALCON was selected in 2022, but its standard is still being written. A known difficulty is making its floating-point arithmetic safe and consistent on every platform.

This walkthrough explains where FIPS 206 stands, why floating-point math creates risk, and what teams should do today.

Why NIST Picked FALCON

NIST IR 8413 (the Round 3 report from July 2022) explained the case for FALCON. Compared to ML-DSA, FALCON produces much smaller signatures. A FALCON-512 signature is about 666 bytes. A FALCON-1024 signature is about 1280 bytes. By contrast, ML-DSA-65 signatures are 3309 bytes.

For applications where bandwidth matters (constrained IoT, certificate authorities issuing billions of leaf certs, blockchain transactions), FALCON's compactness is a major advantage. NIST decided the world needed both a workhorse stateless signature (ML-DSA) and a small-signature option (FALCON).

The pairing makes sense. ML-DSA is the default. FALCON is the small-signature alternative. SLH-DSA (FIPS 205) is the conservative hash-based fallback.

Where FIPS 206 Stands

NIST has not yet published FIPS 206, as a draft or as a final standard. Its post-quantum project page (updated August 2026) lists FALCON as "selected for ongoing standardization; that process is underway." The Round 3 report named FALCON as the fourth signature finalist alongside Dilithium (now ML-DSA) and SPHINCS+ (now SLH-DSA). The first three NIST PQC schemes (ML-KEM in FIPS 203, ML-DSA in FIPS 204, SLH-DSA in FIPS 205) became finalized standards on August 13, 2024. FN-DSA was deferred for additional analysis.

NIST calls the FALCON-derived standard "FN-DSA", planned as FIPS 206. It has not announced a publication date.

Section 1: What FALCON Does

FALCON is a digital signature scheme based on the NTRU lattice problem. The acronym expands to "Fast-Fourier Lattice-based Compact Signatures over NTRU." FALCON uses two mathematical techniques that ML-DSA does not:

The NTRU trapdoor for key generation
Gaussian sampling for signing

The Gaussian sampler is what makes the signatures small. ML-DSA uses uniform-distribution rejection sampling, which produces larger signatures. FALCON's Gaussian sampler is more selective, but it requires high-precision arithmetic to avoid leaking information through the sampler's output distribution.

Why Floating-Point Math Creates Risk

FALCON's reference implementation uses double-precision IEEE 754 floating-point. Floating-point hardware varies between CPU architectures. ARM, x86-64, and RISC-V all comply with the IEEE 754 standard, but they differ in:

Subnormal handling
Fused multiply-add (FMA) availability
Rounding mode behavior under exceptions

A signature scheme whose output depends on bit-level rounding behavior can produce different signatures on different hardware. Worse, the differences can leak secret information. If two CPUs produce subtly different distributions, an attacker who collects enough signatures can statistically distinguish between candidate secret keys.

There is also a side-channel concern. Floating-point operations can take varying amounts of time depending on the operands, especially around subnormals and division. Time-variant code is a classic source of timing-attack leaks. Constant-time floating-point is achievable but requires careful coding and testing on every target platform.

Three Workarounds Under Discussion

To address these hazards, researchers and implementers have discussed three approaches:

Mandate constant-time floating-point with documented architecture support
Replace floating-point with fixed-point arithmetic
Use integer-only Gaussian sampling

Approach 1 keeps the original FALCON design but constrains hardware support to a known list. Implementations on a non-supported architecture would be ineligible for FIPS validation.

Approach 2 swaps double-precision floats for fixed-point integers. The challenge is preserving the Gaussian distribution exactly enough that signatures remain indistinguishable from the original spec.

Approach 3, sometimes called "FFsampling integer," redesigns the sampler from the ground up using integer-only operations. This produces signatures slightly larger than the original FALCON but eliminates floating-point hazards entirely.

NIST has not said which approach FIPS 206 will take.

Likely Structure of the Standard

Once finalized, FIPS 206 is expected to follow the same outline as FIPS 203 and 204:

Section 1: Introduction
Section 2: Mathematical conventions
Section 3: Cryptographic functions used
Section 4: Auxiliary algorithms
Section 5: Internal algorithms
Section 6: External algorithms (KeyGen, Sign, Verify)
Section 7: Parameter sets
Annex A: Test vectors

The internal architecture mirrors FALCON Round 3:

NTRU key generation using the lattice trapdoor
Signing using Gaussian sampling driven by SHAKE256
Verification by computing a public-key transformation and checking signature norms

Parameter Sets

FALCON Round 3 defined two parameter sets, expected to carry forward into FIPS 206 as:

FN-DSA-512 (NIST security category 1)
FN-DSA-1024 (NIST security category 5)

Public key sizes are 897 and 1793 bytes. Signatures are 666 and 1280 bytes on average, with some variability since FALCON uses compressed encoding.

There is no mid-level FN-DSA equivalent of category 3. Applications wanting category 3 should use ML-DSA-65 or move up to FN-DSA-1024 directly.

Sources of Authoritative Information

For real-time status, the most reliable sources are:

NIST CSRC PQC project page
NIST workshops on PQC implementation
The IETF LAMPS working group, which is drafting the X.509 algorithm identifiers

Pre-standard FALCON implementations exist (the original FALCON reference and several optimized versions). They will not be byte-for-byte compatible with final FN-DSA. Production code should hold off on FALCON until FIPS 206 is finalized.

For comparison with finalized signature schemes, see ML-DSA vs SLH-DSA, FN-DSA Falcon explained, and our coverage of LMS stateful signatures.

What QNSQY Does Today

QNSQY offers FN-DSA in the Business tier and labels it pre-standard: it implements the FALCON submission, so signatures made today may not interoperate with the final FN-DSA standard. Use it for testing and development, not for long-lived production signatures.

For production signing, QNSQY offers ML-DSA (FIPS 204), with ML-DSA + Ed25519 hybrids on Pro and Business, as described in hybrid encryption. Once FIPS 206 is published, we will update FN-DSA to match it.

The QNSQY Pro tier today supports ML-DSA, SLH-DSA, and Ed25519. Adding FN-DSA gives users the smallest-signature option for bandwidth-constrained workloads, like signing data destined for satellite uplinks or low-power radios.

What Implementers Should Do Now

For new projects, default to ML-DSA-65 (FIPS 204).
For applications that need very small signatures, plan to migrate to FN-DSA after FIPS 206 finalization.
Avoid deploying pre-standard FALCON in production. The byte-level differences between Round 3 and FIPS 206 could break interoperability.
Monitor the NIST CSRC and IETF LAMPS working group for status updates.
Run hybrid signatures (ML-DSA + Ed25519) today; migrate to (ML-DSA + Ed25519 + FN-DSA) once FIPS 206 finalizes if you need extra diversity.

Where Floating-Point Math Bites

To understand the scope of the floating-point hazard, consider what FALCON's Gaussian sampler actually does. Given a center value c and a standard deviation sigma, it returns an integer drawn from a discrete Gaussian distribution. The naive way is to compute exp(-(x-c)^2 / (2 * sigma^2)) for many candidate x values, then sample proportionally.

The exp() function on a floating-point CPU computes via a polynomial approximation. Different CPUs use different polynomial coefficients depending on their micro-architecture. Two CPUs given the same inputs can produce slightly different outputs. The difference is usually tiny, but cryptography is unforgiving. A single bit difference can produce a different signature.

That sounds bad but might not be exploitable. The harder problem is that the timing of exp() varies with input. On x86-64, exp(very small input) takes a different number of cycles than exp(very large input), partly because subnormal numbers cause microcode fallback. An adversary measuring signing time could infer information about the secret key.

Constant-time floating-point is achievable but expensive. It requires manually polling specific instructions, avoiding subnormals, and using fixed rounding modes. Each platform requires audit. The community judged that this overhead, combined with portability concerns, made an integer-only sampler the safer long-term choice.

NIST Updates Worth Watching

NIST holds annual PQC workshops. The talks at these workshops are public and contain the most current status updates on FIPS 206. Look for the NIST PQC Standardization Conference proceedings.

Other public channels:

NIST CSRC PQC project page (linked in Sources)
Public comment periods on draft documents
NIST PQC mailing list announcements
IETF LAMPS working group for X.509 algorithm identifiers

Until FIPS 206 finalizes, treat FN-DSA as experimental.

Why Small Signatures Actually Matter

Some readers question why FN-DSA is worth the wait. ML-DSA-65 signatures at 3309 bytes seem small enough. The answer depends on the use case.

Consider a public certificate authority issuing X.509 certificates. A modern CA processes millions of certificate-signing operations per day. Every leaf certificate stores the issuer's signature. With FN-DSA, the certificate is 2-3 KB smaller than with ML-DSA. Across billions of certificates, that adds up to terabytes of bandwidth and storage savings.

Consider a blockchain that bundles signatures into blocks. With FN-DSA, more transactions fit per block, increasing throughput. With ML-DSA, blocks fill up faster.

Consider a satellite uplink with severe bandwidth constraints. A 666-byte FN-DSA signature uses 70% less channel time than a 2420-byte ML-DSA-44 signature. For low-power IoT devices uplinking through LoRaWAN or similar, the difference is the line between practical and impractical.

These use cases are why NIST persisted with FALCON despite the implementation challenges. Once FIPS 206 finalizes, FN-DSA will fill a niche that ML-DSA cannot.

Comparing FN-DSA to ML-DSA

For applications considering both, the trade-offs are stark:

FN-DSA-512 signature: 666 bytes versus ML-DSA-44 at 2420 bytes (3.6x smaller)
FN-DSA-1024 signature: 1280 bytes versus ML-DSA-87 at 4627 bytes (3.6x smaller)
FN-DSA public key: 897 or 1793 bytes versus ML-DSA at 1312 to 2592 bytes (smaller)

FN-DSA also has a slightly faster signing path on hardware that can run the Gaussian sampler safely, but signing speed advantage is small in absolute terms (microseconds difference).

The pain point: ML-DSA implementations are simpler and harder to misimplement. FALCON/FN-DSA implementations require careful constant-time floating-point work that not every team can afford. For organizations without specialized cryptographic engineering capacity, ML-DSA is the safer default even if signature size matters.

For a side-by-side comparison of all four NIST signatures, see ML-DSA vs SLH-DSA and LMS stateful signatures.

FAQ

When will FIPS 206 be finalized?

NIST has not announced a date, and no public draft has been published yet. Watch the NIST CSRC project page for updates.

Can I use FALCON Round 3 in production?

Pre-standard FALCON implementations exist but should not be used for long-lived signatures. Final FIPS 206 will likely have different byte encoding, breaking interoperability. Use ML-DSA today and migrate later.

What problem does FN-DSA solve that ML-DSA does not?

Smaller signatures. FN-DSA-512 produces 666-byte signatures versus 2420 bytes for ML-DSA-44. For high-volume systems issuing billions of certificates, the size difference matters.

Is FN-DSA quantum-secure?

Yes. The NTRU lattice problem underlying FALCON is believed to be hard for both classical and quantum attackers. The standardization concern is implementation-correctness, not the underlying math.

Why not just standardize FALCON Round 3 as-is?

Because the floating-point dependency makes it hard to validate consistently across hardware platforms. NIST wants every FIPS-validated implementation to produce identical output, which floating-point does not always guarantee.

Sources

NIST IR 8413, Status Report on the Third Round of the NIST Post-Quantum Cryptography Standardization Process, NIST, July 2022
FIPS 204, Module-Lattice-Based Digital Signature Standard, NIST, August 13, 2024
FIPS 205, Stateless Hash-Based Digital Signature Standard, NIST, August 13, 2024
FALCON submission to the NIST PQC project, Round 3, FALCON team
IETF LAMPS Working Group, Composite ML-DSA and FN-DSA in X.509

Protect Your Data Before Q-Day Arrives

QNSQY's NIST-standardized post-quantum encryption protects files against both current and quantum-era threats.

Try QNSQY