常见问答｜如何应对量子计算紧急情况？—

用你已有的算法而不是你希望拥有的算法去“作战”。

在上一篇文章《PKI前线｜深度好文——后量子TLS的设计选择》中，FirefoxCTO、Let's Encrypt的联合创始人Eric Rescorla介绍了互联网社区如何努力实现后量子算法以防御加密相关量子计算机（CRQC），即能够攻击真实世界密码系统的量子计算机（而普通计算机无法攻击这些系统）。

但没有人真正知道CRQC何时开发出来，甚至不知道是否会开发出来，即使在最好的情况下，过渡也将需要很长时间。那么如果有人在过渡完成之前就构建了 CRQC，这会发生什么？

显然，这将使介于非紧急和紧急之间的情况变成完全突发的情况，但这并不意味着一切都将失去。

在本篇文章中，Eric Rescorla探讨了如果CRQC提前出现会发生怎样的情况。与之前的文章一样，这篇文章主要关注TLS和网络（也会涉及一些其他协议）。

以下为原文，经公钥密码开放社区编译：

显然，有很多情况需要考虑，“加密相关性”在这里发挥着重要作用。例如，我们通常假设X25519的强度约为 2^128。将强度降低到2^80的技术对于攻击来说将是一个相当大的改进，并且肯定是“加密相关的”，但攻击成本仍然相当高；特别是如果每次攻击都需要针对每个连接进行，每次操作耗费2^80，这显然会成为加速量子计算过渡的强烈动机。

出于本文的目的，我们假设：

·这是一次特别严重的攻击，现有算法在合理的时间范围内（无论是几天还是实时）都处于商业攻击者的攻击范围之内。

·这将在未来几年内的某个时间点发生，虽然PQ密钥建立已经得到重大部署，但远未普遍部署，而PQ签名和证书则基本上没有部署。

·这接近于最坏情况，即我们现有的加密被严重削弱，但实际上不太可能简单地禁用它并转换到PQ算法。换句话说，这并不是一个紧急情况，我们只留下了一套相当有限的选择。

密钥建立

首要任务是解决密钥建立的问题。显然，如果您还没有实现PQ混合或纯PQ算法，您应该尽快这样做，选择更广泛部署的一个（或者如果某些同行采用一种算法，而另一些同行采用另一种算法，则可能同时采用这两种算法）。

一旦您添加了对某种PQ算法的支持，那么问题是您是否应该禁用传统经典算法。简单的答案是“不”：即使经典算法被严重削弱，任何加密都比没有加密要好。实际上，情况要复杂一些。

回想一下，在TLS中，客户端提出一组算法，服务器选择一个，如下所示：

这里的想法是，服务器可以查看客户端支持的算法，然后选择最佳算法。只要客户端和服务器对算法排名达成一致，那么这通常就可以正常工作。但是，服务器和客户端可能会出现分歧，在这种情况下，服务器的偏好将占上风。

实际上，在从RC4对称密码过渡时确实发生了这种情况。在一系列论文展示了RC4存在重大弱点之后，浏览器决定他们更喜欢AES-GCM。不幸的是，许多服务器更喜欢RC4，因此即使在客户端和服务器都支持RC4和AES-GCM的情况下，许多服务器仍选择了RC4。为了应对这一问题，浏览器（从IE开始）采用了一种系统，首先尝试不提供RC4连接，如果失败，则重新尝试并使用RC4，如下所示:

该结果是，任何支持AES-GCM的服务器都会协商它，但如果服务器只支持RC4，客户端仍然可以连接。这也使得可以测量支持AES-GCM的服务器比例，从而提供有关禁用RC4有多实际的信息。

降级攻击

到目前为止，我们只考虑了被动攻击者，那么主动攻击者呢？TLS 1.3的设计使得来自服务器的签名保护了握手过程，因此只要客户端支持的最弱签名算法足够强大，积极攻击者就无法篡改协商结果。

