你簽署資料結構的方式依然是錯誤的

背景

在分散式系統與密碼學應用中，如何正確地將資料結構序列化並進行簽署一直是一項挑戰。本文探討了當不同類型的資料結構在序列化後呈現相同的位元組流時，攻擊者可能利用這種「類型混淆」將一個訊息的簽名套用到另一個訊息上，進而引發嚴重的安全漏洞。為了解決此問題，作者提出在介面定義語言（IDL）中直接嵌入隨機且不可變的「領域分隔符」（Domain Separators），確保簽署與驗證過程能強制區分不同的資料類型。

社群觀點

針對這項提案，Hacker News 社群展開了深入的技術辯論。部分資深開發者指出，這並非全新的概念，而是密碼學設計中早已存在的「霍頓原則」（Horton Principle），即簽名必須與特定的上下文綁定。有留言者認為，文章所提的方案本質上是將上下文資訊作為雜湊函數的輸入，而不實際傳輸這些位元組，這確實能有效防止類型混淆，且不會增加傳輸負擔。然而，也有批評者認為文章將此視為「懸而未決的問題」過於誇大，因為正確的密碼學實踐本就要求在驗證前不應觸碰原始資料，且必須在金鑰衍生或 MAC 計算中混入上下文。

社群中對於「如何實作」有著多元的看法。有討論者建議，若使用 Protobuf，其實可以透過自定義的訊息選項（Message Options）來達成類似效果，而不必發明全新的工具。另一種觀點則提出「帶內」（in-band）處理，例如在資料中始終包含一個類型欄位，雖然這會增加傳輸體積，但邏輯更為直觀。針對序列化本身的效能與規範化問題，有留言者分享了使用「多重集雜湊」（Multiset Hashing）的替代方案，認為這能繞過複雜的規範化步驟，直接產生確定性的雜湊值，不過這主要解決的是資料排序問題，而非領域分隔。

有趣的是，這場討論也引發了對技術演進的感嘆。一些資深工程師提到，這類問題在早期的 ASN.1 標準中就已經處理過，現在的討論像是「重新發明輪子」，並預言下一步業界可能會重新發現「在資料中加入版本號」的重要性。此外，也有人將此問題延伸到現實世界的應用，例如電子郵件的 DKIM 簽名雖然能驗證發件者，但往往無法防止「收件者混淆」的攻擊，這類漏洞的本質與本文討論的領域分隔缺失如出一轍。整體而言，社群認同工具鏈自動化處理領域分隔符能降低開發者的認知負擔，但也強調這只是安全設計的一環，開發者仍需對訊息的語義驗證負起最終責任。

延伸閱讀

• The Cryptographic Doom Principle：關於在驗證簽名或 MAC 之前處理不可信資料的風險。
• Horton Principle：密碼學中關於簽名必須包含上下文語義的設計原則。
• Signing JSON the right way：Retr0id 提到的替代方案，探討如何利用多重集雜湊達成確定性雜湊。
• CVE-2022-24771 & CVE-2025-12816：關於 OID 處理不當導致的安全漏洞實例。