后量子 Privacy Pass 的协议取舍：令牌体积、匿名集与兼容成本

短答案：后量子化不会推翻 Privacy Pass 的不可关联性，但会推翻它的不可伪造性。代价主要落在三处——令牌与证明的体积、匿名集的定义方式、以及验证方与签发方之间为承载更大对象而要做的兼容改造。Cloudflare 在 2026 年 11 月 6 日的一篇文章中给出了 MOLE 与 VOLE-in-the-Head 这条可能路径，但本文抓取到的正文在讨论 VOLEitH 证明不简洁处即被截断，凡涉及具体字节数、证明开销与落地状态的结论，本文一律标注待核实（来源：The post-quantum future of web privacy）。

先分清两种安全：不可伪造与不可关联#

Privacy Pass 的基本机制是：客户端先取得若干令牌，之后用令牌换取访问权；关键在于每枚令牌与它被签发时的客户端不可关联。站点运营方用它替代 CAPTCHA、账号与指纹识别这类“要么增加摩擦、要么损失隐私”的手段（来源同上）。

材料明确指出，Privacy Pass 目前仍依赖 RSA 与椭圆曲线这类经典密码，因此量子攻击者可以随意伪造令牌，绕过运营方想实施的任何机制，例如限流。与此同时，材料称 Privacy Pass 是“无条件私密”的：无论攻击者是否拥有量子计算机，都无法把令牌的兑换关联回它的签发（来源同上）。

把这两点放在一起，可以得出一个本文的推断：Q-day 到来时，最先出问题的不是用户隐私，而是滥用防护。迁移的紧迫性来自“限流被击穿”，而不是“匿名被破除”。材料也承认这一点，称这给了业界一点喘息空间，但替代方案仍需尽快到位。

令牌体积：2,420 字节说明的是量级，不是令牌大小#

材料给出的对照是：ML-DSA-44 签名为 2,420 字节，ECDSA-P256 签名仅 64 字节，并且短期内没有可直接替换的方案，只能接受更高成本并重工程系统（来源同上）。

需要克制的两点。其一，2,420 字节是签名方案的输出长度，而一枚 Privacy Pass 令牌还包含消息与盲签名结构，二者不能等同；材料本身也只把这组数字用作“量级差距”的例证。其二，体积本身不改变密码学上的不可关联性，但会改变部署形态——每个请求愿意附带多少令牌、移动端能否承担、边缘节点如何缓存与校验，都是工程推断而非材料结论。

匿名集：从隐藏用户到隐藏签发者#

现有的一类 Privacy Pass 令牌由消息与盲签发签名组成。盲签名的定义是：客户端在不向签发方透露消息的前提下，取得签发方私钥下的签名。验证方校验令牌需要签发方公钥，因此必然会知道签发方是谁。材料对此的判断很直接：这类令牌保护客户端身份，但不保护签发方身份（来源同上）。

签发方身份并非无用信息。材料举例说，客户端可以用某个客户签发的令牌，证明自己有权使用该客户的 VPN 产品；这类信号被用于部分产品和部分客户的分流决策。所以“隐藏签发者”不是免费的改进，而是主动放弃了这一维度。

MOLE（Moderation Of unLinkable Endorsements）的做法是引入 endorsement：由 anchor 签发、由 moderator 兑换。兑换前，客户端与 moderator 先就一组 anchor 集合达成一致，即 moderator 所信任的 anchor 公钥；兑换时，客户端证明自己的 endorsement 来自集合中的某一个 anchor，但不透露是哪一个；被接受后，moderator 再向客户端签发用于调节其访问的 MOLE 凭证（来源同上）。

这里有两个取舍值得写进设计文档。第一，匿名集的大小约等于被信任 anchor 集合的大小（此为推断）：集合越大，签发方身份隐藏得越好，但 moderator 需要维护更长的信任列表，且“只信任某一家签发方”这种策略无法再用令牌结构表达，只能靠凭证侧的策略补回。第二，材料指出 MOLE 凭证因为只面向特定 moderator 使用，不必具备隐藏 anchor 或公开可验证的性质，因此盲签名、匿名信用令牌、匿名限流凭证都可以用来实例化它（来源同上）。灵活性的代价是验证责任内向化：凭证不再是任何人都能独立校验的公共对象。

兼容成本：把参数选择与协议设计解耦#

材料把后量子匿名凭证的中心挑战概括为一句话：把参数选择与协议设计解耦。经典凭证系统里，协议设计者基本不必操心椭圆曲线参数；而后量子方案中，参数往往是为某一具体用途精调过的——ML-DSA 就是例子，它由以构建多种对象的框架派生而来，但为了紧凑，参数被专门调成高效安全的签名方案，同一套参数未必适用于其他用途（来源同上）。

VOLE-in-the-Head（VOLEitH）被材料视为可能的破局点，出处标为 Baum 等人的 Crypto 2023 论文。它是一套零知识证明系统：证明者证明自己知道满足某公开陈述的隐藏证据而不泄露证据。材料给的例子是证明知道一个 AES 密钥 K，使得 Y=AES(K,X)，其中 X、Y 公开；这类证明可转成数字签名，安全性归约到 AES，这正是 NIST 签名竞赛候选 FAEST 的思路。VOLE 的全称是 Vector Oblivious Linear Evaluation（向量不经意线性求值），是一种让两方获得相关随机值的交互技术，这些相关值像认证标签一样，让验证者检查对隐藏证据的计算是否正确；在 VOLEitH 中，证明者本地预演两方本该共同生成的内容（“in the head”），对其承诺，再用 Fiat-Shamir 变换选出验证者要检查的部分，从而把交互过程变成非交互零知识证明（来源同上）。

材料同时提醒，VOLEitH 并不是一个以简洁见长的证明系统，其证明是渐进意义上的……文本在此截断。因此“证明有多大、生成要多久、能否塞进一次 HTTP 请求”这些问题，本文无法回答，只能标为待核实。

按角色拆开看，兼容成本大致分布在四处（以下为基于材料结构的工程推断，非实测）：客户端要生成证明，承担算力与电量；anchor 侧要发布并轮换后量子密钥与参数；moderator 侧要维护 anchor 集合、把凭证验证从“公开可验证”改为内部逻辑；运维侧要把更大的对象写进带宽与存储预算。

如果要给出一条可执行的建议，我会这样排序，并明确它是建议而非材料结论：先把 anchor 集合做成配置而不是硬编码，避免日后扩集合时改协议；再在非关键路径上做双栈灰度，让经典令牌与后量子凭证并存一段时间；最后把令牌体积纳入容量预算之后再谈全量切换。材料所说的“只能接受更高成本并重工程系统”，落到工程上就是这一步。

待核实清单#

• MOLE 的后量子实例化具体采用哪种盲签名构造，材料截断处未给出。
• 后量子 Privacy Pass 令牌的实际字节数、证明生成与验证开销：材料未提供，无可核验测试记录。
• VOLEitH 证明的渐进复杂度结论与常数因子，位于被截断的段落。
• 客户端与浏览器侧的支持计划、与现有 Privacy Pass 部署（如 iCloud Private Relay、Privacy Gateway）的互操作路径，材料只提到已有十年部署经验，未涉及迁移细节。
• anchor 集合的实际规模建议，以及集合扩大后 moderator 的策略表达能力如何补足。

在拿到上述数据之前，稳妥的表述是：后量子 Privacy Pass 的方向已经清楚——用隐藏签发者的 endorsement 换更大的匿名集，用可组合的证明系统换参数解耦——但体积与兼容成本的账，还没有可公开核对的数字。