基於 EVM 事件日誌的混合後量子端到端加密通訊方案

基於 EVM 事件日誌的混合後量子端到端加密通訊方案

Ethereum Magicians·大約 4 小時前
原文

我正在提議一種基於 EVM 事件日誌的後量子抗性加密通訊標準化傳輸與電報格式，透過混合密鑰交換與棘輪訊息主題，確保長期隱私性與不可否認性。

大家好，

我一直在編寫一份關於「基於 EVM 事件日誌的抗量子加密通訊」的草案（predraft），我想儘早分享出來以獲取反饋，例如這是否真的需要標準化。

[ERC 草案預覽]

其目標是標準化一個小型的傳輸與線路格式（wire format）層面，使獨立的客戶端能夠實現互操作，但不標準化索引、通知、存儲、垃圾郵件控制或收件箱行為。這些問題留給前端應用程序處理。

相關工作

首先，這並不是該領域的第一次嘗試：

  • ERC 7627 探索了安全通訊，更強調鏈上金鑰註冊和靈活的對話元數據。
  • ERC 7970 在精神上可能是最接近的提案，儘管它對加密行為和線路格式並未給出明確規範。
  • ERC 8180（與 ERC-3722 有些關聯）也有相關性，但對我來說，它與這項工作是並行關係而非上下層關係，因為它關注的是基於 Blob 的身份驗證消息傳遞和解碼器發現。

我的印象是設計空間尚未收斂，我認為這裡還有空間容納一種更具主張（opinionated）的互操作方法。這篇文章也源於「實作優先」的視角，因為我已經在一個公開 SDK 和一個簡單的 Demo 中探索並測試了這些想法。

我的提案內容

  • 一個小型的傳輸合約，包含 sendMessage、initiateHandshake 和 respondToHandshake 方法。
  • 相應地，定義三個事件：握手發起（handshake initiation）、握手響應（handshake response）和握手後的消息傳遞（post-handshake message delivery）。
  • 使用帶版本的長期公鑰進行身份綁定和消息認證，並使用臨時金鑰進行會話建立和消息傳遞。
  • 與錢包綁定的身份證明，將這些金鑰與 EVM 帳戶綁定。
  • 混合抗量子金鑰交換（Hybrid post-quantum key exchange），使記錄的流量免受「現在收集，以後解密」（harvest-now-decrypt-later）的威脅。
  • 握手響應標籤（Handshake-response tags）在公開層面上無法與發起的握手相關聯。
  • 棘輪消息主題（Ratcheted message topics）會隨紀元（epochs）旋轉，而不是像穩定的對話識別碼那樣運作。

高層級流程

這是我一直在實驗的簡化生命週期：

Alice Bob

  1. 生成臨時 X25519 金鑰
  2. 生成 ML-KEM 768 金鑰對
  3. 構建錢包綁定的身份證明

握手事件 (Handshake event) ---------------------------------->
recipientHash 選擇器
發送者長期公鑰
發起者臨時 X25519 + ML-KEM 公鑰
身份證明 + 選填的純文字備註

                                                      4. 讀取握手
                                                      5. 驗證身份證明
                                                      6. 生成響應標籤金鑰對
                                                      7. 生成首個棘輪金鑰對
                                                      8. 封裝至 Alice 的 ML-KEM 公鑰
                                                      9. 導出混合響應標籤

握手響應事件 (HandshakeResponse event) <---------------------
inResponseTo（由傳統 + 抗量子密鑰材料導出）
公開響應標籤金鑰
加密負載，包含：
響應者長期公鑰
首個棘輪公鑰
ML-KEM 密文
響應者身份證明

  1. 解密響應
  2. 重新計算並驗證 inResponseTo
  3. 導出相同的混合根密鑰
  4. 初始化棘輪會話

會話已建立

消息發送事件 (MessageSent event) ---------------------------->
當前主題上的已簽名棘輪負載

消息發送事件 (MessageSent event) <----------------------------
當前主題上的已簽名棘輪負載

每個新的 DH 紀元都會旋轉主題，因此過去的主題無法用於將未來的消息與同一對話關聯起來。

為什麼不可否認性（Non-repudiation）很重要

不可否認性對於端到端加密（e2ee）通訊協議來說是一個不尋常的特性，我認為值得更深入地考慮它，因為它允許一些有趣的應用。

由於每個交付的密文也是一筆鏈上交易，任何第三方都可以驗證區塊、交易哈希、發出事件的合約以及發布它的帳戶。如果發送者是 EOA，歸屬是直接的；如果是智能帳戶，則歸屬較不明顯（即仍簡化為 calldata 中的所有者簽名或 UserOp 簽名）。無論如何，這意味著區塊鏈已經證明了一個重要的事實：特定帳戶授權在特定時間發布了特定密文（即完全不需要披露對話內容）。如果稍後披露了明文，錢包綁定的身份證明和簽名的棘輪負載可以將披露的內容與會話中使用的通訊身份聯繫起來。

這與 Signal 系列系統非常不同，後者的設計目的是使保存的對話記錄不會成為外部人士的便攜式證明（即消息使用雙方共享的對稱 MAC 金鑰進行驗證，因此任何一方都可以合理地偽造任何消息）。

我在此提出的內容也與 XMTP 等離鏈系統不同，但方式更為具體。我認為 XMTP 可以通過導出的協議工件及其身份層支持可驗證的歸屬，但這種證明通常不是公開見證的鏈上事件。它依賴於披露離鏈對話材料，並將安裝級別的金鑰與收件箱身份聯繫起來，進而與錢包或其他識別碼聯繫起來。

關於未來可能擴展的想法

