Privacy Pass 的后量子迁移：VOLE 方案改了哪几层协议假设

简短回答：从 Cloudflare 2026 年 11 月 6 日的博客给出的线索看，VOLE 这条路线改的不是“把 RSA 换成某个后量子签名”这么一层，而是至少四层协议假设——证明的交互性、原语的数学来源、参数选择与协议设计的关系，以及发行方身份要不要让验证方看到。而 Privacy Pass 的不可链接性本来就不在量子攻击的射程里。

需要先说明材料边界：本文只拿到该文正文片段，且在讨论 VOLEitH 证明规模的句子中间被截断。因此关于证明大小、验证开销、能否支撑高并发兑换的结论，本文不作推断，一律标为待核实。

先分清：量子威胁改的是“伪造”，不是“不可链接”#

按该文描述，Privacy Pass 的基本机制是：客户端先领到一批 token，之后兑换 token 换取站点访问；每个 token 与领取它的客户端不可链接。这样一来，站点可以在不引入验证码、账户或浏览器指纹的前提下做限流。Cloudflare 称已有十年部署经验，涵盖 iCloud Private Relay、Privacy Gateway 等场景。

现在的 Privacy Pass 仍依赖 RSA 和椭圆曲线这类经典密码学。文章的判断是：量子攻击者可以随意伪造 token，用来绕过站点运营方想实施的安全机制，比如限流。但同一段给出了一个不对称的结论——Privacy Pass 是“无条件隐私”的，无论攻击者是否拥有量子能力，都无法把一次兑换链接回它的签发。

换句话说，量子威胁改变的是“token 是否可信”，不是“token 是否暴露客户端身份”。这个区分决定了迁移的紧迫性排序：伪造属于安全属性，必须换；不可链接性属于隐私属性，架构上已经守住。文章也提到，新一代私有认证能力“可以并且将会”以维持同样保证的方式实例化，即 Q-day 之后交互依然私密。Q-day 指密码学相关量子计算机真正可用的时间点。

第一层：交互性——从两方在线到“in the head”#

VOLEitH 来自 Baum 等人发表于 Crypto 2023 的工作。名字里的 VOLE 全称是 Vector Oblivious Linear Evaluation（向量不经意线性求值），是一种交互式技术：让两个参与方获得一组相关的随机值，这些相关值的作用类似认证标签，使验证方能够检查“对隐藏见证所做的计算”是否正确。

VOLEitH 的改动在于：证明者不再真的和验证方跑这轮交互，而是在本地把双方通常会共同生成的东西准备好——所谓 “in the head”——再对这些值做承诺，然后用 Fiat-Shamir 变换挑出验证方要检查的部分。文章说，这一步把交互式的 VOLE 过程变成了非交互零知识证明。

对协议设计者来说，这一层的含义是：证明从“两方在线跑一轮”变成“一方离线生成、单条消息提交”。盲签发的领取与兑换要求客户端在不泄露消息的前提下与签发方来回，而兑换侧通常是单消息、离线可验证的；非交互化是把这类证明嵌进既有流程的前提。这是从文章描述能直接推出的部分；VOLEitH 具体怎样对接 Privacy Pass 的 token 结构，材料未展开。

第二层：原语来源——从数论难题到对称密码，代价是体积#

文章给出的对照是体积：ML-DSA-44 签名有 2,420 字节，而 ECDSA-P256 签名只有 64 字节。它的判断是，短期内没有即插即用替代品的希望，只能接受成本更高的原语并重新工程化系统，TLS 的迁移也是同一条路。

VOLEitH 的位置有些微妙。一方面，文章说它相对好理解、也相对容易安全实现，这对一个要嵌进多种协议的积木很重要；另一方面，文章明确说它“并不简洁”（not succinct），证明在渐近意义上……片段正好在这里截断。所以证明大小和是否适合高并发场景，应以原文为准，待核实。

原语来源的变化可以用文中的一个例子说明：零知识证明可以用来证明“知道一个 AES 密钥 K，使得 Y=AES(K,X)”，其中 X、Y 公开；这个证明可以转成数字签名，安全性归约到 AES，X、Y 是公钥、K 是私钥。文章说这正是 FAEST 数字签名，NIST 签名竞赛的候选之一。从数论难题挪到对称密码，实现门槛与参数风险的来源都变了；但 FAEST 目前只是候选，是否标准化、以什么参数标准化，待核实。

