← Back to Blog Research

FIPS 206 Draft: 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), is still a draft. The draft FIPS standard is designated FIPS 206. It is the only PQC standard that has not yet been finalized, and the reason is interesting: FALCON uses floating-point arithmetic, and floating-point math is hazardous in a security context.

Think of FIPS 206 as a building permit that has been issued but is held up at final inspection. The drawings are complete. The structure stands. But there is a question about the foundation that NIST wants resolved before signing the certificate of occupancy.

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 3293 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 the FIPS 206 Draft Stands

NIST has not yet published a final FIPS 206. 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 has continued to refer to the FALCON-derived standard as "FN-DSA" and identified the document number as FIPS 206 in public talks and presentations. Final publication is expected, with the precise timing tied to resolution of implementation hazards.

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, the FIPS 206 draft and accompanying community work have explored 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 signaled openness to Approach 3 in public communications, but the details are still being finalized. Final FIPS 206 will name a single approach.

Section Structure of the Draft Document

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 currently offers experimental FN-DSA support in the Business tier, gated behind a "draft" flag. Users who enable it understand that signatures generated today will not interoperate with final FN-DSA. We use it for testing and development, not production.

For production signing, QNSQY defaults to ML-DSA-65 (FIPS 204) paired with Ed25519 in hybrid encryption. Once FIPS 206 is final, we will migrate FN-DSA to standard support across Business tier.

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 3293 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 4595 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 committed to a public date. The most recent guidance suggests final publication once the floating-point or alternative-sampler issue is fully resolved. 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