一個可能的擴展是隱藏委託（hidden delegation），即由中繼者發布密文，而主體身份保留在加密信封內（即不像現在這樣是公開的）。在這種情況下，問責制就變得依賴於披露：一旦接收者揭示了隱藏的身份證明，第三方就可以驗證鏈上中繼發布和披露證明中攜帶的主體歸屬。

至於否認性（deniability），我目前的觀點是，完全的傳輸層否認性與公開事件日誌是不兼容的。在棘輪對話記錄中實現較窄形式的否認性可能仍值得探索，我很感興趣這是否有意義的反饋。

如何處理元數據隱私

假設具備前向安全性（forward secrecy）和後向安全性（post-compromise security）的完全端到端加密，可實現的目標不是消除所有元數據，而是消除任何可高效驗證的關聯，讓觀察者只能進行統計推斷，其質量取決於流量大小和側向信息。

換句話說，一旦從傳輸中移除了確定性的接收者發現（即 recipientHash），或者接收者過濾發生在客戶端而非 RPC 層，觀察者就只能依賴啟發式方法。一個簡單的直覺是：令 $C(e')$ 為一組早期事件，這些事件在加密學上未被排除作為目標事件 $e'$ 的可能前置事件。那麼：

$Pr[e \leftrightarrow e' | view] = w(e, e') / \sum_{x \in C(e')} w(x, e')$

其中 $w(e, e')$ 是根據時間、可見的發送者活動和觀察者可獲得的任何其他側向信息得出的啟發式權重。因此，應該消失的是任何能讓某個候選對以近乎確定的機率主導分佈的公開規則。當然，這在公開鏈觀察者層面和 RPC 或索引器層面的影響是不同的，因為後者還能看到客戶端的查詢。

緩解方案

我認為該提案應明確區分「針對公開觀察者的接收者隱私緩解」與「針對 RPC 或索引器的查詢隱私緩解」（後者可以做前者能做的一切，反之則不然）。因此，主要的緩解選擇及其權衡應與現狀進行權衡（見上圖）：

  • 保留 recipientHash，但避免服務端接收者過濾。客戶端通過本地掃描握手日誌而非查詢特定的 recipientHash 過濾器來發現傳入的握手。這消除了握手發現期間的第一個身份洩漏，但它並未向公開觀察者隱藏首次聯繫的嘗試，因為 recipientHash 仍然可以進行字典匹配。如果隨後的 MessageSent 檢索仍使用特定主題的服務端過濾器，RPC 仍可以觀察到匿名讀取模式以及對來自可見發送者消息的興趣。消失的是直接的「網絡客戶端 $\rightarrow$ 接收者」引導，而非所有查詢洩漏。因此，這種方法最私密的版本是對所有事件進行完整的本地掃描，在掃描範圍內的成本為 $O(N)$。

  • 從公開握手選擇器中移除 recipientHash。發送者不再發布確定性的接收者選擇器，而是將接收者定位材料在接收者特定的公開材料下加密，接收者僅保留他們能解密的握手事件。這消除了針對首次聯繫的公開字典攻擊，也消除了讓惡意 RPC 將查詢客戶端（例如通過 IP 地址或 TLS 指紋）與接收者地址聯繫起來的初始關聯步驟。隨後的主題查詢對 RPC 仍然可見，但僅表現為對可見發送者發出主題的匿名興趣。因此，RPC 不再有直接方法斷定兩個地址正在交談，並被推回到上述的啟發式方法。這是一個更好的隱私起點，儘管它仍不是完全的私密檢索。它至少在握手發現時仍需要線性的客戶端掃描（即 $O(N)$，其中 $N$ 現在僅是握手請求的數量，這可能比總消息流量小幾個數量級）。它還需要某種方式來發布接收者加密材料，例如鏈上註冊表或其他公鑰分發機制。

  • 使用 TEE 輔助索引器的私密信令。另一個選擇是向索引服務隱藏接收者興趣，遵循這篇論文中探索的私密信令方向：發送者發布一個公開郵箱條目，而接收者定位材料在 TEE 內部處理，只有預期的接收者知道匹配結果。權衡之處在於額外的基礎設施、硬件假設和擴展性限制，這與其他方法非常不同。

我目前的觀點是，ERC 可能應該避免對這一層進行過度標準化，但明確其假設的隱私模型及相關建議（例如避免將同一個提供商用於交易提交和讀取查詢，因為這會給單方提供更強的關聯優勢）仍然是有用的。

抗量子（HNDL）能力

消息內容的機密性不應面臨「現在收集，以後解密」的威脅。未來的攻擊者不應能夠記錄今天的流量，並在以後利用更強的能力恢復消息內容、將握手響應與後續流量關聯，或僅從存儲的痕跡中關聯後續的棘輪主題。

目前的構造嘗試通過基於 X25519 + ML-KEM 768 的混合引導、由傳統和抗量子密鑰材料導出的握手響應標籤，以及由混合根密鑰加鹽的主題導出來強制執行這一點。我的意圖是，抗量子方案應涵蓋機密性和關聯抗性，而不僅僅是消息解密。

我最希望獲得反饋的地方

  • 這是正確的標準化層級嗎？還是它仍然太過於應用特定，以至於無法從 ERC 中受益？
  • 隱私模型是否連貫？
  • 在上述緩解方案中，哪一個對於互操作標準來說感覺是現實的（如果有的話）？
  • 不可否認性在這裡感覺有用嗎？還是它更有可能成為不採用此設計的理由？
  • 目前的範疇是否足夠窄？還是我仍然標準化了太多的通訊堆棧？

我特別看重對隱私和安全模型的反對意見。有關合約和 SDK 的更多細節，您可以在這裡找到一些正在編寫中的文檔。

謝謝

1 則貼文 - 1 位參與者

閱讀完整主題

https://ethereum-magicians.org/t/hybrid-post-quantum-e2ee-messaging-over-evm-event-logs/28198