For applications that need NIST Category 5 post-quantum signature security but cannot tolerate large signatures, FN-DSA-1024 is the strongest compact option among the standardized post-quantum signatures. Its signatures are approximately 1,280 bytes on average. That is dramatically smaller than ML-DSA-87 at 4,627 bytes and SLH-DSA-256f at 49,856 bytes. Among Category 5 post-quantum signatures, none produces smaller signatures than FN-DSA-1024.
The compactness comes from the same NTRU lattice foundation as FN-DSA-512. The trade-offs are also the same: floating-point arithmetic during signing, careful implementation requirements, and a draft standard (FIPS 206) that is not yet final. This post explains where FN-DSA-1024 fits in real deployments and when it is the right choice.
What 1024 Means
FN-DSA-1024 uses an NTRU lattice with polynomial degree 1024. This is double the degree of FN-DSA-512, which used 512. Doubling the degree roughly doubles all the relevant sizes and security parameters.
The 1024 in the name refers to polynomial degree, not security category. NIST classifies FN-DSA-1024 at Category 5, equivalent to AES-256 brute-force resistance. This matches the strongest tier in NIST's PQC framework.
Key and Signature Sizes
For FN-DSA-1024, byte counts are as follows.
Public key is 1,793 bytes. Secret key is 2,305 bytes. Signature is approximately 1,280 bytes on average. The signature is variable-length but bounded by FIPS 206 (draft) specification.
Compare to ML-DSA-87, the strongest ML-DSA at Category 5. Public key 2,592 bytes, secret key 4,896 bytes, signature 4,627 bytes. FN-DSA-1024 has a smaller public key (1,793 vs 2,592) and dramatically smaller signature (1,280 vs 4,627).
Compare to SLH-DSA-256f at Category 5. Public key 64 bytes, signature 49,856 bytes. SLH-DSA wins on public key size but loses dramatically on signature size.
For protocols that transmit signatures often, FN-DSA-1024 is the most bandwidth-efficient Category 5 option.
Where Compact Signatures at Category 5 Matter
The combination of small signature and high security category is rare. Most schemes at Category 5 either pay in size (SLH-DSA) or in public key (ML-DSA). FN-DSA-1024's compact signatures open use cases that other schemes cannot easily serve.
Long-lived TLS-like protocols where the server certificate is signed at Category 5 and the client must download the full certificate chain. With ML-DSA-87 server certificate signatures, a typical chain is 10-15 KB. With FN-DSA-1024, the chain is 5-8 KB. The difference matters for handshake latency on slow links.
Government records archives that mandate Category 5 signing of every document. Many archived items can carry inline signatures without inflating storage to unmanageable levels.
Long-life-cycle product authentication where the product manufacturer signs each unit's authenticity certificate at Category 5. The certificate must remain compact enough to fit inside product packaging or product serial number databases.
Cryptographic timestamping at Category 5 where each timestamp must be relayed efficiently. Smaller signatures mean smaller timestamp tokens.
DNS responses at the highest security level. Even at Category 5, FN-DSA-1024 signatures fit within DNS over UDP size budgets in many cases, while ML-DSA-87 forces fallback to DNS over TCP.
Implementation Caveats
The same floating-point caveat that applies to FN-DSA-512 applies to FN-DSA-1024. Signing requires fast Fourier sampling using double-precision floating-point arithmetic. The implementation must use IEEE 754-compliant floating-point and verify against published test vectors.
The polynomial degree of 1024 means the floating-point computation is roughly double the work of FN-DSA-512. Signing is thus slower in both raw time and in CPU cycles. On modern x86 hardware with good floating-point support, signing typically takes a few milliseconds.
Verification is integer-only and dramatically faster, typically tens to hundreds of microseconds. The verifier needs no floating-point hardware.
For embedded devices that only verify signatures, FN-DSA-1024 is excellent. The verifier-side integer arithmetic runs on any platform with integer multiplication. For full sign-and-verify roundtrip on resource-constrained hardware, FN-DSA-1024 is harder to deploy than ML-DSA-87.
When FN-DSA-1024 Beats ML-DSA-87
The decision between FN-DSA-1024 and ML-DSA-87 at Category 5 typically comes down to bandwidth versus implementation simplicity.
FN-DSA-1024 wins when bandwidth is constrained. Smaller signatures and smaller public keys translate directly to lower wire and storage costs.
ML-DSA-87 wins when implementation simplicity matters. Integer-only signing, deterministic across hardware, and easier to audit for side-channel resistance.
For server-side signing at scale where signing throughput is critical, ML-DSA-87 is typically preferred for its simpler implementation profile.
For client-side or device-side use where signature transmission is the bottleneck, FN-DSA-1024 is preferred for its compactness.
For applications that practice defense in depth, signing with both ML-DSA-87 and FN-DSA-1024 in a hybrid signing scheme is reasonable. The total signature is roughly 6 KB, still smaller than SLH-DSA-256f alone.
For more on the comparison, see ML-DSA vs SLH-DSA.
NTRU Lattice Foundations
FN-DSA-1024 inherits the same NTRU lattice foundation as FN-DSA-512. The mathematical structure of the lattice is identical at a high level. Only the polynomial degree changes.
The NTRU lattice family is among the oldest post-quantum proposals. NTRU encryption was proposed in 1996 by Hoffstein, Pipher, and Silverman. The mathematical community has studied NTRU lattices for nearly three decades. While NTRU-specific cryptanalysis exists and has produced parameter recommendations over the years, the underlying problems remain hard.
FALCON's specific use of NTRU lattices is more recent, dating from around 2017 when the original FALCON submission to NIST was made. The fast Fourier sampling technique was developed as part of FALCON's design, building on prior work in lattice trapdoor sampling.
The mathematical security analysis of FN-DSA-1024 reflects roughly thirty years of NTRU lattice study. The community is reasonably confident in the underlying problem hardness.
Verification Throughput
For high-throughput verification scenarios, FN-DSA-1024 verification time on modern x86 hardware is in the hundreds of microseconds range, comparable to ML-DSA-87. The integer arithmetic is straightforward and amenable to hardware acceleration.
This makes FN-DSA-1024 suitable for TLS handshake verification at Category 5, server-side document verification, and any verification-heavy workload at the strongest security category.
For verification on constrained hardware like microcontrollers, FN-DSA-1024 is verifiable but takes longer. Microcontrollers typically verify FN-DSA-1024 in tens of milliseconds, which is acceptable for one-shot verification but not for high-throughput verification servers.
Test Vector Validation
NIST has published FIPS 206 (draft) test vectors that any compliant FN-DSA-1024 implementation must reproduce exactly. The test vectors include deterministic key generation outputs, signing inputs and outputs, and verification cases.
QNSQY's FN-DSA-1024 implementation passes all published test vectors. This validation confirms the implementation behaves correctly for the specific cases tested. For applications requiring specific compliance certification, additional validation through accredited testing laboratories may be required, but the test vector validation provides a strong baseline.
QNSQY Implementation
QNSQY's Business tier exposes FN-DSA-1024 alongside other post-quantum signatures. The CLI accepts FN-DSA at the appropriate parameter set when generating keys and signing files.
For users who specifically want compact Category 5 signatures with post-quantum security, FN-DSA-1024 is the natural choice. QNSQY's implementation handles the floating-point requirements internally, so users do not need to manage compiler flags or hardware configuration.
QNSQY validates its FN-DSA-1024 implementation against NIST's FIPS 206 (draft) test vectors. As FIPS 206 finalizes, QNSQY will update the implementation to match any small specification adjustments that emerge between draft and final standards.
For more on QNSQY's algorithm support, see NIST FIPS Guide.
Performance Numbers
On modern x86 hardware with good double-precision floating-point support, FN-DSA-1024 signing takes approximately 5-15 milliseconds depending on hardware and implementation. Verification takes 100-500 microseconds.
ML-DSA-87 on the same hardware signs in roughly 100-300 microseconds and verifies in 50-150 microseconds.
The signing time difference matters when the workload is signing-heavy. ML-DSA-87 can sign roughly 5,000 messages per second on a single core. FN-DSA-1024 can sign roughly 100-200 messages per second on the same core. For high-throughput signing services, this is a major operational difference.
For verification-heavy or low-volume signing workloads, the throughput difference is invisible. Most applications fall into this category.
Hardware and Software Considerations
The floating-point requirements of FN-DSA-1024 are the same as FN-DSA-512 but at larger polynomial degree. Signing requires IEEE 754-compliant double-precision floating-point arithmetic with carefully managed semantics. Modern x86 and ARM CPUs all meet these requirements.
For hardware accelerator deployments, FN-DSA-1024 signing is harder to accelerate than ML-DSA-87 because of the floating-point step. Hardware accelerators typically use fixed-point arithmetic, which requires translating the floating-point reference into a fixed-point implementation that produces bit-identical results. This translation is doable but adds engineering complexity.
For embedded device verification (where signing happens elsewhere on a server), FN-DSA-1024 is excellent. The integer-only verification runs on any platform with integer multiplication. Constrained microcontrollers can verify FN-DSA-1024 signatures even though they cannot sign with FN-DSA.
Side-Channel Considerations
FN-DSA-1024 signing has unique side-channel considerations because of the floating-point step. Floating-point operations can introduce timing variance that depends on operand values. The fast Fourier sampling step can leak information through cache behavior or power analysis if implemented carelessly.
The reference FN-DSA implementation includes a constant-time signing path that mitigates these concerns. Implementers using the reference implementation get reasonable side-channel resistance baseline. Production deployments should perform additional side-channel testing on their target hardware.
Verification is integer-only and follows standard constant-time discipline. Side-channel risks during verification are similar to other lattice-based verification operations.
QNSQY's FN-DSA-1024 implementation uses the reference constant-time signing path and has been validated against published side-channel test vectors.
Library and Ecosystem Support
FN-DSA-1024 (formerly FALCON-1024) is supported by major cryptographic libraries. The reference implementation provides the baseline. OpenSSL providers, libsodium extensions, and language-specific cryptographic packages have integrated FN-DSA support.
Browser support is emerging. As FIPS 206 finalizes, browser vendors are expected to roll out support for FN-DSA in TLS certificate verification. The compactness advantage of FN-DSA over ML-DSA at Category 5 is a meaningful benefit for browser handshake bandwidth.
For operating systems, FN-DSA support is being added to system cryptographic libraries. Linux kernel cryptographic API, Windows CNG, and macOS CryptoKit all have or are adding FN-DSA support.
QNSQY's CLI uses the reference FN-DSA-1024 implementation and provides a consistent interface across operating systems.
Compact Hybrid with Ed25519
A useful hybrid signing pattern combines FN-DSA-1024 with Ed25519. Ed25519 provides 64-byte signatures and classical security. FN-DSA-1024 provides 1,280-byte signatures and post-quantum Category 5 security. The combined hybrid signature is roughly 1,344 bytes.
This combination is the smallest practical post-quantum-plus-classical hybrid signature available. It serves applications that want both classical and post-quantum security at high security category without exploding signature size.
QNSQY supports this hybrid signing pattern. Users can request a hybrid signature that includes both Ed25519 and FN-DSA-1024 components.
For more on hybrid encryption and signing patterns, see Hybrid Encryption.
FAQ
How does FN-DSA-1024 compare to RSA-4096 in size and performance?
RSA-4096 produces 512-byte signatures and signs slower than FN-DSA-1024. FN-DSA-1024 has post-quantum security; RSA-4096 does not. For Category 5 PQC signing at compact size, FN-DSA-1024 is the standardized choice.
Is FN-DSA-1024 deployed in production today?
The standard FIPS 206 is in draft. Production deployments using FALCON-1024 or FN-DSA-1024 are emerging in research, government testing, and early-adopter applications. Wide commercial deployment is expected after FIPS 206 finalizes.
What is the worst-case signature size?
The variable-length encoding in FN-DSA-1024 has a bounded maximum. The bound is approximately 1,330 bytes. Average signatures are around 1,280 bytes, so most applications can budget around 1,330 bytes per signature for safety.
Can I generate FN-DSA-1024 keys deterministically?
The key generation algorithm uses a random number generator. Deterministic key generation from a seed is supported in some implementations for testing purposes, but production deployments should always use a cryptographically secure random number generator.
How does FN-DSA-1024 handle very large messages?
FN-DSA-1024 hashes the message internally before signing. The signature size and signing time do not depend on message length. A signature on a 100 MB file takes the same time and produces the same signature size as a signature on a 100-byte file.
Sources
- NIST FIPS 206 (Draft): Stateless Hash-Based Digital Signature Standard
- FALCON Round 3 Specification, NIST PQC Project
- NIST FIPS 204: Module-Lattice-Based Digital Signature Standard
- NIST PQC Project Resources
- IACR Cryptology ePrint Archive: FALCON Implementation Notes
Related Articles
Protect Your Data Before Q-Day Arrives
QNSQY's NIST-standardized post-quantum encryption protects files against both current and quantum-era threats.