後量子憑證為什麼不直接簽——Merkle Tree Certificate 怎麼把握手壓回比今天還小

讀完這篇之後，你會知道一件聽起來矛盾的事：把整個 Web PKI 換成後量子演算法，握手不一定會變大，常見情況下反而比今天還小。Let's Encrypt 在 2026 年 6 月公布的後量子憑證策略，刻意不走「每張憑證各自用 ML-DSA 簽一次」的路，而是改用 Merkle Tree Certificate（MTC）：一個後量子簽章覆蓋一整批憑證，瀏覽器在握手之外另行同步這個批次簽章，握手裡只剩一個簽章、一把公鑰、一條 inclusion proof。文章會從「後量子簽章為什麼這麼大」開始，一路講到「一次握手裡到底有幾個簽章」「Merkle tree 與 inclusion proof 怎麼壓縮 common case」「landmark 過期時的 standalone fallback」「時程與標準化」，最後落到一個你下週就可能要做的決定：你的伺服器，現在該不該先把 X25519MLKEM768 打開。

先把一個容易混淆的前提標清楚。後量子遷移其實有兩條獨立的戰線——金鑰交換（加密）與憑證簽章（認證）。這篇主角是後者，但原文反覆強調：前者更急。原因下面會講，這裡先記住一句話：認證可以慢慢換，加密不行。

這故事藏著一個違反直覺的轉折。多數人聽到「換成後量子」的第一反應是東西會變大、變慢——後量子簽章確實又大又笨重，這部分直覺沒錯；但 Let's Encrypt 的策略不是把大東西硬塞進握手，而是退一步重新設計憑證的發行與驗證結構，結果反而讓常見情況下的握手變小。理解這個轉折要先串起三件事：後量子簽章為什麼大、一次握手裡有幾個簽章、Merkle tree 怎麼把「很多個簽章」收斂成「一個」。

2,420 bytes 從哪裡來——後量子簽章為什麼天生這麼大

先看數字。今天 Web PKI 用的兩種簽章演算法，尺寸都很小：

• RSA-2048：簽章 256 bytes，公鑰 256 bytes。
• ECDSA-P256：簽章 64 bytes，公鑰 64 bytes。

ECDSA 之所以能把簽章壓到 64 bytes，是因為它的安全性建立在橢圓曲線離散對數問題上——這個問題在古典電腦上很難，但在夠大的量子電腦上，Shor 演算法可以在多項式時間內解掉。RSA 也一樣，它的安全性建立在大整數因式分解上，同樣倒在 Shor 演算法面前。所以「等量子電腦成熟」這件事，對 RSA 與 ECDSA 是一個存亡問題，不是效能問題。

「存亡」與「效能」要分清楚。效能問題是演算法還能用、只是慢了一點。存亡問題是演算法被攻破、簽章一文不值、任何人都能偽造。Shor 對 RSA 與 ECDSA 造成的是後者：一旦有夠大的量子電腦，攻擊者能從公鑰反推私鑰、對任何訊息偽造出通過驗證的簽章——等於能偽造「任何網域的合法憑證」，整個 Web PKI 的信任基礎就垮了。這不是要不要升級的選擇題，是量子電腦成熟前必須換完的時間賽跑。

NIST 在 2024 年標準化的後量子簽章 ML-DSA（FIPS 204，前身是 CRYSTALS-Dilithium），安全性建立在格（lattice）問題上，目前沒有已知的量子演算法能有效攻破。代價是尺寸：以最小的參數集 ML-DSA-44 來說，簽章約 2,420 bytes，公鑰 1,312 bytes。（命名一提：ML-DSA 的前身是 CRYSTALS-Dilithium，金鑰交換那條線的 ML-KEM 前身是 Kyber，文獻裡兩套名字混用、指同一批東西，本文一律用 NIST 新名。）

把這幾個數字並排，落差是數量級的：

• 簽章：64（ECDSA）→ 2,420（ML-DSA-44），約 38 倍。
• 公鑰：64（ECDSA）→ 1,312（ML-DSA-44），約 20 倍。

