FN-DSA — Falcon
FN-DSA (FFT over NTRU lattices Digital Signature Algorithm), based on Falcon, is the third NIST-selected signature scheme. It is to be standardized as FIPS 206, but as of mid-2026 that standard has not yet been finalized. Its standardization is still progressing; the final text, encodings, and object identifiers should follow NIST's official publication. (Its Initial Public Draft has not yet been published and remains in NIST / U.S. Department of Commerce clearance.) Check NIST CSRC for the latest status. Its draw is exceptionally compact signatures; its challenge is the demanding floating-point Gaussian sampling it requires.
Why FN-DSA is attractive
Among the post-quantum signature standards, FN-DSA produces the smallest combined public-key-plus-signature footprint. Where ML-DSA-65 signatures run ~3.3 KB and SLH-DSA signatures range from 8 KB to 50 KB, Falcon's signatures are roughly 0.6–1.3 KB. For bandwidth-constrained or storage-constrained applications — certificate chains, embedded devices, blockchain transactions — that compactness is decisive.
| Parameter set | NIST level | Public key (approx) | Signature (approx) |
|---|---|---|---|
| FN-DSA-512 (Falcon-512) | 1 | 897 | ~666 |
| FN-DSA-1024 (Falcon-1024) | 5 | 1793 | ~1280 |
Sizes are in bytes and signatures are variable-length (compressed). Compare these signature sizes against ML-DSA's: FN-DSA is several times smaller.
How it works
FN-DSA is built over NTRU lattices and uses the "hash-and-sign over a trapdoor" paradigm (the GPV framework), distinct from ML-DSA's Fiat-Shamir-with-aborts. The secret key is a lattice trapdoor; signing finds a short lattice vector close to a hashed target. To avoid leaking the trapdoor, the short vector must be drawn from a precise discrete Gaussian distribution using fast Fourier sampling over the NTRU ring.
Why it is hard to implement
The Gaussian sampler relies on floating-point arithmetic, and it must run in constant time to avoid side-channel leakage of the secret key.
- Floating-point reproducibility — results must be bit-exact across platforms; differing FP rounding can break verification or, worse, leak key bits.
- Constant-time sampling — the discrete Gaussian sampler must not branch or vary timing based on secret values, which is notoriously difficult with FP code.
- No hardware FP? — on microcontrollers lacking an FPU, emulating the required floating point is slow and error-prone.
Standardization status
FIPS 206 is the last of the first selected PQC algorithms to complete standardization; until the final standard is published, it should not be relied upon as the sole basis for a compliance deployment. As of mid-2026 its Initial Public Draft has not yet been published (the draft is still in NIST / Commerce clearance), and it is not yet a final standard. NIST has signalled that the standard will incorporate a HAWK-derived key-generation change so that key generation avoids floating-point arithmetic (the floating-point burden then falls only on signing). A final standard is informally estimated in late 2026 / early 2027, though that is not a NIST commitment. Track progress on the NIST PQC project page.
When to choose FN-DSA over ML-DSA
| Choose FN-DSA when… | Choose ML-DSA when… |
|---|---|
| Signature/key size is the binding constraint (e.g., long cert chains, on-chain data) | You want the simplest, most robust signing path |
| You sign relatively infrequently and verify often | You sign on constrained devices lacking reliable FP |
| You have a vetted constant-time FP implementation available | You need a finalized standard today (FIPS 204 is final; FIPS 206 is still a draft) |
For most organizations, ML-DSA is the safer default; FN-DSA is the specialist tool when its size advantage genuinely matters and a trustworthy implementation is on hand.
Standards & references
- NIST Post-Quantum Cryptography project (FIPS 206 / FN-DSA status)
- FIPS 204 — ML-DSA (final, 13 Aug 2024) — the recommended signature default today
- FIPS 205 — SLH-DSA (final, 13 Aug 2024)
FN-DSA Falcon
FN-DSA（基于 NTRU 格的 FFT 数字签名算法）源自 Falcon，是 NIST 选定的第三个签名方案。它将以 FIPS 206 的形式标准化，但截至 2026 年中尚未最终发布。其标准化进度仍在推进，最终文本、编码与对象标识符应以 NIST 正式发布为准；其首个公开草案 IPD 尚未公开发布，仍处于 NIST / 美国商务部审批（clearance）阶段。它的吸引力在于极为紧凑的签名，挑战则在于所需的高难度浮点高斯采样。
FN-DSA 的吸引力
在各后量子签名标准中，FN-DSA 拥有公钥加签名合计最小的体积。ML-DSA-65 签名约 3.3 KB，SLH-DSA 签名介于 8 KB 至 50 KB，而 Falcon 签名仅约 0.6 至 1.3 KB。对于带宽或存储受限的应用——证书链、嵌入式设备、区块链交易——这种紧凑性往往具有决定意义。
| 参数集 | NIST 等级 | 公钥 近似 | 签名 近似 |
|---|---|---|---|
| FN-DSA-512 Falcon-512 | 1 | 897 | 约 666 |
| FN-DSA-1024 Falcon-1024 | 5 | 1793 | 约 1280 |
尺寸单位为字节，签名为变长且经过压缩。与 ML-DSA 相比，FN-DSA 的签名要小数倍。
工作原理
FN-DSA 建立在 NTRU 格之上，采用基于陷门的“先哈希后签名”范式（即 GPV 框架），这与 ML-DSA 的带中止 Fiat-Shamir 路线不同。私钥是一个格陷门，签名过程就是寻找一个接近哈希目标的短格向量。为避免泄露陷门，该短向量必须借助 NTRU 环上的快速傅里叶采样，从精确的离散高斯分布中抽取。
为何难以实现
高斯采样器依赖浮点运算，且必须以常量时间运行，以免通过侧信道泄露私钥。
- 浮点可复现性：结果须在各平台上逐位一致，不同的浮点舍入会破坏验证，甚至更糟——泄露密钥比特。
- 常量时间采样：离散高斯采样器不得根据秘密值分支或改变时序，而这在浮点代码中是出了名地难做到。
- 缺乏硬件浮点：在没有 FPU 的微控制器上模拟所需浮点，既慢又容易出错。
标准化进展
FIPS 206 是首批选定算法中最晚完成标准化的一个；在最终标准发布前，应避免将其作为合规部署的唯一依据。截至 2026 年中，其首个公开草案 IPD 仍尚未公开发布（草案处于 NIST / 商务部审批阶段），亦尚未成为最终标准。NIST 已表示，该标准将采纳一项源自 HAWK 的密钥生成改动，使密钥生成不再涉及浮点运算，浮点负担届时仅落在签名环节。最终标准的非正式估计约在 2026 年末 / 2027 年初，但这并非 NIST 的承诺。请在 NIST PQC 项目页面跟踪进展。
何时选 FN-DSA 而非 ML-DSA
| 选 FN-DSA 当… | 选 ML-DSA 当… |
|---|---|
| 签名或密钥尺寸是关键约束，如长证书链、链上数据 | 你想要最简单、最稳健的签名路径 |
| 签名相对不频繁，但验证很频繁 | 你在缺乏可靠浮点的受限设备上签名 |
| 你已有经审查的常量时间浮点实现 | 你今天就需要正式标准（FIPS 204 已正式，FIPS 206 仍为草案） |
对多数组织而言，ML-DSA 是更安全的默认选择；FN-DSA 则是一件专用工具——仅在其尺寸优势确有意义、且手边有可信实现时才动用。
标准与参考
- NIST 后量子密码项目 FIPS 206 / FN-DSA 进展
- FIPS 204 ML-DSA 正式 2024 年 8 月 13 日当前推荐的签名默认值
- FIPS 205 SLH-DSA 正式 2024 年 8 月 13 日