PQC導入TLS 1.3實測，完整握手資料量增180%、CPU影響有限

PQC 進入 TLS 1.3：握手資料量激增 180%，CPU 負載卻僅增千分之一毫秒

資安公司 Red Sift 於 9 月 1 日公布最新測試，驗證量子安全密碼學（PQC）在 TLS 1.3 中的實作效能。測試結果顯示，當使用 ECDSA‑256 數位簽章搭配 X25519MLKEM768 混合式金鑰交換時，完整握手的傳輸資料量較傳統 ECDSA‑256 + X25519 基準組增加 180 %（從 1,258 位元組升至 3,522 位元組），但客戶端與伺服器端的 CPU 時間分別僅多 0.074 ms 與 0.042 ms，即「不到 0.1 毫秒」的微幅提升。

為何資料量會大幅上升？

• 混合式金鑰建立：TLS 1.3 允許同時使用傳統的 ECDHE（橢圓曲線 Diffie‑Hellman）與 PQC 的 ML‑KEM（模組格基式金鑰封裝）演算法。握手階段必須攜帶兩套金鑰交換資訊，導致訊息長度激增。
• 純 ML‑KEM‑1024：若拋棄 X25519，僅使用 ML‑KEM‑1024（較大安全參數）作為金鑰交換，握手資料量更升至 4,323 位元組，較基準增加 243.7 %。

網路層面的潛在影響

Red Sift 指出，伺服器端額外的握手資料會佔用 TCP 初始壅塞視窗（TCP Initial Congestion Window），在實際網路環境下可能限制連線建立的速度。更嚴重的是，客戶端目前通常不會在 ClientHello（TLS 握手的第一個訊息）中提供 ML‑KEM‑1024 的金鑰資訊；若伺服器僅支援此演算法，必須回覆 Retry（重試要求），迫使連線額外增加一次往返 RTT（Round‑Trip Time），在高延遲的公共網路上會顯著拖慢建立時間。

測試環境的限制

本次測試在同一台機器上同時執行客戶端與伺服器，網路延遲幾乎為零。因此，雖能清楚比較不同 PQC 金鑰建立方式的 CPU 與 資料量 差異，卻無法直接推論實際部署於廣域網路時的整體效能。

未來展望與建議

• 分層部署：考量到資料量與 TCP 初始視窗的限制，業者可先在支援混合式金鑰的環境中保留傳統 X25519，僅在需要量子抗性時逐步切換至 ML‑KEM。
• 協議優化：IETF 正在討論 TLS 1.3 PQC 擴充（如 RFC 8446 的後續草案），未來或會加入壓縮或延遲隱蔽機制，以減少額外的往返次數與封包大小。
• 觀察實際部署：隨著雲端服務與瀏覽器陸續支援 PQC，業界應持續監測實際流量中的握手延遲與帶寬占用，調整網路參數（如增大初始壅塞視窗）以維持使用者體驗。

總結來說，Red Sift 的測試證明 PQC 在 TLS 1.3 中的 CPU 負載 仍屬可接受範圍，然而 握手資料量 的顯著增加與可能的 TCP 限制，提醒部署者在推動量子安全時必須同步考量協議層與網路層的整體效能。未來隨著標準化與實作成熟，期待能在不犧牲效能的前提下，為網路通訊提供真正的量子抗性保護。