Privacy Pass 的后量子迁移：令牌体积、协议兼容与隐私目标怎么权衡

结论先说：Privacy Pass 的后量子迁移不是“换一个更大的签名算法”。按 Cloudflare 2026 年 11 月 6 日的文章，Privacy Pass 的不可链接性是无条件成立的，量子计算机也破坏不了；被量子攻击击穿的是令牌的不可伪造性——攻击者可以伪造令牌，绕过站点运营方设置的限速等机制。所以三者的权衡顺序是：隐私目标不需要为抗量子让步；体积是必须支付的工程成本；协议兼容只能靠重新设计构造来解决，没有即插即用的替代品。

量子威胁落在哪一层#

Privacy Pass 的机制很直接：客户端从发行方取得若干令牌，之后用令牌兑换访问权限；关键在于每个令牌与签发它的客户端不可链接，客户端不必牺牲隐私就能正常使用站点。材料称这一性质是“unconditionally private”，即无论攻击者是否拥有量子能力，都无法把兑换行为关联回签发行为。

被量子计算动摇的是另一件事：协议仍依赖 RSA 和椭圆曲线，一旦出现密码学相关的量子计算机，攻击者就能随意伪造令牌，从而绕过运营方想实施的任何安全机制，例如限速。材料同时给出了优先级判断——最高优先级是 TLS 这类认证密钥协商的基础件；Privacy Pass 属于“还有一点喘息空间、但很快需要替代”的一类。它需要新的抗量子盲签名方案，而这是一个活跃研究方向，近几年进展明显（Cloudflare Blog，2026-11-06）。

2420 字节与 64 字节：体积账要按层算#

材料给出的核心数字只有一对签名大小，但足以说明问题：

需要说清边界：这是单个签名的大小，不是完整令牌的大小。一个 Privacy Pass 令牌还包含消息本身，验证方还需要发行方公钥，某些构造还带证明数据。本次材料没有给出完整令牌在候选方案下的字节数，所以不能直接把“37.8 倍”套到令牌上。可以确定的只有方向：材料明确说不会有 drop-in replacement，只能接受成本更高的原语，并重新设计系统来承担这个成本。

体积会落在哪些地方，材料没有逐项展开。按工程常识推断（非材料结论）：客户端本地存储的令牌数量、一次批量兑换的请求体积、中继与隐私代理场景下的带宽放大，都会受影响。凡是按“每令牌固定开销”做容量规划的系统，都需要重算。

兼容性的真正难点是信任模型，不是字节格式#

现有 Privacy Pass 令牌由消息加盲签名组成。盲签名让客户端在不向发行方暴露消息的前提下拿到签名，之后出示时也无法被关联回签发。但验证方要校验令牌，就必须拿到发行方公钥，因此必然知道发行方是谁。

材料把这个“泄露”描述为有意设计：发行方身份本身就是信号，某些产品用它判断客户端类型，例如客户端用某客户签发的令牌证明自己有权使用该客户的 VPN 产品。问题在于，很多场景并不需要这么细的信息，只需要确认“令牌由某个我信任的实体签发”。

MOLE（Moderation Of unLinkable Endorsements）把这一点再推一步：令牌连发行方身份也隐藏，避免按发行方区别对待，让更多类型的客户端更容易参与。它的结构是：

• anchor 签发 endorsement（背书）；
• 客户端向 moderator 兑换；
• 兑换前双方约定 anchor set，即 moderator 信任的 anchor 公钥集合；
• 兑换时客户端证明自己持有集合中某个 anchor 的背书，但不透露是哪一个；
• 通过后 moderator 发放 MOLE credential，用于后续对这个客户端交互做管理。

这里有一个对迁移很关键的工程性质：credential 是给特定 moderator 用的，因此不需要 anchor-hiding，甚至不需要公开可验证。材料据此指出，从盲签名到匿名信用令牌、匿名限速凭证，都可以用来实例化 credential。换句话说，昂贵的抗量子隐藏属性只需要压在 endorsement 这一层，credential 层可以按每个 moderator 的实际需求选择更便宜的构造。这是分层承担成本，而不是让每一个令牌都付全价。

