為什麼是混合式後量子，而非純 ML-KEM

熊偉翔 · 2026 年 6 月

第一次開啟後量子金鑰交換時，這是個合理的疑問：如果 ML-KEM 才是具量子抵抗力的演算法，為什麼大家部署的是 X25519MLKEM768—還拖著那個老舊、會被量子破解的 X25519—而不是純 ML-KEM？答案是一個精確的風險權衡，而你可以從兩個密鑰如何在封包上結合，清楚看出每一半各買到了什麼。

混合式在封包上是什麼

X25519MLKEM768 在同一次交握裡跑兩種金鑰交換。客戶端送出單一個 key_share，是兩把公鑰串接而成；伺服器回以兩把；雙方各自算出兩個共享密鑰，再串接成一個。

# X25519MLKEM768 客戶端 key_share（代碼點 0x11ec）— 兩把金鑰，串接
  ML-KEM-768 封裝金鑰   1184 bytes
  X25519 公鑰              32 bytes
                        ----------
  合計                  1216 bytes   # 這就是 ClientHello 的那 ~1.2 KB

# 餵進 TLS 1.3 金鑰排程的密鑰 = 兩者，串接：
  shared_secret = ML-KEM-768 密鑰 (32)  ||  X25519 密鑰 (32)

（一個值得知道的位元組層級小細節：對 X25519 變體而言，ML-KEM 部分在 share 與密鑰中都排在前面；而 NIST P 曲線變體則把 ECDHE 部分排在前面。順序弄錯，金鑰排程就會悄悄地對不上。）串接後的密鑰直接作為 (EC)DHE 輸入餵進 HKDF—見完整的逐位元組解析。

為什麼要結合，而不是二選一

那種「先串接、後 KDF」的構造，只要 KDF 是強健的 PRF，且兩個輸入密鑰中至少有一個未被攻破，就是安全的。要還原工作階段金鑰，攻擊者必須兩者都攻破—X25519 與 ML-KEM。這買到了兩個獨立的失效領域：

• 如果 ML-KEM 有尚未被發現的弱點—數學上的（格密碼分析遠比 ECC 所歷經的數十年攻擊年輕），或更可能在近期出現的、全新程式碼中的實作錯誤—X25519 仍能保護你不受今日的傳統攻擊者侵害。

• 如果一台具密碼學意義的量子電腦問世並破解了 X25519，ML-KEM 仍能保護你。

唯有兩者同時垮掉，你才會輸。

把每一半究竟買到什麼講精確

這裡是容易講錯的部分：X25519 提供的後量子保護是零。面對「先擷取、後解密」，一個今天錄下交握、又擁有未來量子電腦的攻擊者，會用 Shor 演算法破解 X25519 那一半。所以這條連線的量子抵抗力，完全仰賴 ML-KEM。

X25519 的工作是另一種保險：採用一個年輕的演算法，不會讓你比今天更糟。萬一 ML-KEM 在量子威脅成真之前被發現有瑕疵，你並沒有退步—你仍握有 X25519 的傳統安全。所以混合式不是「把量子安全加倍」。它是「由 ML-KEM 提供完整的量子抵抗力，再加上一道保證：提早押注沒有降低你的傳統安全」。這個不對稱，正是全部的重點。

那為什麼還不用純 ML-KEM

主要是成熟度。ML-KEM 於 2024 年標準化（FIPS 203）；上線的實作都還很新。在第一波部署期間，保守的做法是不要把一條連線的整體機密性，押在尚未經歷 ECC 那般數十年檢視的數學與程式碼上。而這道避險的代價很小：在約 1.2 KB 的 ML-KEM share 之上，多加一次 32 bytes 的 X25519 交換—相對於你已經為 KEM 付出的，這份保險幾乎是免費的。

這就是為什麼已部署的代碼點—在當前的瀏覽器、主要 CDN，以及 OpenSSL 3.5+—用的是混合式，而非純式。純 ML-KEM 確實存在，等演算法夠成熟後也很可能成為預設。今天的例外，是嚴格的 CNSA 2.0／純 PQC 態勢明文要求它—那是一項特定的合規要求，而不是比混合式更安全的改進。

選對群組、並證明每一條連線真的協商出了它，正是那種決定一次遷移是真實、還是只是設定好的封包層細節。它是更廣遷移路徑中的一步，也是我們著力之處。

← 所有文章