之前描述的回退系统在某种程度上削弱了这种保证，因为攻击者可以伪造错误并强制客户端进行回退握手。然而，客户端仍然会在回退握手中提供两种算法，因此攻击者不能阻止服务器选择其首选算法；它只能通过操纵第一次握手来阻止客户端获取客户端首选的算法。

当然，如果服务器的签名不够强大，或者更准确地说，客户端能接受的最弱签名算法不够强大，那么攻击者可以篡改协商中的密钥建立算法。但是，能够做到这一点的攻击者可以直接冒充服务器，因此客户端支持什么密钥建立算法并不重要。

也许最好的办法是宁可失败也不可设防

也许最好是失败开启。总的来说，只要你没有受到实时攻击，TLS将会提供由双方共同支持的最强算法，如果你受到能够破解签名算法的攻击者的实时攻击，那么一切都无法预料。如果你已经决定连接到服务器，那这可能是你所能做的最好的事情。但另一种选择是不要连接。

这里的基本问题是与网站的通信有多敏感。如果你只是查找一些食谱或阅读新闻，那么如果你的连接不安全可能并不是什么大问题（实际上，人们过去经常争论根本不需要加密，尽管显然我不同意这种观点）。另一方面，如果你在进行银行业务或阅读电子邮件，你可能真的不希望未加密地进行这些操作。

这并不是说我们不希望加密普及——我们希望——或者说即使是看似无害的通信也可能是敏感的——它确实是——而是要认识到，如果这是唯一的选择，这种情况将迫使我们做出一些艰难的选择，即是否愿意在通信时不安全地传输信息。这对于人类来说是一个艰难的选择，对于像浏览器这样的软件来说更加困难（显然对于一个独立的邮件客户端来说更容易）。

事实上，普遍加密使事情变得更加困难。在加密较为罕见的时候，如果一个网站被加密，那么运营者可能认为这是特别敏感的信息。但现在一切都被加密了，很难区分保护这个特定连接是真的重要，还是只是一种良好的普遍做法（再次强调，这是！）。

可能不太明显的一点是，不安全的连接不仅会威胁您通过它发送的数据，还会威胁其他数据。例如，如果您正在阅读电子邮件，则可能使用密码（使用普通邮件客户端）或cookie（使用Webmail）进行身份验证。这两者都是可重放的凭据，因此可以解密您的连接的攻击者可以冒充您访问服务器并下载您的所有电子邮件，而不仅仅是您正在阅读的消息。

如上所述，过去记录了您的流量的攻击者可能仍然能够恢复您的密码，但这比实时从线路上获取密码要费力得多。

签名算法

当然，这一切都不能对服务器进行认证，这对于防范主动攻击至关重要。为此，我们需要服务器具有带有PQ算法的证书，并且客户端拒绝信任以下证书：

(1) 用经典算法签名的证书，或者

(2) 含有经典算法密钥的证书。

重要的是，服务器停止使用PQ经典证书是不够的，因为服务器根本不必参与连接。事实上，即使服务器没有PQ证书，攻击仍然是可能的，因为攻击者可以伪造整个证书链。

首先必须发生的是服务器必须部署PQ证书。如果没有这样做，客户端就很难自卫。在这种情况下，我期望会有巨大的压力尽快采取行动，尽管Bas Westerban和David Adrian指出PQ证书存在严重的尺寸过载问题。毕竟，拥有一个慢一点的网站总比一个不安全的网站或者一个无法连接的网站要好。

出于同样的原因，我认为对于新PQ算法的硬件安全模块（HSM）的可用性或者所涉及的算法是否已经通过整个IETF标准制定过程的担忧会少很多。这两者都是好事，但拥有PQ安全证书更为重要，因此我预计行业将在前进的道路上快速融合。

