返回资讯中心
外部精选
软件工程
#开发者实时流

Cloudflare 探讨 Privacy Pass 协议向后量子密码学迁移

来源标题:The post-quantum future of web privacy

Cloudflare 指出,向后量子密码学迁移的首要任务是 TLS 等认证密钥协商协议的基础组件,否则量子计算机上线后互联网安全通信将无法实现。Cloudflare 用于防滥用的 Privacy Pass 协议同样依赖易受量子攻击的密码学,该协议通过发放不可关联的代币,让用户无需 CAPTCHA 即可访问站点并保护隐私。

Hacker News 最新AIWithLucas2026/11/7 · 8 天前30 分钟阅读

以下正文由 AI 翻译自 Hacker News 最新(原文版权归原站所有),可能存在偏差,重要内容请以原文为准。

向后量子密码学过渡的重中之重,是诸如 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 的兑换与其签发关联起来。更重要的是,我们为这一代新型隐私认证技术开发的新能力,能够也将会以 upholding 同样保证的方式被实例化:即使在 Q-day 之后,你的交互依然保持私密。

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

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

我们先来概述这项新技术,它目前被称为 MOLE(“Moderation Of unLinkable Endorsements”,即不可链接背书的审核)。后文我们会对 MOLE 做更多阐述,眼下先强调与密码学最相关的细节。

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

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

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

然而,对于许多用例而言,这比我们决定是否授予客户端访问某资源所需的信息要多。通常我们只关心 token 是否由我们信任的某个实体签发。事实上,MOLE 更进一步:token 应完全隐藏签发者的身份,以便我们无法根据签发者是谁而对 token 区别对待。这保证了无论客户端类型如何都一视同仁,从而使更多客户端更容易参与。

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

(原文较长,此处译出前 6000 字,完整内容请点「打开原文」。)

正文由 探How 从来源站点 RSS 同步,内容未经改写;遇到排版缺失或需要图片、视频时请以原文为准。

打开原文
去社区讨论 →