在我們關於後量子密碼學（PQC）的系列部落格文章中，我們幾乎完全專注於 HTTP 環境中的傳輸層安全性（TLS）協定。解決內容傳遞網路（CDN）環境中的「先收穫，後解密」威脅對 Akamai 來說顯然是一個高度優先事項，我們很高興能夠在 TLS 1.3 交握中為客戶到Akamai 和 Akamai到源站連線提供 PQC。

在接下來的幾週內，這些功能將陸續推出，並作為所有 Enhanced TLS 客戶的預設開啟功能。

儘管這與業界其他公司的優先順序一致，但量子威脅影響了所有密碼學領域，而不僅僅是TLS。在這篇部落格文章中，我們將探討在實現量子安全方面需要關注的一些其他協定和服務。

易受量子威脅的演算法

實際上，我們關心任何使用已知易受量子威脅的演算法的軟體；也就是說，任何使用非對稱金鑰密碼學（例如，使用RSA 或 Diffie-Hellman 金鑰交換的密碼學）以及數位簽章（例如，橢圓曲線數位簽章演算法 [ECDSA]是主要關注點）。

值得注意的是，雖然 TLS 涵蓋了 HTTP 生態系統中最大的表面積，但它也被許多其他應用程式使用，包括：

• 使用 STARTTLS 或透過 465 連接埠使用隱式 TLS 提交的簡易郵件傳送協定（SMTP）（依據 RFC8314）

• 基於 TLS 的網際網路訊息存取協定（IMAP）或郵局協定（POP）

• 基於 TLS 的輕型目錄存取協定（LDAP）

• 基於 TLS 的虛擬私人網路（VPN）

• 現代網路分段服務，如 Akamai
  的零信任網路存取（ZTNA）

• 用於某些即時通訊服務的可延伸訊息與呈現協定（XMPP）

由於所有這些服務都使用 TLS 進行流量加密和端點驗證，將這些服務升級以使用我們在先前的部落格文章中詳細討論的後量子/傳統（PQ/T）混合金鑰交換演算法（即 X25519MLKEM768），同樣將有助於保護它們免受量子威脅。

然而，其他應用程式和服務使用不同的協定，同樣需要實施 PQ/T 混合金鑰交換演算法，並開始使用後量子簽章演算法。

安全殼層（SSH）

這裡的一個主要例子是無所不在的 SSH 協定。如您所知，SSH 也使用公開金鑰密碼學來執行驗證，因此需要配置為使用正確的金鑰交換演算法以提供量子安全性。

使用最廣泛的 SSH 實作 OpenSSH，自 2021 年以來已支援PQ/T 混合配置中的 Streamlined NTRU Prime (SNTRUP) 演算法。2024 年，FIPS203 模組格柵為基礎的金鑰封裝機制（ML-KEM）與 X25519 ECDH 結合（如*[網際網路工程任務組（IETF）定義]*）被添加，並從 9.9 版開始成為預設的金鑰交換演算法 —— 這意味著只需升級您的作業系統，今天就能保護您。

若要驗證您的 OpenSSH 版本是否支援 PQC，請執行以下命令：

此外，您會注意到最新版本的 OpenSSH 用戶端（10.1版及以上）會在您連接到不使用後量子金鑰協定的伺服器時主動發出警告：

這種行為是向後相容的，這意味著不支援 PQC 的用戶端只會使用傳統的金鑰交換演算法，因此在這裡更新您的 SSH
部署應該是相當無痛的。

虛擬私人網路（VPN）

VPN 可能使用 TLS 來建立其加密隧道，因此能夠利用常見的 X25519MLKEM768 混合金鑰交換來使這些隧道具備量子安全性。

然而，並非所有 VPN 都必然使用TLS；相反地，許多實作是基於網際網路協定安全性（IPsec），它使用網際網路金鑰交換（IKE）。IKE通常基於 Diffie-Hellman 金鑰協定，並包括例如用於驗證的 x509 用戶端憑證。這些機制仍然容易受到量子威脅，因此需要進行與 TLS 類似必要的更新。

[RFC9370] 定義了 IKEv2 允許多重金鑰交換（從而建立複合金鑰）的方法。一個*[單獨的草案]* 指定了如何使用ML-KEM作為這樣一個額外的金鑰交換。這允許將傳統金鑰與後量子金鑰結合起來，類似於我們從TLS 熟悉的混合 PQ/T 金鑰交換。

不同的網路設備供應商對 IPSec VPN 中 PQC 的支援程度不同。請向您的供應商查詢他們在這些產品中目前的後量子準備情況。

訊息

在更高的應用層上，使用最廣泛的服務之一——尤其是在行動裝置上——包括簡訊。這個領域主要由WhatsApp、Apple Messages、Signal以及任何使用豐富通訊服務（RCS）協定的應用程式或服務（例如 Google Messages）主導。

Signal 和 WhatsApp 都使用 [Signal 協定]，該協定在2025年引入了*[稀疏後量子棘輪（SPQR）]。密碼學專家普遍[認為]* 這是一個設計良好的工程解決方案。

同樣地，Apple 早在 2024 年 2 月就宣布了其 Apple Messages的*[後量子路線圖]*，引入了他們的 "PQ3" 後量子密碼協定。然而，此協定僅保護iMessage；使用 SMS 或 RCS 發送的訊息（在 Apple 裝置上以綠色而非藍色文字氣泡顯示）仍然依賴傳統密碼學。

Google Messages 早在 2020 年就提供了（傳統）[端到端加密]，但這直到 [RFC9420] 中定義了訊息層安全性（MLS）協定後才標準化。不出所料，目前已有*[正在進行的努力]* 將ML-KEM和其他後量子演算法納入，這些已包含在*[官方規範]*中。我們預期隨著即將到來的更新，這些技術的採用將慢慢增加。