一旦PQ得以部署，客户端可以开始不信任经典算法（在此之前，做这样的事情没有多少意义）。然而，与密钥建立一样：如果客户端不信任经典算法，那它将无法连接到任何没有PQ证书的服务器，而最初大多数服务器都属于这种情况，即使在最好的情况下也是如此。这很令人沮丧，因为这意味着你必须在连接失败和防范主动攻击之间作出选择。你真正想要的是得到尽可能好的保护，即

·只信任具有PQ证书的站点的PQ算法（这样你就不会受到主动攻击的影响）。

·对没有PQ证书的站点允许使用经典算法（这样你至少会得到防范被动攻击的保护）。

实际上，这里有三种情况：

·那些非常敏感的站点，如果没有PQ证书，你不应该连接它们（例如你的银行）。

·已知拥有PQ证书的站点，因此你不应接受经典证书（可能像Google这样的大站点）。

·那些不太敏感的站点，因此你愿意接受其经典证书（例如报纸）。

问题在于如何区分站点属于哪个类别。通常情况下，我们不会试图对这种区分进行尝试，只是让站点告诉我们它是否需要TLS，但这并不是一个通常的情况，因此值得探讨一些不便之事。

PQ锁定

最明显的做法是让客户端记住服务器何时具有PQ证书，并在此后拒绝接受经典证书。不幸的是，这个想法并不那么完美，因为服务器配置并不那么稳定。举例来说：

（1）一个网站可能推出PQ，然后出现问题并禁用它。

（2）一个网站可能有多个服务器，逐渐在其中的一个上推出PQ证书。

（3）一个网站可能由多个配置不同的CDN提供服务。

请注意，在情况（2）和（3）中，客户端通常并不知道存在不同的服务器，因为它们具有相同的域名，而IP地址并不可靠（而且也很可能受到攻击者控制，因为DNS并不十分安全）。而在情况（1）中，实际上是同一个服务器。

在任何这些情况下，都可能出现这样的情况：客户端连接服务器，获取PQ证书，然后返回获取传统证书，因此如果客户端在PQ之后禁止对传统的任何使用，这将导致很多故障。幸运的是，我们之前遇到过从HTTP过渡到HTTPS的情况，所以我们知道解决方案：服务器告诉客户端“从现在开始，坚持采用新的方式”，而客户端会记住这一点。

HTTP/HTTPS中，这是一个名为HTTP Strict Transport Security（HSTS）的标头，语义是“从现在开始只使用此域名的HTTPS”。引入一个新功能，其语义是“从现在开始只坚持使用此域名的PQ”，将是直接的。实际上，HSTS规范是可扩展的，因此如果您想坚持使用HTTPS（这是一个好主意！），您可能只需要添加一个新的指令说明“还需要PQ”。也很容易添加一个新的HTTP标头，指出“如果您使用HTTPS，则需要PQ”，因为HTTP很容易扩展，未知的标头将被忽略。

像HSTS这样的标头的一个显而易见的问题——事实上，与HSTS本身一样——是它在某个时候依赖于客户端连接到服务器时不受攻击。如果攻击者正在冒充服务器，那么他们就不会发送新的标头。即使他们可以连接到真实服务器并发送有效的其他数据，但只需剥离标头。不过，这仍然是一个真正的改进，因为攻击者需要更强大：如果客户端能够建立安全连接到真正的服务器，那么它将记住需要PQ，并且从那时起对攻击受到保护，即使在一开始并没有得到保护。

预加载

通过让客户端软件提前知道哪些服务器支持PQ，可以从一开始就保护用户免受主动攻击。浏览器已经在HSTS中做了一些事情，即所谓的“HSTS预加载”。

Chrome运营着一个网站，服务器操作员可以请求将他们的站点添加到“HSTS预加载列表”中。该网站进行一些检查以确保服务器配置正确，然后Chrome将其添加到他们的列表中。原则上，其他浏览器也可以自行执行此操作，但实际上，它们都是以Chrome的列表为起点。

