PQC導入TLS面臨效能挑戰，交握延遲增加、防火牆相容性問題浮現

隨著後量子密碼學（Post-Quantum Cryptography，PQC）逐步應用於TLS連線，交握期間需要傳輸的資料量也可能增加，進而延長連線建立時間，甚至影響既有網路設備的正常運作。資安業者Red Sift近期彙整Google、Cloudflare及多項學術研究，分析PQC在實際網路環境中的效能與相容性問題。該公司先前測試PQC對TLS 1.3交握效能的影響，發現採用混合式金鑰建立機制X25519MLKEM768後，完整TLS交握的資料量增加約180%，但用戶端與伺服器端CPU處理時間各增加不到0.1毫秒。

Google Chrome導入混合式PQC金鑰建立機制後，曾觀察到TLS交握延遲增加約4%。根據文章引用的資料，這項機制使ClientHello訊息增加約1KB，整體大小因此超過約1,400位元組的最大傳輸單元（MTU），需要分成兩個封包傳輸。交握訊息分成多個封包後，也更容易受到封包遺失等網路傳輸條件影響，即使演算法本身的CPU運算成本有限，仍可能延長連線建立時間。

既有防火牆及安全閘道器也可能無法正確處理PQC交握。部分設備遇到分成多個封包傳輸的ClientHello訊息，或新的TLS擴充欄位時，可能導致連線失敗。文章舉出Sophos防火牆過去在特定網頁防護檢查模式下曾出現相容性問題，AWS Network Firewall也曾在處理OpenSSL 3.5.1的PQC交握時發生規則比對問題。至於CDN與原始伺服器之間的TLS連線，Cloudflare的研究顯示，若用戶端初次提供的金鑰交換資訊不包含伺服器選擇的金鑰建立機制所需資料，伺服器可能透過HelloRetryRequest要求用戶端重新提供金鑰交換資訊，使TLS交握增加一次網路往返。Cloudflare也提出自動調整邊緣節點與原始伺服器之間金鑰交換偏好的方法，以減少因初始金鑰交換資訊不符合伺服器需求而增加的交握延遲。

PQC未來進一步用於數位憑證，也可能增加TLS交握的傳輸負擔。目前採用抗量子密碼演算法的憑證鏈尚未廣泛部署於公開網站的公開金鑰基礎建設（PKI）環境，但隨著PQC應用於數位簽章，較大的簽章及憑證鏈可能增加交握期間需要傳輸的資料量。文章引用的學術研究發現，在網路狀況良好的測試環境下，較大型PQC憑證鏈使初始TLS交握延遲增加20%至30%。不過，對於需要傳輸大量應用資料的連線，交握增加的時間占整體傳輸時間的比例可能較低。

IoT及嵌入式設備則面臨不同的限制。這類裝置通常只有有限的記憶體、封包緩衝區及網路頻寬，較大的金鑰與數位簽章資料可能增加負擔，但不代表採用PQC後效能一定會變差。一項針對Raspberry Pi Pico W等微控制器的研究則發現，部分採用模組格基式金鑰封裝機制（ML-KEM）的TLS 1.3交握組態，效能反而優於傳統密碼演算法組態，在特定測試條件下最高快約41%。

PQC導入受限設備的問題也受到網際網路工程任務小組（IETF）關注。IETF於2026年6月發布RFC 9958，說明PQC使用的較大型金鑰、密文及數位簽章可能增加IoT等受限設備的網路傳輸負擔，延長交握時間、提高能源消耗，並增加封包分段處理需求。IETF也持續研究PQC在受限設備上的部署問題，反映企業進行PQC轉型時，除了演算法效能，也須考量既有設備的硬體資源及網路環境限制。