后量子时代的 Privacy Pass：哪些密码学假设要改，哪些不必改

如果只问一句：Privacy Pass 类方案进入后量子时代，要改的是什么？答案是不可伪造性所依赖的密码学假设，而不是不可关联性。据 Cloudflare 2026 年 11 月 6 日的文章 The post-quantum future of web privacy，Privacy Pass 的隐私性是无条件的——任何攻击者，量子的或经典的，都无法把一次 token 兑换关联回它的签发过程；但 token 本身仍由 RSA、椭圆曲线这类经典密码学签发，量子攻击者可以随意伪造 token，绕过站点运营方设置的限速等机制。本文依据该文及其公开抓取片段展开；片段在讨论 VOLEitH 证明是否简洁处被截断，后续具体构造、性能数字与部署安排本次材料未提供，文中不做补写。

两个属性，两条不同的处置路径#

把 Privacy Pass 拆开看，它同时提供两件事。

• 不可伪造：客户端拿不到有效 token，就无法冒充已获授权的流量。这是一个计算假设问题，当前落在 RSA 与椭圆曲线离散对数上。
• 不可关联：验证方拿到 token 时，无法判断它当初发给了谁。来源称这一性质是无条件的，不随计算能力变化。

因此迁移的优先级和范围要分开排。不可关联性不需要"换成后量子版本"，因为它本来就不建立在会被量子算法攻破的难题上；需要重做的是签发与验证这条链路上的签名原语，以及围绕它建立的尺寸预算、消息格式和验证接口。

这里有一个容易被忽略的细节：来源说新一批私有认证能力"可以并且将会"以维持同等保证的方式实例化，使交互在 Q-day 之后仍然私密。这是规划性陈述，不是已完成的部署事实。

验证者是否需要知道"谁签发的"#

经典 Privacy Pass token 由消息加一个盲签名组成。盲签名的含义是：客户端在不向签发者泄露消息内容的前提下，取得签发者私钥下的签名；之后出示消息与签名时，也无法被关联回签发时刻。问题在于验证环节——验证者需要签发者的公钥，于是必然得知签发者是谁。来源明确说：这类 token 保护客户端身份，但不保护签发者身份。

有些场景正需要这个信号。例如客户端用某客户签发的 token 证明自己有权使用该客户的 VPN 产品。但在更多场景中，验证方只需要确认"某个我信任的实体签发过"，并不需要知道是哪一个。知道得越多，就越容易按签发者区别对待 token。

MOLE（Moderation Of unLinkable Endorsements）针对的正是这一点。它引入一个新对象 endorsement：由 anchor 签发、由 moderator 兑换。兑换之前，客户端与 moderator 先就 anchor set（moderator 所信任的 anchor 公钥集合）达成一致；兑换时，客户端证明自己持有集合中某一个 anchor 签发的 endorsement，但不透露是哪一个；接受后，moderator 再向客户端签发用于调节后续访问的 MOLE credential。

这一步对密码学假设的影响比表面更大：验证方不再持有单一签发者的公钥，而是需要验证"集合成员关系"的证明；而 credential 是给特定 moderator 用的，因此不必隐藏 anchor，甚至不必公开可验证。来源列举的可实例化形式包括盲签名、匿名信用 token、匿名限速凭证。可选空间变大，意味着不必把整个系统绑死在某一种后量子签名上。

成本假设要重写：尺寸与参数#

尺寸是最直接的约束。来源给出的对照是：ML-DSA-44 签名为 2420 字节，ECDSA-P256 签名为 64 字节。按这两个数字计算，签名本身相差约 38 倍。注意这只是签名原语的差距；token 或握手消息实际膨胀多少，取决于最终构造里放几个签名、用什么编码，本次材料未提供，待核实。

该文的判断是短期内没有即插即用替代品的希望，只能像 TLS 迁移那样，接受更贵的原语，并重新设计系统来承担这个成本。对开发者而言，这意味着带宽、缓存、存储与验证耗时都要重新做预算，而不是原地换一个库。

