Post-Quantum Digital Signatures

Digital signatures provide authentication and integrity — they prove a message, certificate, or firmware image came from the holder of a private key and was not altered. Post-quantum signatures keep this guarantee against quantum attackers, but they are dramatically larger than ECDSA or Ed25519, and that size is the dominant migration challenge.

The signature API

Every signature scheme exposes three operations:

KeyGen() → (pk, sk) — produces a public verification key pk and a private signing key sk.
Sign(sk, msg) → sig — the signer produces a signature over msg using sk.
Verify(pk, msg, sig) → bool — anyone holding pk checks that sig is a valid signature on msg.

Unlike a KEM, a signature involves no shared secret and no confidentiality — it is purely about proving origin and integrity to anyone who has the public key.

Security goal: EUF-CMA

Standardized signatures target EUF-CMA (existential unforgeability under chosen-message attack). Informally: an adversary who can request signatures on any messages of their choosing still cannot produce a valid signature on a new message they never asked about. This is the baseline security every modern signature scheme should meet.

Where signatures are used

TLS handshake authentication — the server (and optionally client) signs handshake data to prove identity.
X.509 certificates — a CA signs each certificate; chains stack multiple signatures.
Code and firmware signing — long-lived signing keys whose verification keys may be burned into hardware for decades.
Document and software-update signing — package managers, secure boot, and provenance.

The size problem

This is the headline issue. PQC signatures and public keys are far larger than their classical counterparts. Ed25519 has a 32-byte public key and 64-byte signature; ML-DSA-65 has a 1952-byte public key and a 3309-byte signature — roughly 50x the signature. In a TLS handshake a certificate chain may carry several signatures plus several public keys, so the multiplier compounds and can push the handshake past one network round-trip's worth of buffer.

Scheme	Public key (bytes)	Signature (bytes)
Ed25519 (classical)	32	64
RSA-2048 (classical)	256	256
Falcon-512	~897	~666 (padded) or ~650 variable
ML-DSA-65	1952	3309
SLH-DSA-128s	32	~7856

Note

SLH-DSA has a tiny public key but a very large signature; Falcon has the most compact overall footprint but needs delicate floating-point or constant-time emulation to sign safely. There is no free lunch — every family trades something.

Stateless vs stateful

Hash-based signatures come in two flavors, and the distinction is operationally critical:

Stateless (SLH-DSA) — every signature is independent. You can sign as much as you like with no bookkeeping. This is the safe default for general use.
Stateful (XMSS, LMS) — each private key has a finite set of one-time states, and you must never reuse a state. Reusing one catastrophically breaks security. Stateful schemes have smaller signatures but require reliable, atomic state tracking — unsuitable where keys are cloned, backed up, or load-balanced.

Warning

Never deploy a stateful hash-based signature (XMSS/LMS) unless you can absolutely guarantee one-time use of every state across all replicas, crashes, and restores. A single reused state is a full key compromise. When in doubt, use stateless SLH-DSA.

Choosing ML-DSA vs Falcon vs SLH-DSA

ML-DSA (FIPS 204) — the general-purpose default. Reasonable sizes, fast, simple constant-time implementation. Start here unless you have a specific reason not to.
Falcon / FN-DSA (selected by NIST; FIPS 206 in development, not yet finalized) — choose when signature and public-key size are the binding constraint (e.g. dense certificate chains). The cost is a far more delicate, harder-to-secure signing implementation due to floating-point Gaussian sampling.
SLH-DSA (FIPS 205) — choose when you want conservative, hash-only security with the smallest set of assumptions — ideal for firmware/root-of-trust where the verification key lives for decades. The cost is large signatures and slow signing.

A common pattern is to mix: SLH-DSA for the long-lived root, ML-DSA for online handshake and intermediate signing.

Note

Map your level the same way as KEMs: ML-DSA-65 at Level 3 is the common interoperable default for online authentication. See security-levels.html and parameters.html.

ML-DSA — the general-purpose lattice signature SLH-DSA — stateless hash-based signature Falcon — compact lattice signature

Standards & references

FIPS 204 (ML-DSA) — the general-purpose lattice signature standard.
FIPS 205 (SLH-DSA) — the stateless hash-based signature standard.
NIST Post-Quantum Cryptography project — the standardization program behind these signatures.
Resources — full standards register

后量子数字签名

