Cloudflare 探讨 Privacy Pass 协议的量子威胁与后量子加密

向抗量子密码学迁移的最高优先级，是TLS等认证密钥协商协议的基础构建模块。如果这些基础模块不到位，一旦密码学相关的量子计算机上线，互联网上的安全通信将无从谈起。然而，今天我们依赖的抗量子脆弱的密码学，远不止TLS。

Privacy Pass是Cloudflare等站点运营方用来帮助保护应用免受滥用的一种协议。我们实现这一点的方式之一，是对单个客户端进行速率限制，使任何单个客户端都不会消耗站点过多资源。通常，这会涉及某种摩擦或用户隐私损失的组合：CAPTCHA或其他流量调节挑战，以及用于识别流量的账户和指纹识别。Privacy Pass的设计初衷，正是为了避免这种摩擦与隐私之间的权衡。其基本思路是，向客户端签发一定数量的token，客户端可以兑换这些token以换取对站点的访问权。关键在于，每个token都无法与其被签发给的客户端关联起来，从而确保客户端能够像以往一样使用站点，而无需牺牲隐私。

凭借10年的部署经验——将Privacy Pass用于隐私代理（如iCloud Private Relay）和中继（如Privacy Gateway）等应用——我们与其他人一道，正在合作将这项技术的下一代带到Web上。我们的目标之一是开发更精细的工具来管理代理流量，否则这些流量会消耗过多资源并降低人类访客的性能体验。另一个目标是通过让更多类型的客户端更容易参与，来培育一个更开放的生态系统。实现这些目标需要开发超越Privacy Pass当前能力的新功能。

鉴于这一发展轨迹，本文我们将探讨抗量子的前景。事实上，我们的处境比人们想象的要好。Privacy Pass仍然依赖经典密码学，如RSA和椭圆曲线。这意味着量子攻击者将能够随意伪造token，并利用它们绕过站点运营方想要实施的任何安全机制（例如速率限制）。另一方面，Privacy Pass是无条件隐私的，这意味着任何攻击者，无论是否具备量子能力，都无法将token的兑换与其签发关联起来。更重要的是，我们为这一代新型隐私认证技术所开发的新功能，可以并且将会以维护同样保证的方式来实现：即使在Q-day之后，你的交互仍然是私密的。

这给了我们一点喘息空间，但我们很快就会需要替代方案。这是一个活跃的研究领域，近年来已取得重大进展。不过，正如迁移的其他方面一样，主要挑战在于抗量子替代方案的体积庞大：ML-DSA-44签名高达2,420字节，而ECDSA-P256签名仅为64字节。短期内指望直接替换的希望不大。正如TLS的情况一样，我们不得不接受成本更高的原语，并重新设计我们的系统来承受这一成本。

但这些原语会是什么呢？在本文中，我们将探讨Web上抗量子隐私的一种可能未来，这得益于盲签名设计领域的一项最新突破。

我们需要构建什么：MOLE简介

让我们先概述这项新技术，它目前被称为MOLE（“Moderation Of unLinkable Endorsements”）。后面我们还会对MOLE做更多介绍，但现在我们先聚焦与密码学最相关的细节。

Privacy Pass的核心组件之一是盲签名方案，它允许客户端在签发者的密钥下获得签名，而不会向签发者透露其所签名的消息。客户端随后可以公开该消息和盲签名，而不会将签名与其签发过程关联起来。

一种Privacy Pass token由消息和盲签名组成。要验证该token，验证者需要签发者的公钥，因此必然得知签发者的身份。因此，虽然这些token保护了客户端的身份，却不保护签发者的身份。

当然，对于某些用例来说，这正是我们想要的。签发者的身份告诉我们连接到我们边缘节点的客户端属于什么类型，这是我们在某些产品和某些客户中用于决策的信号。例如，客户端可能使用我们某个客户签发的token，来证明其有权使用该客户的VPN产品。

然而，对于许多用例来说，这比我们做出授予客户端访问资源决定实际需要的信息要多。通常我们只关心token是由我们信任的某个实体签发的。事实上，MOLE更进一步：token应完全隐藏签发者的身份，以便我们无法根据签发者是谁而对token区别对待。这保证了无论客户端类型如何都能获得平等对待，使更多客户端更容易参与。

这种隐藏签发者的属性通过一种名为背书（endorsement）的新对象来实现。背书由锚点（anchor）签发，由审核者（moderator）兑换。在兑换之前，客户端和审核者就一个锚点集合达成一致，即审核者信任的锚点的公钥。在兑换过程中，客户端证明自己获得了锚点集合中某个锚点签发的背书，但不透露是哪一个。一旦接受，审核者就向客户端签发MOLE凭证，客户端将用它来管理与站点的交互。

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）