匿名凭证：图解入门（第二部分）

# 匿名凭证：图解入门（第二部分） 来源：https://blog.cryptographyengineering.com/2026/04/17/anonymous-credentials-an-illustrated-primer-part-2/ *这是关于匿名凭证系列文章的第二篇，第一篇见此。（https://blog.cryptographyengineering.com/2026/03/02/anonymous-credentials-an-illustrated-primer/）* 上一篇我们介绍了“匿名凭证”——一种让用户在*不*牺牲隐私的前提下向网站完成身份验证的技术。 快速回顾：匿名凭证系统包含几方：一个发放凭证的**Issuer**、一个或多个**Resource**（例如网站，有时与 Issuer 是同一实体），以及众多**User**。User 先以非匿名方式向 Issuer 证明自己的身份，获得凭证。之后每次访问 Resource 时，User 可以“出示”该凭证。真正的匿名性体现在“出示”环节：正确实现时，任何一方（Resource、Issuer 或二者合谋）都无法把这次“出示”与当初发给该 User 的凭证关联起来。 我们还提到匿名凭证系统最好具备的两项实用功能： 1. **限制单张凭证的使用次数**，防止*凭证克隆攻击*——黑客（或恶意用户）偷走凭证后复制出大量“机器人”账户。由于凭证天生不可追溯，一张被盗凭证可被无限克隆而难以发现。上一篇也给出过几种缓解思路。 2. **让凭证更“表达”**。例如驾照这种（非匿名）凭证能声明年龄、准驾车型、所在州等信息。*表达力强*的匿名凭证允许 User 在不泄露额外信息的前提下，对数据做各种证明。 上一篇偏理论，今天这篇——既然是“密码学*工程*”博客——就要落地：具体介绍两个现实世界已在运行的凭证系统。第一个是**Privacy Pass**（https://privacypass.github.io/），被 Cloudflare、Apple 等公司广泛采用；第二个是 Google 正在标准化的匿名年龄验证新提案。 --- ### Privacy Pass Privacy Pass 是全球部署最广泛的匿名凭证标准。 以不同名字出现的 Privacy Pass 遍布互联网，主要由大型科技公司使用。最出名的当属 **Cloudflare**（https://developers.cloudflare.com/waf/tools/privacy-pass/），其研究员参与制定了标准（https://petsymposium.org/popets/2018/popets-2018-0026.php），用来跳过验证码等反滥用流程。同样协议还被 Apple 称作“Private Access Tokens”（https://developer.apple.com/news/?id=huqjyh7k）、Google 称作“Private State Tokens”（https://privacysandbox.google.com/protections/private-state-tokens）、Brave 浏览器及其他项目采用。Privacy Pass 无处不在，连自称“不 care 隐私”的微软 Edge 也在用。 作为首个大规模落地的凭证方案，Privacy Pass 简单到极致：只提供单比特信息的“一次性手环”凭证——“我有一张凭证”。所用技术基本能在 1980 年代的论文里找到，再加一点性能优化。真正的创新是“居然真的部署了”。 Privacy Pass 已形成 IETF 系列 RFC：9576（https://datatracker.ietf.org/doc/rfc9576/）、9577（https://datatracker.ietf.org/doc/rfc9577/）、9578（https://datatracker.ietf.org/doc/rfc9578/）。标准里有很多部署选项，但核心协议就是 Chaum 最初“盲签名”凭证的完美实现，我们在上一篇也介绍过。快速复习流程： 1. User 想拿一次性凭证时，先选 token 类型（**tokentype**）和可选元数据 **MD**。 2. User 生成一个长的随机*序列号***SN**，希望全球唯一。 3. User 与 Issuer 运行盲签名协议（https://blog.cryptographyengineering.com/a-note-on-blind-signature-schemes/），对消息 (**tokentype**, **SN**, **MD**) 签名。User 得到签名 **sig**，Issuer 对消息与签名一无所知。 四元组 (**tokentype, MD, SN, sig**) 就是凭证。向 Resource“出示”时： 1. User 发送 (**tokentype, MD, SN, sig**)。 2. Resource 检查 **tokentype** 是否合法，并决定是否接受该 **MD**。 3. Resource 用 Issuer 公钥验签 **sig**，并查重 **SN**；全部通过则把 **SN** 记入数据库。 用图表示就是这样： [](https://blog.cryptographyengineering.com/wp-content/uploads/2026/03/image-9.png) 你可能会问：*这个元数据 **MD** 到底干嘛用？* **MD** 可以把凭证绑定到特定应用，例如某个网站。如果我打算在 2026 年 3 月 31 日访问纽约时报，我可以把 **MD** 设为 "`nyt.com || 2026-03-31`"。出示时，网站可验证该字段并决定是否放行。 关键：Issuer 看不到 **MD**，完全由 User 选定且事后无法更改。这样网站就能要求凭证仅限本站、或仅限某时段使用。 **MD** 的主要用途是实现“会话级凭证”——User 不是提前拿凭证，而是访问网站时才实时申请： 1. User 访问 Resource，Resource 下发一个会话“挑战”（随机串）。 2. User 立即向 Issuer 申请凭证，把 **MD** 设为该挑战。 3. User 出示凭证，Resource 验证挑战是否匹配。 用图表示： [](https://blog.cryptographyengineering.com/wp-content/uploads/2026/03/image-10.png) 好处：每张凭证只能用于已发起的这次会话，不能囤着下周再用，方便 Cloudflare 这类站点实时控流。 缺点也有： - Issuer 必须 7×24 在线，一旦宕机，用户拿不到新凭证就全站瘫痪。（预签发模式下用户可提前囤凭证。） - 实时签发可能遭受*时序关联攻击*：Resource 与 Issuer 比对消息时间戳，或可把会话与签发请求对应到同一用户。 对于 Issuer 与 Resource 同一家公司的情况（例如 **Cloudflare 的部署**（https://blog.cloudflare.com/privacy-pass-standard/)），后者尤其敏感。好在 Cloudflare 每秒处理几十万笔请求，海量流量让关联攻击极难落地。（我用 Claude Code 做了个粗糙分析，结果见这里（https://blog.cryptographyengineering.com/some-notes-on-traffic-timing-correlations-for-cloudflares-implementation-of-privacy-pass/)，结论不一。） --- ### 用什么签名方案？“token type” 又是啥？ 讲完协议框架，还剩一个基本问题：盲签名怎么实现？ Privacy Pass 定义了两种标准“签发协议”（https://www.rfc-editor.org/rfc/rfc9578），密码学略有不同。 第一种是**公开可验证 token**，就是上一篇提到的 Chaumian 凭证：Issuer 用**盲 RSA 签名**（https://blog.cryptographyengineering.com/a-note-on-blind-signature-schemes/)，几乎照搬 Chaum 1980 年代原始协议（https://www.hit.bme.hu/~buttyan/courses/BMEVIHI5316/Chaum.BlindSigForPayment.1982.PDF）。好处是 Resource 用 Issuer 公钥就能验签，双方无需共享密钥。 RSA 盲签名的缺点是体积大、运算贵：公钥至少 2048 位才能达到 112 比特对称安全级，签名也大，签名计算成本高。 自然想到换椭圆曲线（EC）原语，例如 Schnorr 签名（https://en.wikipedia.org/wiki/Schnorr_signature) 或（呃）ECDSA。可现实是： 1. 早年“盲 Schnorr” 在并发签发场景下极不安全，攻击者同时跑多轮协议就能在普通硬件上伪造签名（https://eprint.iacr.org/2020/945）。 2. 要安全就得禁止并行签发。 3. 最新论文试图修复，但协议速度反而比盲 RSA 慢（https://eprint.iacr.org/2022/1676）。 因此，Privacy Pass **完全不支持**椭圆曲线盲签名。 如果对性能极度敏感，Privacy Pass 提供第二种**私有可验证 token**：基于**不经意 MAC**（oblivious MAC），内部是**不经意伪随机函数**（oblivious PRF）。优点是用 EC 原语，生成与验证极快；缺点是 Resource 必须持有 Issuer 私钥才能验签。 --- ### 结语 Privacy Pass 是你能想到的最“无聊”的匿名凭证协议：简单的一次性“手环”凭证，优化到极致速度。核心技术 1980 年代就定型，如今标准化后飞快、好用。真正有趣的是部署规模：Apple、Google、Cloudflare……几十亿用户每天都在用，却浑然不觉。 同时，它也很“无聊”：除了“拿 token→用 token”外几乎没有别的高级功能。若要靠它做年龄验证，就得每次上网都先跟 Issuer 打一次招呼。 下一篇，我们将讨论一个更强的新提案——Google 的**零知识凭证**（https://blog.google/innovation-and-ai/technology/safety-security/opening-up-zero-knowledge-proof-technology-to-promote-privacy-in-age-assurance/)，号称能解决这些痛点。