為什麼格密碼學的簽章天生這麼大？直覺上的原因是：格問題的安全性來自高維度空間裡向量的「不可區分性」，要表達一個高維度格上的點，本來就需要很多係數，每個係數又要留足夠的位元數來抵抗攻擊。這不是工程沒調好，是數學結構的本質——你可以在不同 ML-DSA 參數集之間權衡（44 / 65 / 87），但沒辦法把它壓到 ECDSA 那個量級。後量子簽章「又大又必要」這件事，是這整個 MTC 故事的起點。

展開一下這個「本質」，因為它解釋了為什麼不能靠工程把尺寸救回來。橢圓曲線建立在緻密的代數結構上：P-256 安全強度約 128 位元，表達曲線上一個點只要約 256 位元，資訊密度極高。格密碼學相反——安全性來自「在高維度空間裡把藏在雜訊中的格點找出來」的困難度，要把雜訊與安全邊界都表達清楚，就得用一大堆多項式係數。ML-DSA 簽章本質是一組多項式向量加一個 hint，每個係數都佔位元，加總就是 2,420 bytes。這是抵抗更強攻擊者必須付出的空間，不是實作不精巧。

所以面對「後量子簽章很大」，業界只有三條路：接受大握手讓網路撐住（已證明在真實流量上會壞）；換一種更省空間的後量子簽章（hash-based 的 SLH-DSA 簽章更大、更慢，更不適合即時握手）；或不在「每張憑證」的粒度簽、改在「一整批」的粒度簽——這就是 MTC。Let's Encrypt 選第三條。理解這個選擇，要先看清楚「每張各簽一次」會在握手裡堆出多少東西。

下面這張圖把簽章尺寸、公鑰尺寸，以及更關鍵的「一次完整握手的總認證資料量」並排畫出來。你可以切換「單一簽章」與「整次握手」兩種視角——關鍵在於，握手裡不只一個簽章。

切換視角看單一簽章與整次握手的位元組落差 · 2 視角 × 4 方案

單一簽章 + 公鑰 整次握手（5 簽章 + 2 公鑰）

切到「整次握手」那個視角，落差才真正暴露出來。問題從來不是「一個簽章 2,420 bytes」，是「一次握手裡有好幾個」。在單一簽章視角下，ML-DSA 看起來只是「比較肥的 ECDSA」，38 倍聽起來嚇人但似乎還能忍。一旦把視角切到整次握手，那根衝破 10 KB 的長條就把「能忍」這個錯覺打破了——它不在同一條尺度上。下一節把這幾個簽章逐一攤開，你會看到 10 KB 不是誇飾，是把每個必要的認證物件都換成後量子尺寸後的算術後果。

一次握手裡的五個簽章兩把公鑰——認證資料量是怎麼堆起來的

多數人對 TLS 握手的印象是「伺服器出示一張憑證、瀏覽器驗證一下」。實際上一次標準的 Web PKI 握手裡，認證相關的密碼學物件遠不止一個。原文直接點明：一次典型握手包含「五個簽章與兩把公鑰」。把它們逐一拆開，你會看到這個數字怎麼來的。

之所以是「好幾個」而非「一個」，根源在於 Web PKI 是分層的信任體系。瀏覽器不直接信任你的網域憑證——它信任的是預先內建的 root CA，而你的 leaf 與 root 之間通常隔著一到兩層 intermediate。鏈上每一段都需要一個簽章；再加上 TLS 1.3 要伺服器即時證明持有私鑰、Certificate Transparency 要憑證公開可稽核——這些需求各自又貢獻了簽章。「五個簽章兩把公鑰」不是浪費，每一個都對應一條真實的信任需求。

下面這個 widget 把這五簽章兩公鑰逐項列出來——每一項說明它是誰簽的、綁定什麼、為什麼非有不可。重點是：這些東西今天用 ECDSA 各自只有幾十 bytes，加起來沒人在意；一旦每一項都換成 2,420-byte 的 ML-DSA 簽章與 1,312-byte 的公鑰，總量就是前一張圖裡那根衝破 10 KB 的長條。

一次 Web PKI 握手裡的認證物件——五個簽章 + 兩把公鑰