参数与协议解耦，才是后量子匿名凭据的中心问题#

材料把“适应性与效率的张力”点得很直白。ML-DSA 是从一个更大的构造框架里调出来的：框架本身能搭很多东西，但为了把 ML-DSA 做得尽量紧凑，参数是针对数字签名场景精调的，同一组参数不一定适用于其他用途。而 MOLE 这类系统不是只做一种凭据，而是很多种，且类型会随流量模式和攻击行为变化。于是中心挑战变成：把参数选择与协议设计解耦。

在经典密码学里这是理所当然的：协议设计者基本不用操心椭圆曲线参数，非椭圆曲线专家也能搭出有用的东西。后量子凭据目前还做不到这一点，设计高效构造仍需大量专业知识。材料认为今年早些时候出现的突破可能改变这一局面，落点是 VOLEitH。

VOLEitH 的位置

VOLE-in-the-Head 是 Baum 等人在 Crypto 2023 提出的零知识证明系统。VOLE 指 Vector Oblivious Linear Evaluation，一种交互式技术，给两方生成相关随机值；这些相关性像认证标签，让验证方能够检查“对隐藏 witness 的计算是否被正确执行”。VOLEitH 的做法是让证明者在本地准备原本由两方共同生成的值（“in the head”），对其承诺，再用 Fiat-Shamir 变换挑出验证方要检查的部分，从而把交互过程变成非交互零知识证明。

它的价值不在“更小”。材料明确说它并不 succinct，证明体积是代价。它的优势是相对简单、易于安全实现；而且零知识证明可以转成数字签名，安全性归约到 AES——FAEST 就是这样来的，是 NIST 正在进行的签名竞赛的候选方案。对凭据系统而言，这意味着可以围绕一个较简单的证明系统组合出不同协议，而不必为每种用途重新调一套格参数。

本次材料在“其证明是渐近的……”处被截断，因此 VOLEitH 的具体证明大小、验证开销和与 ML-DSA 的体积对比都无法给出，待核实。

给开发者的落地顺序#

1. 先标注令牌用途。哪些路径真的需要验证方知道发行方身份，哪些只需要“某个可信 anchor 签发”。这决定了你未来能不能用 MOLE 式的分层，还是必须保留发行方可识别的令牌。
2. 按令牌类型建体积预算。拆出签名字节、消息字节、公钥字节和证明字节，不要用“签名倍数”代替整令牌倍数。
3. 把签名与证明层抽象出来。令牌格式不要绑定具体参数集，否则换原语等于换协议。
4. 跟踪 MOLE 与 VOLEitH 的规范、实现与安全分析状态。材料把它们定位为方向与突破，不是可直接依赖的成品。

下面只是一段核算口径的示意，未执行，数值取自材料，不代表任何真实令牌大小：

# 未执行示例：仅演示核算口径
sig_bytes = {"ML-DSA-44": 2420, "ECDSA-P256": 64}
ratio = sig_bytes["ML-DSA-44"] / sig_bytes["ECDSA-P256"]  # 37.8125
# 完整令牌还需加上 message、public key、proof 等字段，
# 这些字段的字节数本次材料未提供，不能直接套用上面的倍数。

尚待核实#

• MOLE 的规范状态、参考实现与部署时间：材料只称其“目前叫 MOLE”，并预告后续会有更多说明。
• 可用的后量子盲签名构造及其安全证明：材料称这是活跃研究领域，但未列出具体方案。
• VOLEitH 的证明大小与验证开销：材料在关键处截断。
• 完整 Privacy Pass 令牌在候选方案下的字节数，以及这对批量兑换的影响。

最后一条限制值得单独写：本文依据的是来源文章的截断正文，结论可能出现在未提供的后半部分。凡本文写“待核实”的地方，都表示本次材料未提供，不等于来源没有讨论。