后量子迁移不只换算法：Privacy Pass 这类匿名凭证协议要重核哪些假设

把 Privacy Pass 迁到后量子，最常见的计划是「把 RSA 和椭圆曲线签名换成 ML-DSA」。按 Cloudflare 2026 年 11 月 6 日这篇博文的说法，这个计划至少在三处不够用：token 可被量子攻击者伪造、签名尺寸涨了约一个数量级、新凭证类型需要的构造没法靠现成签名参数拼出来。更根本的问题是，「换算法」只覆盖了不可伪造性这一条假设；匿名凭证协议还依赖另外几条——不可链接性的强度、验证者能看到哪些身份、字节预算、参数与协议设计的耦合、验证成本是否会被滥用放大。本文按材料能支持的范围逐条拆开。

先说明材料边界：可用的只有该博文正文的截断片段，涉及具体新方案的性能数字、标准化与部署状态未在片段中给出，本文对这些位置标注待核实，不做补写。来源：The post-quantum future of web privacy。

一、不可伪造与不可链接，是两条要分开核对的假设#

Privacy Pass 的基本结构是：客户端从签发者处取得一批 token，兑换时向站点出示，换取访问权；关键在于每个 token 与取得它的客户端不可链接。支撑签发的是盲签名（blind signature）——客户端能在不向签发者泄露消息内容的前提下拿到签名，之后出示消息与签名，也无法被关联回签发时刻。

量子威胁落在这条链的哪一环，材料说得很清楚：Privacy Pass 仍依赖 RSA 与椭圆曲线这类经典密码，一旦出现密码学相关的量子计算机，攻击者可以随意伪造 token，绕过站点想实施的任何机制，例如速率限制。这里失效的是不可伪造性。

但材料同时强调另一面：Privacy Pass 是「无条件隐私」的（unconditionally private），即无论攻击者是否拥有量子能力，都无法把 token 的兑换与签发关联起来。也就是说，量子威胁并不会自动击穿不可链接性；会不会击穿，取决于具体构造用什么方式实现不可链接。

由此得到第一条核对动作：把协议里每一条安全性质单独列出，标注它依赖什么假设。不要因为「整体换成后量子算法」就默认可链接性、匿名性、不可追踪性一并保住。材料对 Privacy Pass 给出的表述是无条件成立，但不同 token 类型、不同部署版本可能采用不同构造，具体到自己的实现仍应逐条确认，这一点属于建议而非材料结论。

二、字节预算要重算：2420 与 64#

材料给出的对比很具体：ML-DSA-44 签名是 2420 字节，ECDSA-P256 签名只有 64 字节。作者判断短期内没有可直接替换的方案，只能接受更高的成本，并重新设计系统来承担这个成本。

这对匿名凭证的影响比对 TLS 更复杂，因为 token 通常不是单个使用，而是批量发放、批量出示。按材料数字做一个简单推算（仅为算术演示，不是实测，也未计入编码、头部与传输开销）：若一次发放 100 个 token，签名部分会从约 6.4 KB 变成约 242 KB。实际协议还要考虑请求头上限、缓存键、日志体积与批量兑换策略。

核对动作：把「单个凭证字节数 × 典型批量 × 每请求可携带数量」算清楚，再看现有传输与存储路径是否承受得住。这一步不需要新密码学知识，却最容易被「换算法」的叙事跳过。

三、验证者知道签发者是谁，这本身是一条假设#

材料指出一个常被忽略的点：Privacy Pass 的 token 由消息加盲签名构成，验证时需要签发者的公钥，因此验证者必然知道签发者身份。也就是说，这类 token 保护客户端身份，但不保护签发者身份。

对某些场景这是刻意的特性——签发者身份可以说明客户端类型，例如客户端用某客户签发的 token 证明自己有权使用该客户的 VPN 产品。但对多数场景，这只是超出决策所需的多余信息；站点真正关心的往往只是「这个 token 来自某个我信任的实体」。

核对动作：列出验证环节实际需要知道的身份，并区分「业务上需要」与「协议实现顺带泄露」。后者在后量子重设计时是可以一并改掉的，而改掉它会牵动信任模型。

四、MOLE 的做法：把签发与审核拆成两个角色#

材料介绍的 MOLE（Moderation Of unLinkable Endorsements）针对的正是上一条。它引入一个新对象：背书（endorsement），由 anchor 签发、由 moderator 兑换。兑换前，客户端与 moderator 先就一个 anchor 集合达成一致，即 moderator 信任的 anchor 公钥列表；兑换时，客户端证明自己持有该集合中某一个 anchor 签发的背书，但不说明是哪一个。moderator 接受后，向客户端签发 MOLE 凭证，用于对该客户端与站点的后续交互做审核。

这个设计带来一个实用后果：MOLE 凭证只面向特定 moderator 使用，因此不必具备隐藏 anchor 的性质，甚至不必可公开验证。于是凭证的实例化方式被放开——盲签名、匿名信用 token、匿名限速凭证都可以用来构造。这是「可组合」从口号落到接口层面的地方：需要隐藏签发者的部分收敛到 endorsement，需要适配业务的部