原则上，我们也可以像这样使用一个系统进行PQ预加载，但存在扩展性问题。HSTS预加载列表相当庞大（截止到目前为止有约160K条目），但这仅代表互联网上的一小部分域。

例如，Let's Encrypt目前为超过1亿个注册域和4亿个完全合格域颁发证书。如果我们假设已经迁移到PQ的站点会积极进行预加载—出于安全原因，他们应该这样做—那么我们可能在讨论数千万条目。

当前的Firefox下载大约为134MB，所以即使使用紧凑的数据结构，我们可能也需要大幅扩展浏览器下载的大小来携带整个预加载列表。另一方面，在早期可能并不会有太多的预加载，这可能不是完全不可承受的。

也许还有避免下载整个数据库的方法。例如，您可以使用类似于Safe Browsing的系统，将一个不完美的摘要数据结构与查询机制相结合，这样您就可以为大多数站点获得离线答案，但随后需要与服务器检查以确保。

Safe Browsing数据库大约有400万条目—至少在2022年是这样—所以您可能可以将类似于SB的技术重新用于这样的事情，至少在PQ证书变得更加流行之前。SB风格系统的隐私属性不如只预加载整个列表那么好，所以在这里存在权衡，需要找出一组不太理想选项中的最佳选项。

当然，浏览器供应商不需要等待服务器请求进行预加载；他们可以主动添加它们，例如通过扫描以查看哪些站点宣传仅PQ标头，甚至支持PQ算法的站点。显然，有过早将站点记录为仅PQ的风险，但在这种情况下允许非PQ连接也存在风险。支持这些算法的服务器比例越高，浏览器供应商就越能够积极要求PQ支持，并且他们也能够更容易地将服务器添加到列表中，即使服务器实际上并没有直接表示希望被包括在内。"

站点分类

还有其他指标可以用来确定一个站点是否特别敏感，因此需要通过PQ安全连接到达，或者根本不需要。这可能发生在浏览器端或服务器端，根据各种指标，比如需要密码或是医疗或金融网站。人们甚至可以想象建立某种统计或机器学习模型来确定站点是否敏感。这并不需要完全完美，只要比静态配置显著好即可。

减少开销

显然，如果使用PQ签名算法不那么昂贵，我们将处于更好的位置。主要是关于签名的大小。正如Bas所说，在减少大小开销上有许多可能的选项，包括：

·删除已知的中间证书和根证书

·根据已知证书数据库对证书进行智能压缩

·彻底重新设计证书的整个结构

所有这些机制都设计为向后兼容，这意味着客户端和服务器可以检测它们是否都支持优化并使用它，但如果不支持，则可以回退到更传统的机制。前两种机制与现有的WebPKI证书一起工作，也可以与PQ证书一起工作，只需要更新客户端和服务器软件以支持优化。

最后一种机制（“Merkle树证书”）替换了现有的WebPKI证书，因此需要服务器获取PQ WebPKI证书和PQ Merkle树证书，并根据客户端的能力有条件地提供正确的证书。这显然对服务器运营商（同样适用于浏览器用户）来说是更多的工作。另一方面，如果服务器运营商已经要改变其流程以获取PQ和传统证书，那么同时改变以获取Merkle树证书也是一个方便的时机。

HTTP 公钥固定

HTTP 公钥固定（HTTP Public Key Pinning）是一种技术，它允许网站服务器指定它支持的公钥证书，以增强安全性。

通过在HTTP响应头中添加公钥指纹（Pc xinning），客户端可以验证服务器证书的有效性，从而防止中间人攻击和伪造证书的风险。然而，由于HPKP可能会导致网站因指定错误的密钥而无法访问，以及其他技术如证书透明度的出现，HPKP最终被废弃。

