別再等更好的後量子簽章：ML-DSA 現在就得上

看完這篇，你會知道 ML-DSA 這個「又大又慢」的簽章為什麼非上不可、體積代價實際落在哪裡、NIST 手上還有哪些候選方案在排隊、以及排隊要排多久——多久到「等」本身變成一個比「先上」更危險的選項。

RSA 為什麼撐不住——後量子簽章要接的位置

RSA 和 ECC 是幾乎每一條 TLS 連線、每一次程式碼簽章都在用的演算法，用了幾十年。Cloudflare 這篇文章的開場論點很直白：RSA 與 ECC 這兩個大家依賴了幾十年的密碼演算法，會被「夠強大的量子電腦」攻破。這不是「效能會變差」的漸進式威脅，是這兩類演算法背後的數學問題（大數分解、離散對數）一次性失效的問題。

NIST 對此的回應是一場公開競賽，篩出一批「後量子」演算法——安全性建立在量子電腦目前也解不動的數學問題上。它們在 2024 年由美國國家標準與技術研究院正式標準化。ML-DSA 是格密碼（lattice-based）家族的成員，跟無狀態雜湊式簽章 SLH-DSA 一起，是第一批拍板、也是接下來要接手 RSA/ECC 位置的候選人。這兩個標準不是憑空冒出來的終點，是一整條篩選管線走到今天的暫時結果——管線的另一端，還有九個候選在排隊等著接下一棒。

問題是，這個「接手」不是無痛換裝。這篇文章談的是簽章，不是加密。後量子遷移還有另一半戰場是金鑰交換（ML-KEM），道理類似但問題不同，不在這篇的討論範圍裡。

這也是為什麼這個題目值得現在讀，不是等到量子電腦真的出現才讀。密碼演算法的汰換從來不是「哪天量子電腦上線，哪天就切換」——憑證的有效期、韌體的更新週期、硬體裝置的服役年限，全部比量子電腦研究進度慢得多。等到威脅具體化才開始換，換的東西早就已經簽好、發出去、埋在客戶手上的裝置裡了。

ML-DSA 為什麼又大又慢——體積代價從哪裡來

Cloudflare 貼出的比較表把這個代價量化了。以安全強度最低的一檔（ML-DSA-44）為基準：公鑰 1,312 bytes、簽章 2,420 bytes。同樣拿來對照的 Ed25519，公鑰只要 32 bytes、簽章只要 64 bytes——公鑰差了四十倍出頭，簽章也差了將近四十倍。RSA 2048 的簽章一樣只有 256 bytes、公鑰 272 bytes，同樣遠小於 ML-DSA。

這個差距在單一連線裡看起來還能忍。真正吃緊的是「重複出現」的場景，最典型的就是憑證鏈。一條 TLS 憑證鏈通常不只一張憑證：葉憑證、中繼憑證、根憑證，每一張都帶著自己的公鑰，也都被上一層簽過一次。抓一個三張憑證的鏈做個簡單乘法——這不是文章裡直接寫的數字，是拿上面已核實的單張公鑰＋簽章大小推出來的還原算——全用 Ed25519，三張憑證加起來大概 288 bytes；全換成 ML-DSA-44，三張憑證加起來超過一萬一千 bytes，膨脹了將近四十倍。下面這個 widget 把這個對比拉開看，拖動中間的分隔線就能看見兩邊的差距。

拖動分隔線比較兩種憑證鏈 · 3 張憑證

這種膨脹不只是「多花一點頻寬」的美學問題。握手往返的封包數、CDN 邊緣的簽章驗證吞吐量、嵌入式裝置的記憶體預算，全部要重新抓一次容量。這是為什麼很多 RSA/ECC 玩得動的把戲，ML-DSA 玩不動——不是工程沒做好，是格密碼這個數學基礎本身就長這個尺寸。

換句話說，體積代價不是一次性成本，是每一次連線都要重付的稅。憑證鏈只是其中一個容易算的例子，任何「重複簽、重複驗」的場景，都要用同一套邏輯重新估一次容量。這也是為什麼 Cloudflare 這種本身就在處理巨量連線的公司，會把「先上」當成當務之急，而不是等公司內部評估報告寫完。

為什麼不能等——on-ramp 時程與雙軌陷阱

