常见问答｜后量子TLS如何设计选择？
我们的许多加密算法都被设计为难以使用“经典”计算机来破解。但加入你有一台利用量子力学效应的量子计算机，那么破解这些算法可能就会轻而易举。
我说“可能”是因为情况不大确定，虽然人们已经开发出了量子计算机，但它们目前还达不到对现代密码算法发起攻击所需的规模。
然而，如果密码学相关量子计算机（CRQC）存在，其影响将是灾难性的，其可能会使几乎所有现有的密码学使用变得不安全。具体来说，它将破坏我们用来验证其他互联网用户并建立加密密钥的“非对称”算法，因此攻击者将能够冒充任何人和/或恢复用于加密数据的密钥。
出于这一原因，研究人员已经开始开发通常被称为后量子（PQ）的加密算法，这些算法旨在抵抗量子计算机的攻击，或者更准确地说，没有已知的量子算法可以让你破解它们（并不是说这些算法不存在）。
经过相当长的竞争，NIST发布了后量子密钥建立 ( ML-KEM ) 和数字签名 ( ML-DSA ) 的新标准 ，协议设计者和实现者开始考虑如何调整他们的协议以使用它们。
在这篇文章中，我想看看围绕这一转变的挑战，重点关注TLS和WebPKI的情况，尽管一些相同的问题也适用于其他设置。
为什么不立即进行转换？
显而易见的问题是，为什么不立即进行转换，就像我们从RSA等旧算法更改为基于椭圆曲线（EC）的新算法时所做的那样。原因是新的PQ算法并不明显优于目前主导该领域的EC算法。具体来说：
在很多情况下，性能会更差，就CPU、密钥、密文或签名大小而言。例如，ML-KEM比X25519（当前最流行的 EC 密钥建立算法）更快，但密钥要大得多，超过1000字节，而32字节。
对于签名来说，情况更糟，实际上没有任何标准化算法，这与基于EC的签名在某种程度上不是一个大的回归，并且由于需要在一个签名中携带大量签名。对于典型的协议交换，大小问题是一个大问题，特别是当出现兼容性问题时。总的来说，它们的整体性能概况都没有比EC更好。
我们不确定它们是否安全。对广泛使用的特定EC变体进行了大量的安全分析，虽然针对ML-KEM和ML-DSA 的问题进行了大量工作，但我的理解是，仍然存在真正的不确定性这些系统对传统计算机的安全性如何。
Daniel J. Bernstein（DJB） 一直是这一观点的最大拥护者之一，但业界的许多人对PQ算法有点坐立不安。我们不知道是否或什至何时会获得CRQC。
当前的量子计算机距离密码相关性还很远，进展很难预测。全球风险研究所已经制作了一份报告，其中估计了我们何时进行CRQC，结果如下：
由于这些原因，业界普遍对推出PQ算法非常谨慎。
威胁模型
由于经典密钥建立和数字签名基于相同的基础数学问题，因此CRQC对这些算法的影响也是相同的，也就是说非常糟糕。然而，安全影响却截然不同。
密钥建立
当您使用通过基于非对称密钥的建立协议派生的密钥（如 TLS）对流量进行加密时，这意味着您需要该密钥建立算法在数据的生命周期内也是安全的。
在这种情况下，这意味着现在使用EC算法建立的密钥发送的数据（也就是说大部分数据）如果有人开发 CRQC，将来可能会被泄露。攻击者甚至可能故意捕获互联网上的大量流量，押注最终将开发CRQC并且他们可以解密它（这称为“立即收获，稍后解密”攻击）。
因此，针对CRQC对密钥建立安全性的威胁采取措施是相当高的优先级，因为每天使用非PQ算法都会将其添加到最终可能可解密的数据堆中。尤其如此，因为即使在最好的情况下，转换也可能需要很长时间。例如，TLS 1.2于2008年首次添加了对AES-GCM等现代AEAD算法的支持，但Firefox和Chrome直到2013年才添加对TLS 1.2的支持，并且AEAD密码套件的数量并没有超过旧的基于CBC的密码直到2015年。因此，即使在最好的情况下，我们仍将在未来几年发送大量非量子安全流量。
数字签名
相比之下，数字签名算法只需要在您根据签名的有效性做出决策时是安全的；在TLS中，这是建立连接的时间。
如果在建立TLS连接后30秒开发出破坏签名算法的CRQC，那么只要您使用某种不易受攻击的方法建立密钥，您的数据就保持安全（当然，您的下一次连接将不安全，因此你会想要为此做点什么）。
出于这个原因，对数字签名采取一些措施通常被认为是一个较低的优先级，虽然如果建立了CRQC而我们还没有部署任何PQ签名算法，确实非常不方便，因为每个人都会争先恐后地赶上。当然，可能有人——很可能是某种国家情报机构——已经拥有CRQC并且没有透露，但即便如此，这也比让你的通信受到任何人的攻击要好得多，只要他们有Amazon Prime，就可以在一夜之间将QC寄给他们。
威胁模型中的这种不对称性很方便，因为如上所述，没有人对 PQ 签名算法感到兴奋，而 PQ 密钥建立算法似乎相当合理——当然假设它们是安全的。因此，人们将注意力集中在密钥的建立上，并且大多祈祷签名情况能够在紧急情况之前得到改善。
对象安全签名
请注意，对于基于对象的协议（例如电子邮件）中的签名，情况有所不同，因为人们希望能够在消息发送后很长时间内验证签名。因此，即使与经典签名配对，拥有 PQ签名也确实有帮助，因为它允许签名在CRQC的后续开发中继续存在。
还可以通过对签名加时间戳来证明经典签名是在CRQC开发之前创建的，从而使经典算法在CRQC的开发过程中继续存在。例如，您可以安排使用某些区块链类型系统注册签名文档的哈希值。然后，您可以提供与时间戳证明配对的签名文档（请注意，时间戳服务不需要验证签名本身；它只是证明它在时间X看到了该文档。）。依赖方可以验证签名是在CRQC开发之前进行的，在这种情况下，它大概是值得信赖的。
传输安全协议中的加密算法
出于本文的目的，我想重点关注TLS等传输安全协议。这些并不是世界上唯一的加密协议，但它们说明了许多正在发挥作用的问题，特别是我们如何从一组算法过渡到另一组算法。
在某个时间点（通常称为“标志日”）从旧算法批量切换到新算法显然是不切实际的。我们花了几年（实际上是几十年）的时间来部署我们在生态系统中拥有的一切，任何重大变化也都需要时间。
相反，TLS和大多数类似协议都被明确设计为具有所谓的算法敏捷性，这种能力同时支持多种算法，促进端点可以与新旧对等方通信，从而促进从旧到新的渐进式脚本。
下图提供了 TLS 握手的程式化版本。客户端发送第一条消息（ClientHello），其中包含一组“密钥共享”，一个对应于它支持的每个密钥建立算法。对于椭圆曲线算法，这意味着每条曲线都有一个密钥共享。当服务器响应它的ServerHello消息时，它将选择这些组之一，并使用来自同一组的密钥发送自己的密钥共享。然后，每一方都可以将自己的密钥共享与另一方的密钥共享组合起来，生成双方都知道的密钥。然后可以使用该共享密钥来派生密钥以保护应用程序数据流量。
当然，我们还需要对服务器进行身份验证。通过让服务器提供证书并签署握手记录（每个人发送的消息方）在其证书中使用与公钥对应的私钥。
但如上所述，签名算法有多种，因此需要ClientHello告诉服务器客户端支持哪些签名算法，以便服务器可以选择合适的证书。当然，如果服务器没有与客户端的任何算法相匹配的证书，那么客户端和服务器将无法通信。
请注意，这里实际上有多个签名，因为证书既有服务器的密钥，又有CA拥有的某个密钥签名。这些密钥可能具有不同的算法，并且都必须位于客户端公布的列表中。此外，CA可能有自己的证书，并且该签名也必须使用适当的算法，然后还有CT SCT。
后量子算法恰好适合这种结构。每个PQ算法都被视为一条新的椭圆曲线（即使它们在密码学上确实没有任何共同点），并且签名算法的行为相同（尽管如上所述，结果要大得多）。更好的是，所有密钥共享的生成和选择都是在TLS堆栈内部完成的，因此只需更新软件即可推出新的密钥建立算法，而无需用户执行任何操作（这就是EC的方式）是首先部署的。
当然，如果您的软件可以远程更新或至少定期更新，那么这会容易得多；如果我们谈论的是灯泡中的软件，情况可能会更糟。
相比之下，为了部署新的签名算法，您需要一个新的证书，尽管证书部署现在已经部分自动化，但还没有自动化到人们期望新的签名算法和相应的证书会在他们的服务器中弹出的程度。此外，某些服务器未设置为并行拥有多个证书。考虑到上述部署现实、性能差距和威胁模型差异，围绕部署PQ密钥建立的活动比围绕签名的活动多得多也就不足为奇了。
当前的部署情况
在过去几年中，我们看到了许多PQ算法的实验性部署，主要用于密钥建立。
密钥建立
大多数密钥建立部署都是采用所谓的“混合”模式，也就是说并行使用两种密钥建立算法。
·经典的EC算法，如 X25519
·像ML-KEM这样的PQ算法
例如，Chrome最近宣布推出X25519/Kyber-768（Kyber是现在ML-KEM的原始名称，经过一些修改后成为ML-KEM ）混合动力，而Firefox也正在进行相关工作。
这些混合方案的工作方式是，您发送两种算法的密钥共享，然后计算这两种算法的共享密钥，最后将共享密钥组合到整体加密密钥计划中，您可以使用该计划来派生用于加密流量的密钥。
但在TLS 1.3中的做法很简单：你只需为传统算法和后量子算法对发明一个新的算法标识符，密钥份额即为密钥对。同样，组合算法会发出一个新的密钥，该迷药通过组合各个算法的迷药形成的。这与TLS的模块化设计非常契合，因为它看起来就像你定义了一个新的椭圆曲线算法，而TLS堆栈的其余部分不需要知道更多细节。
像这样的混合设计的优点是——假设它做得正确——它可以抵抗任何一种算法的失败。只要两种算法之一是安全的，那么生成的密钥将对攻击者保密，并且生成的协议将是安全的。这使您可以购买一些相当便宜的保险：
如果有人开发了CRQC，连接仍然受到PQ算法的保护。
如果事实证明PQ算法毕竟很弱，那么流量仍然用经典算法进行保护。
当然，如果PQ算法出现问题，那么在有人开发CRQC的情况下，流量就无法得到保护，但至少我们的状况不会比以前更糟，除了PQ经典算法的额外成本，正如上文所述，这个成本相对较低。
所有这些使得推出相当容易：客户端和服务器可以独立地为他们的实现添加对PQ混合的支持，并配置他们的客户端以优先选择这些算法而不是经典算法。当两个支持PQ的实现尝试连接到彼此时，它们将协商混合算法，否则将使用经典算法。
最初，这意味着几乎不会使用混合算法，但随着更新后的实现被广泛部署，将会越来越多地使用混合算法，直到最终大多数流量都受到CRQC的保护。这与我们历史上用来推出新的TLS密码套件以及新版本的TLS（如TLS 1.3）相同的过程。
当然，直到几乎所有对等方都支持PQ混合算法之前，对客户端或服务器禁用经典算法是不安全的；如果你过早禁用对它们的支持，那么你就无法与那些尚未升级的人进行通信，这显然是不好的。对于许多应用程序来说，这是一个很好控制的问题：例如，只要你的邮件服务器支持PQ混合算法，你就可以在邮件客户端中禁用经典算法。
然而，Web是一个特殊情况，因为浏览器必须能够与任何服务器通信，服务器也需要能够与任何浏览器通信，因此Web客户端和服务器通常对禁用算法的时间非常谨慎。标准程序是同时提供新旧算法，然后测量新算法的部署水平，只有当几乎没有对等方不支持新算法时才禁用旧算法。除非有强烈迹象表明CRQC即将到来，否则我预计会有很长一段时间客户端和服务器（尤其是服务器）不支持PQ混合算法，部分原因是PQ混合算法只在TLS 1.3中而不是TLS 1.2中存在，并且仍然有相当多的仅支持TLS 1.2的服务器。这也将使浏览器难以禁用经典算法，即使他们想这样做。
如果开发出了可行的CRQC，那么其他人就有必要立即切换到后量子密钥建立算法，但这还不够。如果你接受传统算法进行身份验证，攻击者就能够冒充服务器。这意味着在CRQC存在之后，你还需要让所有人切换到PQ签名算法。开发出可行的CRQC，那么其他所有人都需要快速切换到后量子密钥建立算法，但这还不够。如果您接受经典的身份验证算法，攻击者将能够冒充服务器。这意味着CRQC存在之后，还需要让大家都切换到PQ签名算法。
数字签名
相比之下，PQ算法在签名领域的应用非常少，主要原因如上所述，即：
·部署新的签名算法比部署新的密钥建立算法要困难得多。
·感觉没有那么紧迫，因为未来的CRQC主要影响未来的连接，而不是当前的连接。
·签名算法并不是那么出色。所谓“不是那么出色”，指的是用ML-DSA替换我们当前的算法将导致在TLS握手中添加超过14K的签名和公钥。作为比较，我刚刚尝试连接到google.com，服务器发送了4297字节。
在我们进行任何部署之前，我们首先需要更新WebPKI证书的签名算法标准。从技术角度来看，这是相当简单的（除了与证书相关的性能和大小问题），因为你只需为签名算法分配代码点。然而，与密钥建立的情况不同，这只是整个过程的开始。
在网络上，证书颁发机构的实践在一定程度上受一组规则（基线要求）的管理，这些规则由CA/Browser Forum管理，该组织在添加新算法方面一直非常保守。例如，尽管TLS生态系统的大部分已经转向新的现代椭圆曲线X25519，但基线要求仍不支持这些曲线用于数字签名。因此，首先需要发生的事情是CABF为某种PQ算法或PQ混合算法添加支持（下文将详细介绍）。在商业硬件安全模块可以执行PQ签名之前，这可能不会发生。
一旦新算法被标准化，那么：
·CA必须生成新的密钥用于签署终端实体证书。
·这些密钥（嵌入在CA证书中）需要提供给供应商，以便他们将其分发给用户。
·证书透明日志也需要获取PQ证书。
·服务器需要生成自己的PQ密钥，并获取由CA和CT日志签署的新证书。
请注意，这种过渡远比通常添加新签名算法要糟糕得多。例如，希望使用EC密钥进行身份验证的服务器不一定需要等待CA拥有EC密钥，因为CA可以用RSA密钥为EC密钥签发证书，因为RSA仍然是安全的，只是速度较慢。这意味着您可以逐步推出，并且随着替换算法，事情会逐渐变得更好。但是，PQ过渡的整个前提是我们不信任经典算法，因此最终您需要让整个证书链使用新算法。当然，可以有混合链，但这更适用于部署实验而不是提供真正的CRQC安全性。实际上，随着逐步推出，事情变得更慢，但直到很久以后才能获得安全性好处，这实际上是错误的激励机制。
一旦发生这一切，当更新的客户端遇到更新的服务器时，那么更新的服务器可以提供其新的仅PQ或PQ混合证书。就像密钥建立一样，客户端和服务器都需要支持经典算法，直到他们可能接触到的每个端点有效支持PQ。对于客户端来说这没什么大不了，但对于服务器来说，这意味着它需要很长时间同时拥有常规证书和PQ证书。
然而，与密钥建立不同的是，在这个过渡期间，无论客户端还是服务器都没有从使用PQ算法中获得任何安全好处。这是因为在TLS中，签名算法的安全性仅在连接建立时才相关。有两种主要可能性：
1. 没有使用CRQC的人试图攻击您的连接，在这种情况下，传统算法就足够好了。
2. 有人使用CRQC试图攻击您的连接，在这种情况下，他们将只攻击传统密钥而不是PQ密钥。
为了在这种情况下从PQ签名中获得安全好处，依赖方需要停止信任传统算法，从而防止攻击者攻击这些密钥。在Web环境中，这意味着Web浏览器需要禁用这些算法；在此之前，PQ证书不会使任何内容更安全，但会使其更昂贵，这并不是一个很好的销售主张。
因此，我预计会发生的情况是，客户端对PQ签名的支持将得到广泛部署，但PQ证书的部署范围将较小。绝大多数客户端由少数几家厂商（四大浏览器厂商）生产，对他们来说，这是一个相当容易的变化。相比之下，虽然服务器在某种程度上集中在如Google、Facebook或大型CDN等大型网站上，但还有很多长尾服务器不会被激励去做这种改变。特别是，我将会对有足够多的服务器采用基于PQ的签名以便实际上禁用传统签名而不受来自客户端厂商的强烈压力的情况感到非常惊讶。
作为参考，对SHA-1的首次有效攻击是在2004年公布的，直到2017年SHA-1才在证书中被弃用。此外，即使Chrome宣布他们将弃用SHA-1，实际上仍然花了三年时间才实现。SHA-1和SHA-2之间的差异对性能或证书大小没有实质影响，因此这实际上只是一个过渡阻力的问题。这并不是一个非典型的例子：绝大多数证书包含RSA密钥，并使用RSA密钥签名，尽管ECDSA对服务器来说更快，且具有更小的密钥和签名。
最近对WebPKI生态系统进行了一些改变，以使过渡更容易（例如，缩短证书寿命），但过渡到PQ证书会带来更糟糕的性能后果，因此我们应该预计PQ过渡将是一个缓慢的过程。
混合算法与纯PQ算法之争
一个重要的争议点是是否主要支持将经典算法和PQ算法结合起来的混合系统，还是纯PQ算法。正如上文所述，行业似乎正在趋向于在密钥建立方面采用混合系统，但签名的问题更加不确定。
所有这一切的背景是，美国国家安全局和英国政府通信总部强烈支持纯PQ算法而非混合系统。2023年11月，英国政府通信总部发布了一份白皮书，主张采用纯PQ方案而非混合系统：
未来，如果CRQC存在，传统的PKC算法将无法为抵御具有CRQC的攻击者提供额外保护。此时，PQ/T混合方案将提供的安全性不会比单个后量子算法更高，但会带来更多的复杂性和开销。如果选择PQ/T混合方案，英国国家网络安全中心建议将其用作临时措施，并应在一个灵活的框架内使用，以便未来能够轻松过渡到仅使用PQC。
同样，美国国家安全局的商业国家安全算法2.0（CNSA 2.0）指导文件中包含一些文本，许多人解读为最终将不允许混合方案：
尽管由于协议标准、产品可用性或互操作性要求，混合解决方案可能被允许或要求使用，但在特定日期，CNSA 2.0算法将成为强制选择，仅选择CNSA 1.0算法将不再获得批准。
这并不是世界上最清晰的语言，但最好的解读似乎是他们不想允许混合解决方案。另一方面，在上周的IETF 119上，NIST的Quynh Dang表示，NIST对混合解决方案没有问题。
具体的时间表因产品而异，但对于这篇文章最相关的部分，他们表示希望到2033年时，Web浏览器和服务器仅支持CNSA 2.0。
即使您将其解释为“仅限纯PQ”，这在实践中仍有些不清楚。请记住TLS的工作方式是客户端提供一些算法，服务器选择其中一个；这意味着服务器应该能够选择纯PQ算法，只要有足够多的浏览器支持它们，这似乎可能发生，尽管据我所知，当前没有浏览器支持它们。然而，仅支持PQ模式对于浏览器来说是不太可行的，除非您永远不想连接到互联网上的服务器，正如上文所述，这些服务器不太可能全部支持纯PQ。即使是政府系统在2035年是否会配置为禁用混合模式？
CNSA 2.0指南之所以重要有两个原因。首先，许多应用程序很可能会感受到遵守CNSA 2.0的强大压力。当然，如果供应商决定只使用混合方法，NSA最终可能会屈服并批准，但人们理所当然地不愿意冒险尝试。其次，GCHQ和NSA提出了许多关于为什么选择PQ算法而不是混合方法的论点。这篇文章已经变得相当长，所以我不想详细讨论这些论点，但它们主要归结为混合方法会带来更多的问题（因此更复杂、成本更高等），而且如果有一个很好的CRQC，那么系统的经典部分在安全性方面并没有太多的增益。
关于混合方法的另一个担忧是性能问题。显然，混合方法比纯PQ更昂贵，但这种差异可能不是一个重要因素。PQ密钥和签名要大得多，因此拥有经典算法的增量大小对系统的影响微不足道。ML-KEM比X25519快得多，但X25519已经非常快，我觉得人们对此并不担心。类似地，ML-DSA在验证方面大约比EC快两倍，但在签名方面看起来要慢大约4倍，这有点误导，因为在大多数TLS的使用中，需要担心性能的是服务器，签名就是发生在这里，因此EC的增量成本并不是一个大问题。
我不确定这些论点对我的说服力有多大，但我认为它们最多只是边缘性的论点。特别是，并没有真正的理由相信部署混合方法本质上是不安全的，即使经典算法很容易被破解。假设我们设计得当，最终的系统应该只具有混合方法中PQ部分的安全性。我看到有人建议，严重到足以破坏系统的经典部分的实现缺陷（例如，内存损坏）可能会危及PQ部分。当然，这并非不可能，但现代软件存在大量易受攻击的代码，因此很难将其视为决定性因素。
密钥建立
如上所述，密钥建立中大部分能量都集中在混合模式中。目前，这些模式易于部署，看起来比纯PQ算法更安全，至少目前是这样。特别是在TLS中，可能会发生以下情况：
TLS工作组将标准化一组基于ML-KEM的混合算法，并建议人们使用它们。
IETF将为纯ML-KEM分配一个代码点（算法标识符），但它不会成为标准，IETF也不会推荐（或不推荐）其使用。
可能的结果是会有很多混合使用，但人们也可以选择使用纯ML-KEM。在某个时候，人们的看法可能会转向纯ML-KEM，在这种情况下，TLS工作组可以将该文档拿出来并将其标准化。然而，如上所述，即使有一个工作中的CRQC，这也并非紧急的事情：人们可以多花一点CPU和带宽来进行混合，同时进行从混合到纯PQ的过渡。
数字签名
关于是使用混合还是纯PQ进行签名的问题仍然在激烈争论中。正如我上面提到的，似乎很明显服务器在一段时间内将需要经典算法和PQ签名两者。相关问题是它们将如何组合在一起。
看起来服务器可能会有一个证书采用经典算法（例如ECDSA），就像今天一样，然后另一个证书采用后量子算法。这可以有两种方式：
·用纯PQ算法（ML-DSA）
·既有经典算法（例如ECDSA），又有PQ算法（ML-KEM）。与密钥协商一样，它们将被打包成一个密钥和一个签名，这个签名是两种算法的组合，语义是两个签名都必须有效。
有一段时间，我的直觉是更容易只做PQ：因为PQ算法效率低下，客户端和服务器很可能更倾向于经典算法，除非明确经典算法不安全，因此PQ证书中包含的内容并不重要。如果明确实施必须不信任经典算法——考虑到PQ证书的部署水平可能会非常高，这个过渡将会非常困难——那么混合中的经典部分对你来说并没有太大意义。
现在，考虑相反的情况，即PQ算法出现问题。在这种情况下，您希望不信任该算法并回到经典算法。与不信任经典算法相比，不信任PQ算法相对容易，因为每个人仍然会长时间拥有经典证书，因此依赖方（例如浏览器）可能只需关闭PQ算法，那么您实际上并不需要混合证书以保持连续性。
这在某种程度上是正确的，但也是一种浏览器供应商的思维方式，因为他们对远程配置其客户端有很好的支持，所以实际上可以在几天内关闭算法对大多数用户来说是可行的。然而，对于许多需要更长时间才能更新的软件，这并不适用，对于那些客户端和服务器来说，如果他们信任的只有经典（仍然可以）和PQ混合（现在与经典证书一样安全），那么世界将更加安全。此外，还有可能会发生PQ算法的秘密破解，即使是浏览器也不会更新（对于秘密CRQC，我们唯一能做的就是停止信任经典算法）。出于这些原因，我开始认为混合是短期内PQ凭证的最佳选择。
写在最后
度过这一过渡期将对我们的加密协议中建立的敏捷机制带来很大压力。在许多方面，TLS的定位要比许多常用协议更好，这既因为交互式协议本质上能够协商算法，也因为TLS 1.3的设计使得这种过渡变得实际可行。即便如此，这一过渡可能会非常困难。虽然TLS本身被设计为算法敏捷，但它通常嵌入在那些本身无法快速迁移的系统中。
许多专有的TLS用途，比如应用程序与供应商的通信，应该能够迅速无缝地切换。例如，Facebook只需在应用商店更新他们的应用和服务器，问题就解决了。
网络将会更加困难，因为它是一个多元化的系统，服务器端几乎没有中央控制。另一方面，浏览器通常由供应商进行中央控制，这意味着大多数浏览器用户群体能够快速变更。当然，在嵌入式设备（电视、Kindle等）中仍有大量使用较老浏览器的情况，它们可能会更难更新。
除了这两种情况，还有大量TLS部署处于糟糕状态，无法轻松进行远程更新（比如许多物联网设备）。取决于这些设备需要通信的客户端或服务器的行为，它们可能会陷入脆弱状态（如果对等方不强制使用后量子算法），或者干脆无法通信。
不幸的是，一个不太顺利的过渡实际上是最好的情况。最可能的结果是，除非有强有力的证据表明经典算法出现了削弱，否则我们将长时间广泛部署后量子或混合密钥建立，而几乎不部署后量子签名算法，尤其是如果后量子签名算法没有得到改善的话。
更糟糕的是，如果在未来几年内有人开发出CRQC——远早于我们有机会彻底放弃经典算法的时间——我们将不得不争分夺秒地紧急替换一切。
（本文首发自公钥密码开放社区，点击了解“公钥密码开放社区”，作者：Eric Rescorla）