数字签名提供认证与完整性保障——它证明某条消息、证书或固件镜像出自某私钥持有者之手且未被篡改。后量子签名在面对量子攻击者时仍能维持这一保证，但其体积远大于 ECDSA 或 Ed25519，而这一体积正是迁移工作的首要挑战。

签名接口

每个签名方案都提供三个操作：

KeyGen() → (pk, sk) — 生成公开验证密钥 pk 和私有签名密钥 sk。
Sign(sk, msg) → sig — 签名者用 sk 对 msg 生成签名。
Verify(pk, msg, sig) → bool — 任何持有 pk 者都可校验 sig 是否为 msg 上的有效签名。

与 KEM 不同，签名不涉及共享秘密，也不提供机密性——它纯粹是向任何持有公钥者证明来源与完整性。

安全目标 EUF-CMA

标准化签名以 EUF-CMA（选择消息攻击下的存在性不可伪造）为目标。通俗地说：即便攻击者能针对任意自选消息索取签名，仍无法对一条从未请求过的新消息生成有效签名。这是任何现代签名方案都应达到的基线安全。

签名的用途

TLS 握手认证 — 服务端（必要时含客户端）对握手数据签名以证明身份。
X.509 证书 — CA 为每张证书签名，证书链层层叠加多个签名。
代码与固件签名 — 长期签名密钥，其验证密钥可能被固化进硬件长达数十年。
文档与软件更新签名 — 包管理器、安全启动与来源溯源。

体积问题

这是头号问题。PQC 签名与公钥远大于经典对应物。Ed25519 公钥 32 字节、签名 64 字节；而 ML-DSA-65 公钥 1952 字节、签名 3309 字节——签名约为前者的 50 倍。TLS 握手中一条证书链可能携带数个签名外加数个公钥，倍增效应层层累积，足以使握手数据超出单个网络往返的缓冲容量。

方案	公钥（字节）	签名（字节）
Ed25519（经典）	32	64
RSA-2048（经典）	256	256
Falcon-512	约 897	约 666（padded）或约 650 变长
ML-DSA-65	1952	3309
SLH-DSA-128s	32	约 7856

注意

SLH-DSA 公钥极小但签名很大；Falcon 整体足迹最紧凑，但要安全签名需依赖精细的浮点运算或恒定时间仿真。天下没有免费的午餐——每个家族都在某处做出取舍。

无状态与有状态

基于哈希的签名分两种类型，二者在运维上的区别至关重要：

无状态（SLH-DSA）— 每个签名相互独立，可任意签署而无需记账。这是通用场景的安全默认值。
有状态（XMSS、LMS）— 每个私钥只有有限组一次性状态，绝不可重用任何状态。重用将彻底摧毁安全性。有状态方案签名更小，但要求可靠、原子的状态跟踪——不适用于密钥被克隆、备份或负载均衡的场景。

警告

除非能在所有副本、崩溃与恢复情形下绝对保证每个状态仅用一次，否则切勿部署有状态哈希签名（XMSS/LMS）。哪怕一次状态重用都等同于完全泄露私钥。拿不准时，请用无状态的 SLH-DSA。

如何在 ML-DSA Falcon SLH-DSA 之间取舍

ML-DSA（FIPS 204） — 通用默认值。体积合理、速度快、恒定时间实现简单。若无特殊理由，从这里起步。
Falcon / FN-DSA（NIST 已选择，FIPS 206 制定中，尚未最终发布） — 当签名与公钥体积是硬约束时（如密集证书链）选用。代价是因浮点高斯采样而更为精细、更难保证安全的签名实现。
SLH-DSA（FIPS 205） — 当你追求保守的、仅依赖哈希的安全与最少假设时选用，非常适合验证密钥需存活数十年的固件/信任根。代价是签名很大且签名速度慢。

常见做法是混用：长期的信任根用 SLH-DSA，在线握手与中间证书签名用 ML-DSA。

注意

等级映射与 KEM 一致：在线认证的常见互操作默认值是 Level 3 的 ML-DSA-65。参见 security-levels.html 与 parameters.html。

标准与参考

FIPS 204 ML-DSA — 通用格签名标准。
FIPS 205 SLH-DSA — 无状态哈希签名标准。
NIST 后量子密码项目 — 这些签名背后的标准化计划。
资源链接 — 完整标准登记册

Previous上一页← Key Encapsulation (KEM)密钥封装 KEM Next下一页Parameter Sets & Sizes参数集与尺寸 →