# FN-DSA-512 (FALCON-512): Compact Lattice Signatures **Source**: https://quantumsequrity.com/blog/fn-dsa-512-deep-dive **Category**: PQC Algorithms --- [← Back to Blog](../../blog.html) PQC Algorithms # FN-DSA-512 (FALCON-512): Compact Lattice Signatures 12 min read If you measure post-quantum signature schemes by signature size alone, FN-DSA-512 wins by a wide margin. Its signatures are roughly 666 bytes. That is smaller than ML-DSA-44 at 2,420 bytes, dramatically smaller than SLH-DSA-128f at 17,088 bytes, and competitive with classical RSA-2048 signatures at 256 bytes. Among NIST-standardized post-quantum signatures, none produces signatures smaller than FN-DSA-512. This compactness comes from a different mathematical foundation than ML-DSA. FN-DSA, formerly known as FALCON, is built on NTRU lattices and uses a unique signing technique called fast Fourier sampling. The trade-off for these compact signatures is implementation complexity. FN-DSA's signing operation requires careful floating-point arithmetic that introduces caveats most other PQ schemes do not have. ## What FN-DSA Stands For FN-DSA stands for Fast Fourier Lattice-based Compact Signatures over NTRU, with DSA appended to indicate the digital signature algorithm. The original submission was named FALCON, an acronym derived from the same words. NIST renamed it FN-DSA when standardizing it. FIPS 206 is currently in draft form. The final standard is expected to publish soon. The 512 in FN-DSA-512 refers to the polynomial degree, not the security category. NIST FN-DSA-512 targets Category 1, equivalent to AES-128 brute-force resistance. Its sibling, FN-DSA-1024, uses degree 1024 and targets Category 5. ## Key and Signature Sizes For FN-DSA-512, key sizes are. Public key is 897 bytes. Secret key is 1,281 bytes. Signature is approximately 666 bytes on average. Signature size varies slightly because the signature includes a Gaussian-sampled vector that compresses based on its magnitude. The signature is variable-length within a defined maximum. FIPS 206 (draft) specifies that the worst-case signature size is bounded but the typical signature is around 666 bytes for Category 1 parameters. Compare to ML-DSA-44, the smallest ML-DSA. Public key 1,312 bytes, signature 2,420 bytes. FN-DSA-512 has a smaller public key (897 vs 1,312) and dramatically smaller signature (666 vs 2,420). FN-DSA's secret key is slightly larger because of the polynomial structure. For applications that transmit many signatures, FN-DSA's compact signature is a major bandwidth advantage. The compactness comes from the underlying NTRU lattice structure, which yields tight short vectors during signing. ## How NTRU Lattices Differ NTRU is a structured lattice family invented in 1996, well before LWE-based lattices. The original NTRU encryption scheme is one of the oldest post-quantum public-key proposals. Its mathematical foundation differs from the Module-LWE used in ML-KEM and ML-DSA. In NTRU, the lattice is generated by a polynomial relation. Specifically, an NTRU lattice has a basis of the form (1, h) and (0, q) where h is a public polynomial and q is the modulus. The trapdoor that lets you sign efficiently is knowledge of two polynomials f and g such that h = g/f mod q. Without f and g, finding short vectors in the NTRU lattice is hard. With them, you can compute short vectors quickly. FN-DSA uses this NTRU lattice as its foundation. The signing key contains f and g. The verification key contains h. Signing involves computing a short lattice vector that hashes the message and the verifier's public key. Verifying involves checking that the signature is short and that it satisfies the verification equation. For more on lattice-based cryptography, see [Lattice-Based Cryptography Explained](../lattice-based-cryptography-explained.html). ## The Floating-Point Caveat The unique aspect of FN-DSA is that signing requires fast Fourier sampling, which uses double-precision floating-point arithmetic. Cryptographers traditionally avoid floating-point in cryptographic code because of three reasons. First, floating-point operations are not always deterministic across hardware. The IEEE 754 standard specifies behavior, but specific compiler optimizations or specific hardware implementations can introduce subtle differences. Cryptographic operations that depend on bit-exact computation can fail or leak when this happens. Second, floating-point operations can introduce timing variance. Some floating-point operations take different time depending on operand values, which is a side-channel risk for cryptographic operations. Third, floating-point computations can leak through subnormal handling, exception flags, and other indirect channels. The FN-DSA design carefully manages all three concerns. It specifies a strictly defined computation procedure that, when executed correctly with IEEE 754-compliant floating-point, produces identical signatures across hardware. The reference implementation includes detailed guidance on which compiler flags to use, which floating-point modes to enable, and how to validate that an implementation produces correct results. The practical consequence is that FN-DSA signing implementations are harder to write correctly than ML-DSA signing implementations. Verification, which uses integer arithmetic only, is straightforward. Signing requires careful attention to floating-point semantics. ## Verification Without Floating-Point The good news is that FN-DSA verification is integer-only. The verifier checks that the signature satisfies an integer polynomial equation modulo q, and that the signature is short. Both checks use only integer arithmetic. This means devices that verify FN-DSA signatures do not need floating-point hardware. Verification can run on microcontrollers, embedded chips, and any environment where integer arithmetic is available. Only signing requires floating-point. In practice, signing is typically done on full server hardware where double-precision floating-point is well supported. Verification happens on whatever device receives the signature, which can be any platform. ## When FN-DSA-512 Wins The compact signature size makes FN-DSA-512 the right choice in several scenarios. DNSSEC at scale. DNS responses must remain compact. Signature schemes with multi-kilobyte signatures cause DNS over UDP to fail and force fallback to TCP, which is slower. FN-DSA-512 signatures fit comfortably within DNS response size budgets. Constrained protocol fields. Some protocols allocate fixed-size fields for signatures. If the field is in the kilobyte range, FN-DSA-512 fits while ML-DSA does not. Bandwidth-sensitive deployments where every byte counts. Satellite communication, low-power radio, and constrained IoT links benefit from FN-DSA's compactness. Long-term archival metadata where many signatures live in tight metadata structures. FN-DSA's small signature lets each archived item carry its signature inline without inflating storage. Certificate transparency style applications where many signatures are aggregated. Smaller signatures mean smaller aggregated structures. ## Where ML-DSA Beats FN-DSA-512 ML-DSA-44 has tradeoffs that make it preferable in many real deployments despite the larger signature size. Implementation simplicity. ML-DSA's signing operation is integer-only. There are no floating-point caveats. Implementing ML-DSA correctly is straightforward. Side-channel resistance. The deterministic and integer-only structure of ML-DSA makes constant-time implementations easier to audit. Performance on diverse hardware. ML-DSA performs predictably across many platforms. FN-DSA performance depends on floating-point hardware quality. For most applications, ML-DSA's larger signature is acceptable in exchange for these simpler implementation properties. NIST's reference implementations and most major cryptographic libraries ship ML-DSA as the default lattice signature. For more on the comparison, see [ML-DSA vs SLH-DSA](../mldsa-vs-slhdsa.html). ## FN-DSA-512 in Hybrid Signing A common pattern is to combine FN-DSA-512 with Ed25519 in a hybrid signing scheme. Ed25519 produces 64-byte signatures and provides classical security. FN-DSA-512 produces 666-byte signatures and provides post-quantum security. The total hybrid signature is roughly 730 bytes, still well below the size of either ML-DSA-44 or SLH-DSA-128f. This combination keeps the on-wire footprint manageable while delivering both classical and post-quantum security. If lattice cryptanalysis ever advances unexpectedly, Ed25519 still protects the signature against classical adversaries during the transition period when FN-DSA might need to be replaced. For more on hybrid signing patterns, see [Hybrid Encryption](../hybrid-encryption.html). ## Performance Characteristics Signing time for FN-DSA-512 on modern x86 hardware with proper double-precision floating-point support is typically a few milliseconds. The fast Fourier sampling step dominates signing time. Verification is dramatically faster, in the tens of microseconds, because it uses only integer operations. Compare to ML-DSA-44, which signs and verifies in tens of microseconds. FN-DSA-512 signs slower than ML-DSA-44 but verifies at similar speed. For workflows where signing is rare and verification is frequent, FN-DSA-512 is excellent. For workflows where signing is the throughput bottleneck, ML-DSA-44 is faster. ## QNSQY Implementation QNSQY's Business tier exposes FN-DSA-512 alongside other post-quantum signatures. The CLI accepts FN-DSA as an algorithm choice on keygen and sign subcommands. Internally, QNSQY uses the FALCON reference implementation, which has been validated against NIST FIPS 206 (draft) test vectors. For users who specifically want compact post-quantum signatures and can tolerate floating-point requirements on signing hardware, FN-DSA-512 is the right choice. The CLI handles all the floating-point setup internally so users do not need to manage compiler flags or hardware configuration. For most QNSQY users, ML-DSA remains the default. FN-DSA is offered for users with specific bandwidth or signature size constraints. ## Side Notes on FALCON-512 vs FN-DSA-512 FALCON-512 is the legacy name from the original NIST submission. FN-DSA-512 is the standardized name in FIPS 206 (draft). The mathematical specification is essentially identical. Implementations validated against FALCON test vectors generally pass FN-DSA test vectors and vice versa. The renaming aligns FN-DSA with the broader NIST PQC naming convention. ML-KEM (formerly Kyber), ML-DSA (formerly Dilithium), SLH-DSA (formerly SPHINCS+), and FN-DSA (formerly FALCON) all share the standardized DSA or KEM suffix. For more on the FALCON to FN-DSA naming history, see [FN-DSA Falcon Explained](../fn-dsa-falcon-explained.html). ## Hardware and Software Considerations For software implementations, the floating-point requirements of FN-DSA-512 mean that platforms with weak or non-IEEE-754-compliant floating-point hardware are unsuitable for signing. Most modern CPUs have full IEEE 754 double-precision support, so this is rarely a concern in practice. For hardware accelerator deployments, FN-DSA-512 signing is harder to accelerate than ML-DSA-44 because of the floating-point step. Hardware accelerators typically use fixed-point arithmetic, which requires careful translation from the floating-point reference. This translation is doable but adds engineering complexity. For embedded device verification (where signing happens elsewhere), FN-DSA-512 is excellent. The integer-only verification runs on any platform with multiplication. Constrained microcontrollers can verify FN-DSA-512 signatures even though they cannot easily sign with FN-DSA. ## FIPS 206 Status As of late 2025 and early 2026, FIPS 206 is in draft form. NIST has published the draft specification and is collecting public comments. The final FIPS 206 standard is expected to publish in late 2026 or early 2027. The technical specification is unlikely to change substantively between draft and final, but small parameter or encoding adjustments are possible. QNSQY tracks the FIPS 206 draft and will update its FN-DSA implementation when the final standard publishes. Users should expect that FN-DSA implementations may have small interoperability adjustments around the FIPS 206 final publication date. For status of the NIST FIPS standards, see [NIST FIPS Guide](../nist-fips-guide.html). ## FAQ ### Is FN-DSA-512 secure if implemented with single-precision floating-point? No. The fast Fourier sampling step requires double-precision floating-point. Single-precision lacks the necessary precision and produces incorrect signatures or, worse, signatures that leak information about the secret key. ### Can I sign with FN-DSA-512 in a constant-time manner? The reference FN-DSA implementation includes a constant-time signing path. Care must be taken to ensure the floating-point operations themselves are constant-time, which requires careful compiler and hardware selection. ### What happens if the signing platform's floating-point produces slightly different results from another platform? The FN-DSA design tolerates small variations in intermediate floating-point results because the final signature is reduced modulo q in integer arithmetic. The variation must remain within bounded ranges defined by the specification. Implementers must validate against published test vectors. ### Why is the signature variable-length? The signature includes a Gaussian-sampled vector, which gets compressed using a length-aware encoding. Vectors with more entropy compress less, vectors with less entropy compress more. The encoding is bit-aligned, so small variations in the underlying vector produce slight differences in encoded length. The compressed signature stays within a maximum bound specified in FIPS 206 (draft). ### Does FN-DSA-512 work for code signing? Yes. FN-DSA-512 is suitable for signing software artifacts. The verifier-side integer arithmetic makes it easy to verify signatures on any platform that runs the signed code. ## Sources 1. [NIST FIPS 206 (Draft): Stateless Hash-Based Digital Signature Standard](https://csrc.nist.gov/publications/detail/fips/206/draft) 2. [FALCON Round 3 Specification, NIST PQC Project](https://falcon-sign.info/falcon.pdf) 3. [NIST PQC Project Resources](https://csrc.nist.gov/projects/post-quantum-cryptography) 4. [IACR Cryptology ePrint Archive on FALCON Signing](https://eprint.iacr.org/2017/438) 5. [NIST FIPS 204: Module-Lattice-Based Digital Signature Standard](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.204.pdf) ## Related Articles - [FN-DSA Falcon Explained](../fn-dsa-falcon-explained.html) - [ML-DSA vs SLH-DSA](../mldsa-vs-slhdsa.html) - [Lattice-Based Cryptography Explained](../lattice-based-cryptography-explained.html) - [Hybrid Encryption](../hybrid-encryption.html) --- ### 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](../../pricing.html)