如果 ML-DSA 這麼笨重，直覺的反應是「等一下，等更小更快的方案出來」。NIST 確實還在找——上個月，NIST 宣布九個後量子簽章方案進入「signatures on-ramp」的第三輪篩選，橫跨格密碼、對稱／雜湊式、同源密碼、零知識證明系統、多變數密碼五個數學家族。下面這個時間軸把標準化以來到 2035 年之間，各個節點分別發生什麼事排出來，拖動右邊的把手看每個時間點的狀態。

拖動把手看每個年份的狀態 · 7 個時間點 · 2024 到 2035

拖到 2024 看起點：ML-DSA 與 SLH-DSA 標準化。

而 Cloudflare 自己的目標是 2029 年前完成全面後量子化——比上面任何一個候選的「廣泛可用」時間點都早。等，等不到。

更麻煩的是「等」本身不是中立選項。文章原文講得很直接：「In a system of any reasonable size, you can't upgrade everything all at once. You'll need a transition period where both post-quantum and traditional signatures are supported.」任何有規模的系統都沒辦法一次性把所有節點升級完，中間一定要有一段過渡期同時支援古典與後量子兩種簽章。而只要兩種都支援，就打開了 downgrade attack 的空間——攻擊者只要想辦法讓連線協商回退到比較弱的那一邊。唯一乾淨的解法是直接關掉古典演算法，但這件事需要時間，而且在 WebPKI 這種分散、沒有單一中控的系統裡，短期內根本不是一個選項。下面這個 widget 把「遷移進度」當成一個連續變數，拖動看看 downgrade attack 的風險視窗在哪一段打開、又在哪一段關閉。

拖動圓點看遷移進度如何影響風險視窗 · 0% 到 100%

雙軌並存期：古典與後量子簽章都被接受，攻擊者可以想辦法讓協商回退到比較弱的古典演算法——這就是 downgrade attack 的空間。

「第三輪」這個字眼本身就是個提醒：NIST 的 on-ramp 流程還沒走完，九個候選進了第三輪，不代表九個最後都會活著走到標準化那一天——密碼分析、結構性攻擊、效能不如預期，任何一個環節都可能讓候選被要求重新設計，甚至整個撤回。這正是為什麼工程團隊不該現在就把系統的長期規劃押在任何一個第三輪候選身上，押注的對象應該是「ML-DSA 現在就能用」這件事本身。

這正是 Cloudflare 引用 Eric Rescorla 那句話的位置：「You go to war with the algorithms you have, not the ones you wish you had.」手上有的演算法就是 ML-DSA，不是等到 2030 年代才會出現的那個更好的候選。把這句話放回工程情境裡讀，意思很具體：規劃 2026、2027 年要上線的系統，選型清單上能填的欄位只有 ML-DSA——不是因為它最好，是因為它是唯一一個通過完整標準化、能寫進生產環境檢查清單的選項。等其他候選也走到這一步，你的系統早就已經上線很久了。

九個候選，各自的取捨——沒有一個同時做到小、快、穩

要先分清楚兩件事：ML-DSA、SLH-DSA 是已經拍板的標準，任何人現在都能直接用；FN-DSA（Falcon）正在走完標準化程序的最後一段路；剩下的九個 on-ramp 候選還在第三輪篩選裡，離「能拿來用」還有一段距離。這九個候選橫跨格密碼、同源密碼、多變數密碼、對稱／雜湊式、零知識證明系統五個數學家族——本文詳細討論的六個候選（SQIsign、HAWK、FN-DSA、MAYO、SNOVA、UOV）分散在其中三個家族裡，同一個家族內部的候選，取捨方向也常常不一樣。

那九個候選到底差在哪？下面這張圖把簽章大小（橫軸，對數尺度）跟驗證速度（縱軸，以 ML-DSA-44 的速度當作基準 1，數字越大代表驗證越慢）放在一起看，加上兩個已經在用的對照組（Ed25519、RSA 2048）跟 ML-DSA 自己。

點欄位標題排序 · 6 欄 × 11 列