第三层：参数与设计——从“不必关心曲线”到必须解耦#

这一层对工程实践影响最大。文章把“把参数选择与协议设计解耦”称为后量子匿名凭证的中心挑战。

在经典凭证系统里，这件事被当成理所当然：多数情况下，协议设计者不需要考虑所用椭圆曲线的参数，即使不是椭圆曲线密码专家，也能用这套东西做出有用的系统。后量子的情况不同：今天广泛使用的后量子方案大多来自更大的构造族，但已经被针对特定用途调过参数。文章拿 ML-DSA 举例——它背后的密码框架可以用来构建多种东西，但为了让 ML-DSA 尽可能紧凑，参数被仔细裁剪成“一个高效且安全的数字签名方案”；同样的参数未必对其他用途安全。

这意味着后量子凭证的高效设计仍然需要大量专业知识，除非出现能让参数与协议设计分开处理的构造。文章说今年早些时候出现过一次突破，可能代表匿名凭证的范式转变，并与 VOLEitH 这条线放在一起讨论。至于这次突破具体走到哪一步、能否直接用于生产，材料没有给出结论，待核实。

第四层：发行方身份——从“验证方知道是谁签发”到“只知道一个集合”#

前几层讲的是证明怎么生成、原语是什么；这一层讲的是验证方知道什么。

经典 Privacy Pass token 是“消息 + 盲签发的签名”。盲签名指客户端能在不向签发方透露消息的情况下拿到签发方私钥下的签名，之后公开消息与签名，而不把它们链回签发环节。但验证 token 需要签发方公钥，因此验证方必然知道签发方是谁。文章说得很直白：这类 token 保护客户端身份，但不保护签发方身份。有些场景正需要这一点，比如客户端用某个客户的 token 证明自己有权使用该客户的 VPN 产品。

MOLE（Moderation Of unLinkable Endorsements）把这条假设再推一步：token 应当完全隐藏签发方身份，这样验证方就无法按“谁签发的”区别对待 token。文章给出的理由是保证不同类型的客户端受到同等对待，让更多客户端能参与进来。

实现方式是引入一个新对象：背书（endorsement）。背书由锚点（anchor）签发、由审核方（moderator）兑换。兑换之前，客户端与审核方先就“锚点集”达成一致——即审核方信任的锚点的公钥集合；兑换时，客户端证明自己持有的背书来自这个集合中的某一个锚点，但不透露是哪一个。审核方接受后，再给客户端签发 MOLE 凭证，用于后续审核该客户端与站点的交互。

示意一下（非实际实现）：若审核方信任锚点 A1–A4，客户端持有 A2 签发的背书，兑换时暴露的信息只是“来自 {A1, A2, A3, A4} 之一”。这改的是信任粒度：从“验证方认识并信任某个签发方”变成“验证方信任一个集合，集合内部不可区分”。文章还提到，MOLE 凭证只供某个特定审核方使用，因此不需要隐藏锚点，甚至不需要公开可验证；盲签名、匿名信用 token、匿名限流凭证都可以用来实例化它。

四层假设一览#

表中内容是对文章描述的小结，不是文章原文的结构。

现在能做什么，什么只能等#

下面几条是基于上述结论的工程建议，属于推断，不是文章的主张。

• 把“令牌格式与签名原语”和“业务策略”分开。体积从几十字节变成千字节级时，受影响的不只是签名库，还包括请求头、缓存键、日志字段和限流键的设计，应预留空间。
• 把“签发方身份是否可见”当作策略参数，而不是写死在协议里。MOLE 的锚点集模型说明，信任可以是集合级别的，不必是单点级别的。
• 不要把它当成“现在就该换库”的信号。VOLEitH 的证明规模、MOLE 的标准化状态、FAEST 的竞赛结果，在本次材料里都没有定论。

待核实的问题至少包括：VOLEitH 证明的实际字节数与验证开销；MOLE 的命名、规范与落地节奏（文章说它是“目前称为”MOLE）；FAEST 在 NIST 签名竞赛中的最终结果；以及现有 Privacy Pass 部署的迁移时间表。在有可核验的测试记录之前，任何性能数字都不应写进技术选型文档。

结论可以收在一句话上：这次迁移不是一次算法替换，而是把后量子成本分摊到协议设计的每一层，VOLE 这条线的价值，在于它至少让“参数”和“协议”有机会分开处理。