有人可能会想到，在网站准备部署PQ但CA还不能颁PQ证书的时期，可以重新启用HPKP的某些变体，作为PQ过渡的权宜之计。这不会完全一样，因为服务器必须使用其传统证书进行身份验证，然后锁定PQ密钥，而PQ密钥无需证书链即可被接受，而HPKP不支持证书链。我的感觉是，我们可能能够设法颁发一些PQ证书，速度比我们设计一种新的HPKP类型机制并广泛部署它的速度要快，但这可能仍然是一个值得记住的选择，以防我们需要它。

那么TLS 1.2怎么样？

上面讲述的一个挑战是，PQ支持仅在TLS 1.3中可用，而不在TLS 1.2中。这意味着任何想要添加PQ支持的人也必须升级到TLS 1.3。

一方面，人们显然必须进行升级才能添加PQ算法，所以问题不算大。另一方面，升级更多东西总是比升级更少的东西更困难。毕竟，TLS工作组可以为TLS 1.2定义新的PQ密码套件，并且这是一个紧急情况，为什么不让人们使用TLS 1.2与PQ，而不是试图强迫他们转移到TLS 1.3呢。

在紧握手中，TLS 1.3几乎是TLS 1.2的即插即用替代品。有一个TLS 1.2使用案例未被TLS 1.3覆盖（设计如此），即能够在拥有服务器私钥时被动解密连接的能力（有时称为“可见性”），这在一些网络中用于服务器端监控。然而，这种技术对于PQ密钥建立也无法使用，因此如果转换到TLS 1.3，这并不是一种退化。

非TLS系统

上面我写的大部分内容同样适用于许多其他交互式安全协议，比如IPsec或SSH，它们基本上都是按照相同的模式设计的。任何非Web的交互式协议可能会更容易，因为你需要连接的端点数量相对较少，所以你可以更容易地确定对方是否已经升级。以SSH为例，它依赖于密钥的手动配置（通常在客户端初始连接时基于“首次使用即信任”）。一旦完成了这个设置，你就不需要去发现对等方的能力。相比之下，Web浏览器必须能够连接到任何服务器，包括它没有先前信息的服务器。

还有许多其他加密协议，我们从CRQC中恢复的能力会有很大差异。特别受影响的将是那些依赖长期数字签名的任何东西，因为它们很难替换。一个很好的例子是像比特币这样依赖签名来实现代币转移的加密货币系统：如果我能伪造你的签名，那么我就能偷走你的钱。对此的正确防御是用PQ密钥替换你的经典密钥（实际上是将钱转移到自己），但我们可以假设很多人不会及时这样做，一旦CRQC可用，任何未来的交易都会变得可疑。

围绕比特币的情况似乎实际上非常有趣。现代进行比特币转移的方式是将它们转移到公钥的哈希值而不是公钥本身（称为支付到公钥哈希（p2pkh））。只要公钥不被揭露，你就无法使用量子计算机伪造签名。为了转移硬币，公钥必须被揭露，但如果你不重复使用密钥，那么在签名和付款被纳入区块链之间只有一个狭窄的漏洞窗口（这并不依赖于公钥加密）。然而，根据德勤的一项研究，大约25%的比特币容易受到CRQC的攻击，所以情况并不乐观。

如果PQ算法不安全会怎么样呢？

以上所有假设都建立在我们有公钥算法确实能够抵御经典计算机和量子计算机攻击的前提下。在这种情况下，我们面临的问题“只是”从不安全的经典算法过渡到更或多或少兼容PQ替代算法。但如果那些算法最终被证明是不安全的，情况将变得非常糟糕。显然，世界几个世纪以来一直没有公钥加密也运转良好，但现在我们建立在公钥加密基础上的庞大生态系统将会变得不安全。

一些应用可能会被放弃（也许我们并不真正需要加密货币…），但显然，如果没有人能够安全地在亚马逊购物，使用谷歌文档，或者你的医疗记录无法安全传输，那将是非常不利的。因此，显然会有很大的动力采取行动。然而，可供选择的方案非常有限。