演算法	分類	公鑰 bytes	簽章 bytes	簽署速度×	驗證速度×
Ed25519	古典演算法	32	64	0.15	1.3
RSA-2048	古典演算法	272	256	80	0.4
ML-DSA-44	已標準化	1,312	2,420	1	1
SLH-DSA-128s	已標準化	32	7,856	14,000	40
SLH-DSA-128f	已標準化	32	17,088	720	110
FN-DSA-512	即將標準化	897	666	3	0.7
HAWK-512	on-ramp 候選	1,024	555	0.25	1.2
SQIsign-I	on-ramp 候選	65	148	300	50
MAYO-one	on-ramp 候選	1,420	454	2.1	0.4
SNOVA (24,5,4)	on-ramp 候選	1,016	248	1.2	1.7
UOV Is-pkc	on-ramp 候選	66,576	96	0.3	2.4

從圖上可以看到一個規律：目前沒有任何候選同時落在「簽章小」又「驗證快」的角落。每個候選都是拿一邊的優勢，換另一邊的代價。把這張圖跟上面的表對照著看，左下角（簽章小、驗證快）那個位置目前是空的——這不是巧合，是每個候選面對的共同物理限制：數學結構決定了它要拿什麼換什麼，不是工程優化能繞過的細節。

SQIsign 建立在同源密碼上，簽章只要 148 bytes，是全表最小的方案之一。代價是簽署慢了 300 倍，驗證也慢了 50 倍，而且文章特別指出，要把簽署過程做成能抵抗 timing side-channel 的版本很難，做到了還要再吃一次效能懲罰。UOV 走的是多變數密碼，簽章壓到 96 bytes，逼近 Ed25519 的水準，但公鑰暴增到 66,576 bytes——對需要在連線當下把公鑰整包傳過網路的 TLS 伺服器憑證來說，這個公鑰大小完全沒有幫助。

FN-DSA（也就是 Falcon 的標準化版本）簽章相對小，666 bytes，但它天生最適合用硬體加速的浮點運算來實作，這是密碼標準史上第一次要靠浮點數，也讓側通道防護變得棘手。HAWK 走的是另一條格密碼路線，引入一個全新的困難假設「lattice isomorphism problem」；2024 年，也就是 HAWK 發表兩年後，有人證明這個問題在「totally real number fields」這個特例下容易求解——雖然這個特例不是 HAWK 實際使用的參數，沒有直接打中它，但也說明這個假設還年輕，安全邊界還在被摸索。

多變數密碼裡另外兩個候選反而看起來比較穩：MAYO 的簽章 454 bytes，文章說目前為止沒有找到針對它「whipping」結構本身的攻擊；SNOVA 簽章壓到 248 bytes，是整張表裡最省的候選之一，代價是每次結構被攻破，開發團隊就換一次底層結構重新推出效能更好的新版——省是省，但底子一直在動。已經標準化的 SLH-DSA 走的是保守路線。文章解釋早期的有狀態雜湊式簽章方案是怎麼運作的：用一次性簽章金鑰組成 Merkle tree，簽署方必須自己追蹤哪些金鑰已經用過，一旦追蹤出錯、金鑰重複使用，安全性就整個垮掉。SLH-DSA 的賣點正是「無狀態」——不用背這個追蹤負擔，換來的安全假設也非常紮實，只依賴雜湊函式的抗碰撞性，沒有格密碼或多變數密碼那種相對年輕的數學假設。代價是簽章落在 7,856 到 17,088 bytes 之間，驗證慢了 40 到 110 倍——這是目前表格裡體積跟速度都最極端的一端，保守換來的就是這麼大的代價。

六個候選，各自的取捨關鍵字

• SQIsign · 同源密碼簽章 148B

  簽章全表最小之一，但簽署慢 300 倍、驗證慢 50 倍，還難防 timing side-channel。

• HAWK · 格密碼簽章 555B

  建立在全新的 lattice isomorphism problem 上，2024 年被發現特例可解——雖不影響 HAWK 實際參數，假設仍年輕。

• FN-DSA（Falcon）· 格密碼簽章 666B

  相對小的簽章，但天生要靠硬體加速浮點運算實作——密碼標準史上第一次，側通道防護因此更難。

• MAYO · 多變數密碼簽章 454B

  目前為止沒有找到針對其「whipping」結構本身的攻擊，是九個候選裡看起來比較穩的一個。