• ① leaf 憑證簽章sig 1

  intermediate CA 對你的網域 leaf 憑證的簽章，綁定網域名稱與公鑰。

• ② intermediate 簽章sig 2

  root（或上層 CA）對 intermediate 憑證的簽章，把信任鏈往上接。

• ③ CertificateVerifysig 3

  伺服器當場用 leaf 私鑰簽握手 transcript，證明它真的持有私鑰。

• ④ 兩條 SCT 簽章sig 4 + 5

  Certificate Transparency log 對「此憑證已登錄」的兩個簽章承諾。

• ⑤ 兩把公鑰key 1 + 2

  驗證上面那串簽章所需的 leaf 與 intermediate 公鑰，本身也要傳輸。

點任一層看它在握手裡扮演什麼角色。

① leaf 憑證簽章

這是最直覺的那一個：CA 對「這個網域的公鑰是這個」做出的背書。換成 ML-DSA，光這一張就從 64 bytes 變成 2,420 bytes。

② intermediate 簽章

信任不是直接從 root 到你的網域，中間隔著 intermediate CA。這一段鏈接也是一個簽章——也要一起被換掉、一起變大。

③ CertificateVerify

持有憑證不等於持有私鑰。TLS 1.3 要求伺服器當場用私鑰簽一次握手 transcript，證明私鑰真在它手上。這是握手中唯一一個「即時產生」的簽章。

④ 兩條 SCT 簽章

Certificate Transparency 要求憑證必須登錄在公開 log 裡，瀏覽器才接受。每個 SCT 是 log 對「我收錄了這張憑證」的簽章承諾，通常要兩條來自不同 log。MTC 的妙處之一，就是讓這兩條變得多餘——後面會講。

⑤ 兩把公鑰

簽章要能被驗證，對應的公鑰就得在握手裡傳過來——leaf 一把、intermediate 一把。ML-DSA 的公鑰 1,312 bytes，兩把又是一筆。

把五個簽章兩把公鑰全換成 ML-DSA，原文的結論是一句很實際的話：在這個尺寸下，「真實網路上有相當比例的 TLS 連線會失敗，其餘的則變慢」。這不是模型推算，是真實流量上的觀測——握手變肥到一定程度，封包要切片、要多個 round trip，某些中間設備或舊路徑就會直接斷掉。逐張簽不是「比較慢的方案」，是「在真實網路上會壞掉的方案」。

「為什麼會壞」是整個策略的物理底層。握手早期雙方都還沒完成認證，能塞進前幾個封包的資料有限；憑證鏈膨脹到十幾 KB 就要切更多片、跨更多 round trip。更糟的是網路上散布著大量對封包大小敏感的中間設備——老防火牆、深度封包檢測、對 TLS record 大小有隱性假設的 middlebox——它們面對遠超「見過尺寸」的握手，行為未定義：有的截斷、有的丟棄、有的直接重置。這就是「相當比例連線會失敗」的來源：不是端點的問題，是路徑上的設備受不了。而中間設備分散全球、無人能協調升級，所以唯一可靠的策略是不要把握手變大。MTC 正是衝著這個約束設計的。

Merkle tree 與 inclusion proof——一個簽章怎麼覆蓋一整批憑證

到這裡問題定義清楚了：後量子簽章很大、握手裡又有好幾個、全換會壞。MTC 的核心想法一句講完——別讓每張憑證各帶一個簽章，讓一整批共用一個。原文的描述是：「MTC certificate authority 不是一次發一張、各自簽一次，而是成批發行憑證，用一個簽章覆蓋整批。」這個「一個簽章覆蓋一整批」靠的就是 Merkle tree。

Merkle tree 的結構很簡單：把這一批要發的憑證放在樹的葉子，每個葉子取 hash，相鄰兩個 hash 再拼起來取 hash 往上一層，一路收斂到唯一的 root hash。任何一個葉子改一個位元，root hash 就會變——這是 hash 函數的性質。所以 root hash 就是「這整批憑證」的一個密碼學指紋。CA 只要對這一個 root hash 簽一次（用 ML-DSA），就等於對整批憑證背書。原文把這個批次簽章叫做 landmark。