签名

我们确实至少有一种签名算法，我们有相当高的信心认为它是安全的：哈希签名算法，NIST正在标准化为“SLH-DSA”。不幸的是，性能非常糟糕（签名为8KB）。另一方面，慢且大的签名算法总比没有签名算法好，所以可能有一些应用会使用SLH-DSA。

密钥建立

虽然签名的故事很糟糕，但密钥建立的故事确实很糟糕。人们似乎正在考虑的主要选择是我一直称之为星际 Kerberos的某种变体。Kerberos 是麻省理工学院在80年代设计的一种安全协议，其原始形式的工作原理是让每个端点（用户、服务器）与密钥分发服务器 (KDC)共享一对对称密钥。

在高层级上，当爱丽丝想要与鲍勃进行通信时，她使用用她的配对密钥K_a 加密的消息联系KDC，并告诉KDC她想要联系鲍勃。KDC 创建一个新的随机密钥R_ab，然后向爱丽丝发送两个值：

（1） R_ab

（2）在鲍勃的密钥（K_b）下加密的R_ab的副本，即E(K_b, {Alice, K_ab})。在Kerberos术语中，这被称为“票证”。

爱丽丝随后可以联系鲍勃并出示票证。鲍勃解密票证并恢复K_ab。现在爱丽丝和鲍勃共享一个用于通信的密钥。请注意，所有这些都使用对称加密，因此不易受到我们的PQ算法的攻击。您可以在诸如TLS的协议中将这种类型的密钥建立机制连接起来（实际上TLS 1.2具有Kerberos集成，但未移植到TLS 1.3），并以一种接近传统方式的方式使用它们，尽管方式略显笨拙。

这种设计有很多挑战。首先，它更难管理。在基于公钥的系统中，客户端不需要与证书颁发机构（CA）建立直接关系，因为他们只需要CA的公钥。然而，在对称密钥系统中，每个客户端都需要与密钥分发中心（KDC）建立关系，以便建立共享密钥。这显然是一个巨大的操作挑战。

这种设计的基本挑战在于，KDC能够解密K_ab，因此能够解密Alice和Bob之间的所有流量。这是因为KDC提供了认证和密钥建立，与WebPKI等公钥系统不同，其中CA提供认证，而端点使用非对称算法执行密钥建立。这只是对称系统的固有属性，如果没有CRQC安全的非对称算法，我们就只能退而求其次。

一种潜在的缓解措施是使用多个KDC，然后爱丽丝和鲍勃使用与这些KDC交换派生的密钥。在这样一个系统中，攻击者需要comprom ise使用中的所有KDC以连接的一方或解密流量。最近，我们开始看到一些对这些线路的对称密钥类型解决方案的兴趣，包括IETF的草案和Adam Langley最近的博客文章。

（文章🔗：

https://www.imperialviolet.org/2024/04/07/letskerberos.html）

我觉得由于上面提到的缺点，这种系统不太可能在我们拥有PQ算法的情况下推广，即使它们效率不高。然而，如果最糟糕的情况发生，我们根本没有非对称PQ算法，我们将不得不采取措施，而基于对称加密的系统将成为备选方案之一。

宏观视角

正如我在上一篇文章中提到的，我们不应该期望PQ过渡会很快发生，因为算法并不是我们想要的，而且即使有更好的算法，过渡也非常具有破坏性。

然而，由于互联网非常依赖密码学，特别是公钥密码学，如果CRQC很快开发出来，就会有巨大的需求去做某事。

与完全没有安全通信的替代方案相比，我们之前认为没有吸引力甚至完全不可行的许多选择会突然看起来好得多，我预计在我们制定长期计划的同时，行业将不得不做出许多艰难的选择才能让任何事情发挥作用。

相关阅读

《专访亚数TrustAsia产品总监徐忠灏：量子计算真的遥不可及吗？》