Red Sift 實測顯示，TLS 1.3 導入 PQC 混合式金鑰建立後，完整握手資料量明顯增加，但 CPU 成本仍低；真正風險在於握手封包膨脹可能壓縮 TCP 初始壅塞視窗，影響連線建立效率。
資安業者 Red Sift 近期針對 TLS 1.3 導入後量子密碼學（PQC）的實際效能進行測試，結果顯示，當採用 ECDSA-256 數位簽章搭配 X25519MLKEM768 混合式金鑰建立機制時，完整 TLS 握手資料量相較基準組大幅增加 180%。基準組為 ECDSA-256 搭配 X25519。來源
這項測試由 Red Sift 首席科學家 Ivan Ristic 於 9 月 1 日公布。測試重點不在漏洞利用，而是觀察 PQC 在既有 TLS 1.3 連線流程中的實際成本，特別是握手封包大小與 CPU 時間的變化。來源
從協定設計來看，TLS 1.3 本身已經盡量縮短握手流程，但當導入 PQC 的混合式金鑰建立後，握手期間必須同時攜帶傳統 ECDHE 與 ML-KEM 相關資訊，因此封包內容自然變大。Red Sift 的數據顯示，採用 X25519MLKEM768 時，完整 TLS 握手資料量從 1,258 位元組增至 3,522 位元組。來源
值得注意的是，CPU 成本並未同步明顯上升。依測試結果，用戶端與伺服器端 CPU 時間僅分別增加 0.074 毫秒與 0.042 毫秒，顯示至少在同機、低延遲條件下，PQC 對計算資源的影響相對有限。這代表當前瓶頸未必出現在加解密運算，而更可能出現在資料傳輸與握手流程的協定層。來源
若改採純 ML-KEM-1024 金鑰建立且不搭配 X25519，握手資料量進一步增至 4,323 位元組，較基準增加 243.7%。Red Sift 也指出，伺服器端增加的握手資料可能占用 TCP 初始壅塞視窗的傳輸空間，進而影響實際連線建立效能。對實務部署而言，這個現象比 CPU 耗時更值得關注。來源
此外，若用戶端在初始 ClientHello 中未提供 ML-KEM-1024 的金鑰交換資訊，伺服器就必須回覆重試要求，導致每次完整 TLS 連線多出一次網路往返。在公開網際網路環境中，這種額外 RTT 對使用者體感與服務延遲的影響通常會比單純的毫秒級 CPU 成本更明顯。來源
不過，本次測試是在同一臺電腦上執行用戶端與伺服器，網路延遲極低，因此結果主要可視為不同 PQC 金鑰建立方式的相對比較，不能直接等同於真實網路部署下的絕對表現。換言之，這份數據更像是「方向性指標」，而非最終上線效能保證。來源
這起測試最直接影響的是正在評估或規劃導入 PQC 的 TLS 服務。若服務本身握手頻繁、連線建立密集，封包膨脹就可能放大成可觀的延遲與頻寬成本，尤其是入口網站、API Gateway、邊緣節點與高併發應用。來源
對終端使用者而言，風險未必表現在系統資源耗盡，而是表現在連線建立速度變慢、首包時間拉長，甚至在網路品質較差時出現更明顯的握手延遲。對服務營運方而言，則可能意味著需要重新檢視 TLS 堆疊、負載平衡、憑證與金鑰建立策略。來源
對已經規劃逐步過渡到 PQC 的組織來說，這份實測也釋出一個清楚訊號：PQC 的導入不只是演算法替換，更是對協定大小、網路行為與基礎設施容量的一次重新校準。若只看加密強度而忽略握手體積，可能低估部署後的整體成本。來源
首先，應以混合式部署策略作為過渡起點，優先評估 X25519MLKEM768 這類兼顧相容性與 PQC 的方案，避免直接跳到更高成本的配置而造成不必要的握手膨脹。從 Red Sift 的測試結果看，混合式方案在 CPU 影響與握手體積之間仍保有相對可控的平衡。來源
其次，應在接近真實環境的條件下做壓測，不能只依賴單機或低延遲實驗數據。測試時應特別觀察握手封包大小、初始壅塞視窗、重試次數與 RTT 對用戶體感的影響，才能更準確推估上線後的實際風險。來源
再者，若服務端流量高度依賴短連線或大量新建連線，應優先檢查是否能透過連線重用、前置快取、TLS 終止點調整或邊緣節點部署來吸收握手成本。這類優化不改變密碼學強度，但能減少 PQC 握手變大後對傳輸層的壓力。來源
最後，組織應將 PQC 視為長期演進專案，而非單次升級。除了演算法本身，還要持續追蹤不同金鑰建立方式在封包大小、延遲與相容性上的差異，並把這些結果納入架構審查與變更管理流程。來源