更麻烦的是参数治理。来源把"参数选择与协议设计解耦"称为后量子匿名凭证的核心挑战。经典凭证系统里，协议设计者基本不必操心所用椭圆曲线的参数，非椭圆曲线专家也能构建有用的东西；而后量子方案不是这样。文中以 ML-DSA 为例：它派生自一个可以构建多种对象的框架，但为了让签名尽量紧凑，参数被仔细裁剪过，同一组参数搬到别的用途未必安全。

VOLEitH 提供的是哪一类构件#

来源提到 2023 年 Crypto 会议上的 VOLE-in-the-Head（VOLEitH）零知识证明系统（Baum 等）。VOLE 是 Vector Oblivious Linear Evaluation 的缩写，一种让两方获得相关随机值的交互技术；这些相关性起认证标签的作用，让验证者能检查针对隐藏 witness 的计算是否被正确执行。VOLEitH 让证明者在本地把通常由两方共同生成的值准备好（即"in the head"），对其承诺，再用 Fiat-Shamir 变换挑出验证者要检查的部分，从而把交互过程变成非交互证明。

文中举的用法是：证明自己知道某个 AES 密钥 K，使 Y=AES(K,X)，其中 X、Y 公开。该证明可转成数字签名，其安全性归约到 AES 的安全性，这正是 NIST 签名竞赛候选 FAEST 的思路。换句话说，这条路线把安全性假设挪到对称原语上，而不是继续依赖数论难题。

但来源同时说，VOLEitH 是一个"相当不起眼"的证明系统：它不像许多其他证明系统那样简洁（succinct）。原文在展开这一点时被截断，具体证明尺寸与验证开销本次材料未提供，不能据此判断它能否直接用于高频 token 兑换场景。

接口差异示意

// 未执行的示例：仅示意“验证者需要什么输入”这一接口层面的差异。
// 不对应任何真实库、消息格式或 API，也没有实际运行。

// 经典 Privacy Pass 式校验（示意）
verify_token(token, issuer_public_key) -> bool
// 验证者必须持有具体签发者的公钥

// MOLE 式 endorsement 兑换（示意）
redeem_endorsement(proof, anchor_public_key_set) -> credential | reject
// proof 需证明：存在集合中的某个 anchor 签发了该 endorsement，
// 但不透露是哪一个；通过后由 moderator 签发 credential

给迁移工作的核对清单（建议）#

以下条目是依据上述事实提出的工程建议，不是来源原文结论。

1. 先标注每个 token 的验证输入：验证方是否必须知道签发者公钥。若答案是否，隐藏签发者的结构能显著放宽后续原语选择。
2. 把不可伪造性与不可关联性分开写安全目标：前者随原语更换而变化，后者应作为不变量长期保持。
3. 按字节做预算：把 token、请求头、缓存键的尺寸上限写进设计文档，再选原语，而不是反过来。
4. 核查参数来源：确认所用参数是为当前用途裁剪并经过分析的，不要从签名方案直接搬到凭证或盲签名场景。
5. 保留可组合性：MOLE 的动机之一是凭证类型会随流量模式和攻击行为变化，构件应能重新组合而非一次写死。

尚待核实#

• MOLE 的完整规范、消息格式与安全模型；本次材料只有概念描述。
• VOLEitH 的证明尺寸与验证开销，以及它如何具体构造盲签名或 MOLE 构件；材料在此处截断。
• FAEST 在 NIST 签名竞赛中的当前状态；材料只称其为候选。
• 实际部署中 token 与握手的字节膨胀比例，以及迁移时间表。

结论回到开头那句：后量子迁移对 Privacy Pass 类方案而言，不是把"隐私"重新证明一遍，而是把不可伪造性的地基从 RSA 与椭圆曲线换到后量子假设上；换地基时，验证接口、尺寸预算与参数治理会一起被牵动。MOLE 与 VOLEitH 是这条路上已经公开的两个方向，但都还停留在需要继续核实细节的阶段。