VOLET 与后量子 Privacy Pass：令牌体积、匿名性与协议兼容的迁移取舍

先给结论：材料支持的答案不是“把 RSA 或椭圆曲线换成后量子签名”这么简单。迁移要在三条约束之间同时取舍——令牌体积会因后量子原语上升一个量级；匿名性需要区分“客户端不可链接”和“签发者隐藏”两个不同目标；协议兼容的真正瓶颈是把参数选择与协议设计解耦，而不是找一个可直接替换的算法。另需先澄清一个术语：本次材料正文中没有出现“VOLET”，出现的是 VOLE-in-the-Head（VOLEitH）和 MOLE。二者是否为同一事物的不同叫法，材料无法支持，本文按待核实处理，只讨论材料实际写到的 VOLEitH。

材料能确认的边界#

可用来源是 Cloudflare 博客 2026 年 11 月 6 日发布的文章，抓取时间为 2026 年 11 月 9 日，正文片段在讨论 VOLEitH 证明不简洁处被截断（The post-quantum future of web privacy）。因此本文能确认的是设计动机与部分数字，不能确认 MOLE 的完整规范、任何基准测试结果、标准化状态或迁移时间表。凡涉及这些内容，下文标为待核实，而不是断言“官方未说明”。

体积：先分清签名、令牌与凭证#

材料给出的唯一硬数字在签名层：ML-DSA-44 签名为 2,420 字节，ECDSA-P256 签名为 64 字节。按这两个数字直接相除，前者约为后者的 38 倍。这个比值只描述签名长度，不能直接搬到令牌上。

材料说明，Privacy Pass 的一种令牌由“消息 + 盲签名”构成，验证者需要签发者公钥才能验证。这意味着令牌体积至少包含签名，还可能包含消息与其他字段；若换成带承诺或证明的构造，还要再加一层。材料没有给出 MOLE 中 endorsement 或 credential 的字节数，因此“令牌会大多少”属于待核实，不能拿 38 倍直接下结论。

工程上的含义是具体的：如果每个请求携带若干令牌，令牌体积会直接改变头部预算、单连接可携带的令牌数、以及批量兑换与缓存的策略。这些上限取决于实际协议与部署环境，材料未提供，需自行测量。

匿名性：两个性质不要混用#

材料对现有 Privacy Pass 的表述很明确：它是“无条件隐私”的，任何攻击者，无论是否拥有量子能力，都无法把令牌的兑换链接回它的签发。这是客户端侧的不可链接性。

但同一段材料也指出另一面：由于验证需要签发者公钥，验证者必然知道签发者是谁。所以这类令牌保护客户端身份，不保护签发者身份。对某些场景这恰恰是需要的——材料举例，客户端可以用某客户签发的令牌证明自己有权使用该客户的 VPN 产品。

MOLE（Moderation Of unLinkable Endorsements）改变的是这一点。它引入 endorsement：由 anchor 签发、由 moderator 兑换；兑换前客户端与 moderator 就 anchor 集合（moderator 信任的 anchor 公钥）达成一致，兑换时客户端证明自己持有集合中某一个 anchor 的 endorsement，但不泄露是哪一个。接受后，moderator 再签发用于审核该客户端交互的 MOLE credential。材料给出的理由是平等对待：不因签发者不同而区别对待令牌，让更多类型的客户端参与。

这里有一处容易被忽略的边界：MOLE credential 面向特定 moderator 使用，因此不必具备签发者隐藏性质，甚至不必公开可验证。也就是说，匿名性保证的强度随对象而变，不能笼统说“MOLE 更匿名”。

协议兼容：瓶颈在参数与协议耦合#

材料把后量子匿名凭证的核心挑战说得很直白：把参数选择与协议设计解耦。经典凭证系统里，协议设计者通常不必关心椭圆曲线参数；而后量子方案大多从更大的构造族派生，却针对特定用途调校。ML-DSA 就是例子——它的底层框架可以构建多种东西，但为了紧凑，参数被专门调成高效的签名方案，同样的参数不一定对其他用途安全。

VOLEitH 是材料给出的可能路径。VOLE 指 Vector Oblivious Linear Evaluation，一种交互式技术，给两方相关随机值，这些相关性像认证标签，让验证者能检查对隐藏 witness 的计算是否正确。“in the head”指证明者在本地准备好两方本来要共同生成的值，对其承诺，再用 Fiat-Shamir 变换选出验证者检查的部分，从而把交互过程变成非交互零知识证明。材料举的例子是：证明知道 AES 密钥 K 使得 Y=AES(K,X)，该证明可转成数字签名，即 NIST 签名竞赛候选 FAEST。这条路径的意义在于，安全性可以归约到对称原语，协议设计者不必每次都重新理解后量子参数。

但代价没有被隐藏：材料明确说 VOLEitH“并不简洁”，证明是渐近……（此处正文截断）。所以体积问题没有消失，只是从“签名很大”换成“证明不小”。具体多大，待核实。

给开发者的落地判断#

以下是基于材料的建议，不是材料本身的结论。

1. 先定匿名性目标，再选原语。如果业务只需要“同一客户端不可被链接”，现有 Privacy Pass 的隐私模型已经够用；只有当你确实需要不依赖签发者身份做决策时，才需要 MOLE 这类签发者隐藏设计。顺序反了，会为一个不需要的性质付出体积与配置成本。
2. 把体积写成预算项。按“每请求令牌数 × 令牌大小 + 头部开销”列预算，再决定可接受的原语。材料只给了签名层数字，令牌层必须自己测。
3. 按能力抽象凭证层，不要绑定算法。材料指出 MOLE credential 可由盲签名、匿名信用令牌、匿名限速凭证等多种方式实例化，这提示接口应围绕“能证明什么”设计，而不是围绕某个签名方案。
4. 不要把 ML-DSA-44 的参数当通用件。材料明确其参数是为签名调校的，挪用到匿名凭证需要重新论证。
5. 把 anchor 集合当成新的配置面。验证者从“持有一个签发者公钥”变成“与客户端就一组公钥达成一致”，这会带来配置分发、集合更新与信任边界的新问题。

仍需核实的事项#

• VOLET 与 VOLEitH 是否为同一事物，或 VOLET 指另一种构造。
• MOLE 中 endorsement 与 credential 的实际字节数、证明大小与验证开销。
• VOLEitH 在浏览器与移动客户端上的可行性，材料片段未涉及。
• 后量子 Privacy Pass 的标准化状态与互操作测试结果。
• 迁移时间线，以及材料所称“Q-day”之后的隐私保证如何被验证。
• 被截断部分可能给出的结论；本文不对未见内容作推断。

一句话收束：这次迁移的正确顺序是先定匿名性目标，再定令牌体积预算，最后才选原语。反过来做，通常会在协议兼容性上返工。