這裡的省力是攤提（amortization）：一個 2,420-byte 的 ML-DSA 簽章本來要為一張憑證付出，現在被一整批共同分攤。一個 batch 一萬張憑證，2,420 bytes 攤到每張只剩約 0.24 bytes——簽章成本幾乎消失。後量子簽章「很大」這個問題沒被解決，是被攤平到忽略不計。它不跟數學硬碰硬把簽章變小，而是改變「一個簽章服務多少張憑證」的比例。原文也點明 Let's Encrypt 自 2019 就在營運用 append-only Merkle tree 的 CT log——MTC 對它不是全新技術，是把跑了多年的資料結構從「事後稽核」推到「發行核心」。

那瀏覽器怎麼只憑一個簽章就驗證單一憑證？這就是 inclusion proof 的工作。瀏覽器手上已經有 landmark（批次簽章 + root hash，透過獨立管道事先同步）。握手時伺服器只需要證明「我這張憑證確實在那棵樹裡」，而證明這件事不需要整棵樹，只需要從這個葉子到 root 路徑上的那些 sibling hash——數量是 log₂(n) 級。瀏覽器拿這張憑證的 hash、配上這串 sibling hash，自己往上重算一遍，如果算出來的 root 等於 landmark 裡那個 root，證明成立。

關鍵在於 inclusion proof 用的是 hash，不是後量子簽章。Hash 函數（SHA-256）對量子電腦相對抗打——Grover 演算法只把暴力破解的成本開根號，加倍輸出長度就能補回來，不像 Shor 對 RSA/ECDSA 那樣是致命的。所以這條 proof 既後量子安全、又便宜。一批一萬張憑證，proof 路徑大約 log₂(10000) ≈ 14 個 hash，每個 32 bytes，總共約 450 bytes——配上一個 ML-DSA 簽章與一把公鑰，就是原文說的 common case。

這條 log(n) 性質是 MTC 可規模化的根本。Merkle tree 深度是葉子數的對數，proof 長度也是對數級。batch 從一萬張放大到一百萬張，proof 只從約 14 個 hash 增到約 20 個——多六個 hash、約 192 bytes。batch 開再大，每張憑證的握手成本幾乎不變。這讓 CA 可以激進地把 batch 開大、把那個 ML-DSA 簽章攤到極致，而代價只以對數緩慢增長。一個簽章、一把公鑰、一條對數長度的 proof——這就是 common case 能比今天 ECDSA 鏈還小的原因。下面這個 widget 讓你直接拖 batch 大小，看簽章攤分成本與 proof 長度怎麼反向權衡。

拖 batch 大小，看簽章攤分成本與 proof 長度的反向權衡 · 1 → 1,048,576 張

batch = 16,384

拖動上方滑桿觀察兩條曲線的交叉。

下面這張圖是一棵八葉子的 Merkle tree。點任一張 leaf 憑證，它到 root 的 authentication path 會亮起來，需要的 sibling hash（也就是 inclusion proof 的內容）會被框出來。你會直接看到：要驗證一張憑證，亮起來的節點數量是 log 級，不是整棵樹。

點任一張 leaf 憑證看它的 inclusion proof 路徑 · 8 leaves

點任一張 leaf 憑證——它的 inclusion proof 就是路徑上那些 sibling hash。

把這個結構接回前面的五簽章兩公鑰，逐項對照 MTC 怎麼把它們消掉：

• ① leaf + ② intermediate 簽章：兩個都不見了。整批憑證共用 landmark 那一個 ML-DSA 簽章，不再每張各簽、每層各簽。
• ④ 兩條 SCT 簽章：也不見了。原文一句點破——「一張憑證不可能存在於 Merkle tree 之外。Certificate Transparency 變成內建性質。」既然憑證的存在就等於它在公開的樹裡，就不必再額外附 transparency 證明。
• ③ CertificateVerify 仍然需要——伺服器還是得當場證明持有私鑰，但這部分另有後量子方案處理。

