Skip to content

SYSTEM Cited by 1 source

FN-DSA (Fast-Fourier Lattice Signature)

What

FN-DSA (formerly Falcon) is a structured-lattice hash-then-sign post-quantum signature algorithm selected by NIST for standardisation as FIPS 206. It offers significantly smaller signatures (666 B at 128-bit security) and public keys (897 B) than ML-DSA-44 (2,420 B + 1,312 B), with faster verification.

Parameter sets

Parameter set Security level Public key (B) Signature (B) Signing time (×ML-DSA) Verification time (×ML-DSA)
FN-DSA-512 128-bit 897 666 3× ⚠️ 0.7×
FN-DSA-1024 256-bit 1,793 1,280 ~6× ~1.4×

A critical gap: no middle security level exists. If lattice cryptanalysis improves beyond 128 bits, the only option is a full jump to FN-DSA-1024 (double all sizes).

Implementation hazards

FN-DSA's primary challenge is signing, not verification:

  • Floating-point arithmetic dependency: The most natural and efficient implementation uses hardware-accelerated FPU operations — a first for a cryptographic standard. Side-channel-safe floating-point is poorly understood and processor-specific.
  • Timing side-channel: A safe implementation for one processor may be unsafe on another. Fixed-point arithmetic implementations are safer but ~20× slower (comparable to RSA-2048).
  • Non-reproducible test vectors: Due to floating-point non-associativity (a+(b+c) ≠ (a+b)+c), different implementations produce slightly different valid outputs. This undermines the humble test vector — still the most practical bug-catcher.
  • Deterministic signing leaks keys: Two deterministic signatures from slightly different implementations on the same private key can leak partial key material. FN-DSA adds a randomiser, but there's tension with testing (you need deterministic interfaces for tests but must never use them for real signatures).

(Source: sources/2026-07-09-cloudflare-post-quantum-signature-algorithms)

Deployment timeline

  • Draft standard: pending (has taken years to write due to complexity)
  • Early software support: ~2029
  • Widely available: not before 2033

Use cases

  • Verification is straightforward — all hazards are on the signing side. Good for scenarios with a small number of trusted signers and many verifiers.
  • Not suitable for environments where diverse, potentially unvetted implementations must sign (embedded devices, edge, client-side).

Seen in

Last updated · 575 distilled / 1,757 read