• SNOVA · 多變數密碼簽章 248B

  簽章體積全表最省之一，但每次結構被攻破就換底層結構重新推出——省，代價是底子一直在動。

• UOV · 多變數密碼公鑰 66,576B

  簽章只要 96 bytes 逼近 Ed25519，但公鑰暴增到 66kB——對要傳公鑰過網路的 TLS 伺服器憑證沒有幫助。

SQIsign 用同源（isogeny）數學結構把簽章壓到 148 bytes，是九個候選裡簽章最小的之一。但這個結構的簽署運算本身很重，慢了 ML-DSA-44 三百倍；驗證也慢五十倍。文章特別點名：要把簽署過程做成能抵抗 timing side-channel 的安全實作很難，做到了還要再犧牲一次效能。

HAWK 建立在一個全新的困難假設「lattice isomorphism problem」（LIP）上。2024 年，也就是 HAWK 發表兩年後，有研究證明 LIP 在「totally real number fields」這個特例下容易求解——這個特例不是 HAWK 實際使用的參數，所以沒有直接打中它，但也提醒讀者：這個假設還年輕，安全邊界還在被摸索中。

FN-DSA 是 Falcon 準備標準化的版本，簽章 666 bytes，相對小。代價是它天生最適合用硬體加速的浮點運算實作——文章說這是密碼標準史上頭一次要靠浮點數，讓側通道防護變得棘手。

MAYO 走多變數密碼路線，簽章 454 bytes。文章的說法是「目前為止沒有找到針對其 whipping 結構本身的攻擊」——用了「so far」這個保留字眼，代表這個紀錄還在累積中，不是永久保證。

SNOVA 也是多變數密碼，簽章壓到 248 bytes，是體積最省的候選之一。代價是穩定性：每次底層結構被攻破，開發團隊就順勢換一次結構、推出效能更好的新版——省，是拿結構的不斷變動換來的。

UOV 的簽章只要 96 bytes，逼近 Ed25519 的水準。但公鑰暴增到 66,576 bytes，文章直接點出：這種公鑰大小對需要在連線當下把公鑰整包傳過網路的 TLS 伺服器憑證沒有幫助。

這代表你現在要做的選擇——先上、限縮、或者等

Cloudflare 的結論沒有留退路：不是每個系統都撐得住 ML-DSA 的體積代價，也不是每個系統都能等到上面那些候選成熟。文章原文把選擇攤開成兩條路：「Some will have to accept a performance cost. Others will need to deal with the security gap in other ways, such as restricting access, tunneling, more monitoring, or a myriad of other measures that are costly on their own.」翻成白話——有人得先接受 ML-DSA 的效能代價，把它部署上去；有人的系統暫時撐不住這個尺寸，就得靠限制存取、把流量包進額外的 tunnel、加強監控這些手段撐過這段安全落差，而且這些補救手段本身也不是免費的，都要付出額外的維運成本。

實務上，這個選擇通常不是全有全無。同一個組織裡，對外的 TLS 憑證鏈可能因為要顧相容性，只能先吃 ML-DSA 的體積代價；內部服務之間的連線，如果流量本來就走在私有網路裡，用限制存取搭配監控撐著、晚一點再換，反而是更划算的順序。判斷的關鍵不是「要不要上後量子」，是「哪些連線先上、哪些連線可以晚一點」。

這兩條路都不浪漫，但都比「什麼都不做」誠實。「什麼都不做」等於選擇繼續依賴一把已知會被打穿的鎖，賭量子電腦不會在你的系統退役之前出現。文章的結尾把這句話說得很白：即使地平線上有更好的簽章、更進階的密碼學，眼前的任務也不該被忘記——先在近期內守住安全。回頭看整條論證，體積代價、時程表、downgrade attack 的風險視窗，三件事合在一起指向同一個結論：ML-DSA 現在能用，這件事本身就是它被選中的理由，不是因為它是九個候選裡最好的一個。如果你的團隊還沒有把 ML-DSA 放進 2026 到 2027 年的路線圖，這是這篇文章真正想留給你的提醒。

現實檢查：ML-DSA 不是後量子簽章的終點，是唯一一個現在能用的起點——九個候選都還在排隊，最快的一批也要等到 2030 年後才輪得到你。