結果就是 common case 的「一個簽章、一把公鑰、一條 inclusion proof」。原文的總結很乾脆：在常見情況下，MTC 握手反而比今天的 Web PKI 還小——即使用的是後量子演算法。後量子卻更小，靠的不是更小的簽章，是更少的簽章。把四種方案的握手認證資料量並排，這個結論一眼可見：

方案	簽章數	公鑰數	認證資料量	真實網路
今天 · ECDSA-P256	5	2	~448 B	可用
逐張 · ML-DSA-44	5	2	~14.4 KB	部分連線失敗
MTC · common case	1	1	< 今天	可用且更小
MTC · standalone	1+	1	稍大	可用（fallback）

「Certificate Transparency 變成內建性質」是個優雅的副作用。今天的 CT 是事後補強：CA 簽完憑證再送進公開 log、拿回 SCT，瀏覽器握手時檢查 SCT——這是外掛上去的監督機制，所以要額外的簽章與成本。MTC 把它變成結構性的：憑證的存在方式就是「Merkle tree 裡的一個葉子」，而這棵樹本身就是公開的 append-only log。原文一句講透——「一張憑證不可能存在於 Merkle tree 之外。」存在即公開，就不必再額外證明「我有被公開」。透明性從附加檢查，變成憑證本體的一部分。

landmark 過期時的 standalone fallback——這套設計怎麼不卡死老 client

上面整個 common case 有一個前提：瀏覽器手上要有最新的 landmark。landmark 是批次簽章，瀏覽器透過獨立於握手的管道（類似今天同步 CRL / CT log 的機制）持續更新。但如果一個 client 很久沒上線、它的 landmark 過期了呢？

這就是 standalone form 存在的理由。原文說：「另一種情況是 standalone 形式。當 client 的 landmark 過期時，它用稍大的握手作為 fallback。」也就是說，當瀏覽器沒有對應這張憑證所在批次的 landmark，伺服器就退回一種把驗證所需資訊全部塞進握手的形式——握手會變大，但連線不會斷。

這個 fallback 是整套設計能上線的關鍵。MTC 不要求「全世界瀏覽器都先同步好 landmark」才能運作——它在 common case 享受小握手，在 landmark 缺席時優雅退化成一個能用、只是稍大的握手。沒有這條 fallback，任何 client 的同步落後都會變成連線失敗，這套東西就沒人敢部署。

為什麼 landmark 要「另行同步」而不是放在握手裡？因為它是整批共用的——放進每次握手，「攤分」的效果就沒了，每次連線又要重傳那 2,420-byte 簽章。把它移到握手之外、讓瀏覽器像同步 CT log 或撤銷清單那樣定期批次更新，握手裡才能只剩 proof。這跟瀏覽器今天已在做的事（背景更新 root store、CRLSet、CT log 狀態）是同一類機制——MTC 只是多加一個「定期拉最新 landmark」的通道。standalone fallback 則呼應務實現實：總有 client 處於不理想狀態（剛開機、長期離線、企業內網更新被卡）。把「landmark 缺席」當成一等公民而非錯誤，是想在開放網路上規模部署的協定該有的形狀。

用一段對照把兩種路徑寫清楚：

// 瀏覽器收到伺服器的 MTC 憑證後
if (browser.hasLandmark(cert.batchId)) {
  // common case：握手只帶 1 簽章 + 1 公鑰 + 1 inclusion proof
  recomputedRoot = foldHashes(cert.hash, cert.inclusionProof)
  accept = (recomputedRoot == landmark.root)   // 比 ECDSA 今天還小
} else {
  // standalone fallback：landmark 過期 / 缺席
  // 伺服器改送把驗證資訊塞滿的較大握手——慢一點，但不斷線
  accept = verifyStandalone(cert)
}

值得停下來體會的是這條設計線：MTC 不是用「假設理想條件」換來小握手，而是把理想條件當成 common case 優化、把非理想條件當成正確性 fallback。這正是能在真實異質網路上部署的協定該有的形狀。