OpenPGP

在 [RFC9580] 中定義的OpenPGP，透過數位簽章提供對稱和非對稱加密及驗證。儘管多年來對其格式本身以及一些最廣泛使用的實作的可用性存在擔憂和挫折，PGP仍然被頻繁使用，特別是開源專案和其他軟體供應商用來為其軟體版本或安全公告提供完整性和真實性保證。

許多組織也使用 OpenPGP 進行電子郵件加密通訊。例如，Akamai允許安全研究人員使用我們在 [Akamai漏洞回報]頁面上發布的*[公開
PGP 金鑰]* 與我們的安全團隊溝通。

因此，OpenPGP 標準必然受到量子威脅，需要更新以允許使用 PQC 演算法。在 IETF 的OpenPGP 工作小組中，正在制定一份*[新草案]*，該草案「定義了基於 ML-KEM（前身為CRYSTALS-Kyber）的複合公開金鑰加密、基於 ML-DSA（前身為CRYSTALS-Dilithium）的複合公開金鑰簽章（兩者皆與橢圓曲線密碼學結合），以及作為獨立公開金鑰簽章方案的
SLH-DSA（前身為 SPHINCS+）。」

此草案已經有[一些採用的跡象]，但與我們討論的許多其他密碼學工具和函式庫一樣，您需要密切追蹤您所用軟體的官方版本，以便在它們發佈時能夠採用和整合新版本。我們可能還需要一段時間才能看到PQC 廣泛應用於例如軟體套件簽章等領域。

DNSSEC

最後，我們需要談談房間裡的大象。是的，就是 DNS。（總是DNS，對吧？）或者，更具體地說，是 DNSSEC。

網域名稱系統安全性延伸（DNSSEC）為 DNS 資源記錄（RR）提供加密簽章，主要（再次）使用 RSA 和 ECDSA
作為簽章演算法。這當然意味著這些簽章易受量子威脅，任何依賴 DNSSEC來保證完整性和真實性的系統都將需要採用後量子密碼演算法。

然而，正如我們[之前討論過的]，從傳統演算法轉向PQC 演算法時，簽章和驗證效能以及簽章大小都會顯著增加。與 HTTPS 用例相比，DNS主要透過 UDP 使用這一事實加劇了這個問題，因為較大的簽章將無法再放入單個 UDP回應封包中。

這可能導致 TCP回溯、封包分段、回應時間變慢以及許多其他可能的複雜情況——更不用說漫長而[複雜的]演算法轉換過程，該過程必須從根區域的金鑰簽署金鑰（KSK）開始協調，並且在過渡期間可能需要在所有已簽署的區域中使用多重簽章。

雖然業界尚未完全同意前進的正確方法，但一些獲得關注的提案和[策略草案] 涉及使用FN-DSA（即未來的 [FIPS206]）或者，在[梅克爾樹階梯（MTL）] 模式中使用 [FIPS205 無狀態基於雜湊的DSA（SLH-DSA）] 簽章。

這種方法將透過避免簽署和驗證每個單獨記錄，轉而簽署梅克爾「樹階梯」來降低簽章成本，這個概念類似於[梅克爾樹憑證]，後者旨在幫助解決
TLS 生態系統中關於多重簽章的類似問題。

在 DNSSEC 的背景下，採用 PQC 演算法的緊迫性可能不像保護 HTTPS流量免受「先收穫，後解密」攻擊那樣立即，因為 DNS流量的真實性和完整性保證不受事後攻擊的影響。然而，執行[根 KSK演算法轉換]的複雜性意味著我們需要規劃更長的時間線，才能完成所有DNS 的切換。

再加上如上所述，我們甚至尚未就最終解決方案達成共識，即使考慮到量子電腦的預期時間範圍以及不同司法管轄區的[合規要求]，這也意味著我們不能延遲這項工作。

結論

儘管 Akamai 在 HTTPS 生態系統內採用 PQC 方面處於領先地位，已經為 TLS1.3 [啟用]了
PQ/T混合金鑰交換，但要讓所有其他系統和服務實現量子安全，還有大量工作要做。對於我們上面討論的一些服務（例如SSH），遷移會比較容易，但對於其他服務（例如 DNSSEC）則會複雜得多。

建構在 TLS 之上或使用 TLS 的系統使遷移變得更容易，因為大多數函式庫和工具包現在都支援 PQ/T 演算法，並且供應商已開始提供這些保護。然而，保持您的加密庫存更新、識別哪些元件已準備好更新以及追蹤最新軟體版本的成本仍然很高。

對於其他協定，我們建議您密切關注業界的最新發展，並參與 IETF 和其他標準討論。隨著我們繼續將 PQC 帶給更多我們自己的服務，我們也將繼續在這個部落格系列中向您通報最新情況。

系列中的先前文章

如果您錯過了本系列的任何先前文章，現在可以查看它們。

• [數位簽章：傳統與後量子密碼機制]（發佈於2025 年 12 月 3 日）

• [國際後量子密碼學標準指南]（2025 年 10 月 8 日 ）

• [Akamai在邊緣啟用後量子密碼學]（2025 年 9 月 3 日）

• [TLS中後量子密碼學的實作考量]（2025年 8 月 6 日）

• [建構量子安全網際網路：IETF 的 TLS計畫]（2025年 6 月 18 日）

• [採取措施為量子優勢做準備]（2024年 8 月 12 日）

• [Akamai與後量子密碼學的採用]（2023年 4 月 27 日）