這也影響 ACME 發行流程。今天你用 certbot 申請憑證，CA 立刻簽一張回給你；MTC 模型下，CA 把你的憑證放進下一個 batch、等封樹、對 root 簽 landmark，再把「憑證 + inclusion proof + landmark 引用」一起交給你。發行從「一次性簽發」變成「進入批次、取得 proof」——這就是 PLANTS 與 ACME 兩個 working group 要協調的：PLANTS 定義 MTC 格式與驗證規則，ACME 定義 client 怎麼自動取得 MTC 憑證與 proof。理想狀態是這層複雜度被 ACME client 完全吸收，你還是跑 certbot，只是底下換了一套發行語意。

時程與你下週的決定——staging 2026、prod 2027，以及更急的那件事

MTC 還在路上。原文給的時程很明確：「我們的目標是 2026 年底有一個發行 MTC 的 staging 環境，2027 年有一個 production-ready 環境。」標準面，IETF 的 PLANTS working group 正在標準化 MTC 設計，Let's Encrypt 同時參與 PLANTS 與 ACME working group；ML-DSA 進 X.509 已有 RFC 9881，進 TLS 是 draft-ietf-tls-mldsa。Chrome 那邊已經把話講白：MTC 是它「把後量子憑證加進公開 web 的首選路徑」。Cloudflare 與 Chrome 正在用真實流量對 MTC 做可行性實驗。

把這些日期、再加上推著整件事走的法規 deadline，攤在一條時間軸上會更清楚壓力落在哪。拖動下面的把手，看每個時間點對應什麼承諾或 deadline：

拖動把手看後量子遷移時程 · 2026 → 2035

拖動把手——時間軸上每個點對應一個產業承諾或法規 deadline。

但這篇最該帶走、跟你下週工作最相關的一句，不是憑證的時程，而是原文反覆強調的優先順序。原文說得很直接：「後量子加密是更急迫的問題，因為任何沒有後量子金鑰交換的 TLS 連線，都可能被攔下來、留著等以後解密。」

這就是 harvest-now-decrypt-later 攻擊：對手今天把你的加密流量錄下來存著，等量子電腦成熟再回頭解。對「認證」來說這個威脅不存在——你沒辦法事後偽造一個 2026 年的簽章，因為簽章是即時驗證的，量子電腦未來再強也回不到過去幫你騙過當時的瀏覽器。但對「加密」來說它是現在進行式，今天錄、未來解，你的資料機密性是被當下的金鑰交換演算法保護的。所以兩條戰線的急迫性天差地別：憑證可以等 MTC 在 2027 慢慢上，但金鑰交換不能等。

這個非對稱性是這篇最重要的工程結論。認證（簽章）的價值在「連線當下」就被消費掉——瀏覽器當場驗證、當場決定信不信任，之後簽章就沒用了。就算未來量子電腦能偽造簽章，也偽造不了「過去某次握手」。這給憑證遷移一個從容的時間窗：等標準成熟、等 MTC 上線、慢慢換。加密則相反——它保護資料的長期機密性。一段今天用純 X25519 加密的流量被錄下來，安全性取決於「未來十年內沒人造出能破 X25519 的量子電腦」。對任何需保密超過幾年的資料，這賭注太危險。所以加密必須現在就升級，因為威脅在資料被錄下的那一刻就成立了。

原文的具體 action 只有一句但很硬：「如果你經營伺服器，請確保它們支援 hybrid 後量子金鑰交換（X25519MLKEM768）。」hybrid 是把古典 X25519 與後量子 ML-KEM-768 並排、結果混合成 session key，任一個沒被攻破連線就安全。為什麼不直接純 ML-KEM？因為後量子演算法相對年輕，萬一被發現有古典弱點，純後量子反而更脆弱；hybrid 確保「至少不比現在差」。這件事不用等任何標準定案，OpenSSL、BoringSSL 與各大 CDN、瀏覽器都已支援，X25519MLKEM768 在 Chrome 與 Firefox 都已預設啟用。你今天就能開，而且應該今天就開。

Take-away：後量子簽章很大不可改，但 MTC 用「一個簽章覆蓋一整批、inclusion proof 用 log(n) 個 hash 補完」把握手壓回比今天還小——而在你等 MTC 落地的同時，請先把 X25519MLKEM768 打開，因為加密被 harvest-now-decrypt-later 威脅的是現在，認證不是。