探索無簽名的後量子 RLPx 握手協議

作者：Manuel B. Santos (Tectonic Labs)

---

本筆記彙整了關於如何為執行層 P2P 堆疊設計無簽章認證金鑰交換（AKE）的想法。

感謝 Mike Lodder 對 Rebar 方案進行的基準測試。

---

動機

正如最近的一篇 PSE 部落格文章所指出的，以太坊的 P2P 堆疊高度依賴橢圓曲線密碼學。該文章識別了以太坊共識層和執行層 P2P 遷移至後量子（PQ）的幾項需求，並呼籲進行進一步探索。他們基於直接替換 PQ 原語的初步分析凸顯了一些實際限制。例如，在基於 UDP 的 Discv4/5 協定中，直接替換會超過 1280 位元組的 UDP 幀限制。

在此，我們專注於執行層 P2P 堆疊並探索一個特定方向：我們能否完全移除執行層 P2P 的簽章？ 我們不使用 PQ 簽章方案來替換 ECDSA，而是將節點身份與 KEM 金鑰綁定，並將 KEM 同時用於金鑰交換和身份驗證。我們展示了一系列演進的協定，並比較它們的安全特性和頻寬權衡。作為參考，我們也描述了目前的 RLPx 握手協定。

注意： 提議的其中兩個協定使用標準 KEM API，為該層提供了加密敏捷性（crypto-agility）和模組化。在實踐中，我們使用 X-Wing (Barbosa et al., (2024)) 實例化 KEM 以提供混合安全性。最後一個認證金鑰交換則使用特定的基於格（lattice-based）的雙重 KEM 結構，其模組化程度較低。

金鑰交換中的身份驗證類型

在深入探討協定設計之前，有助於釐清金鑰交換中「身份驗證」的含義，因為我們提出的協定實現了不同形式的驗證。我們遵循 Guilhem et al., (2019) 的定義框架：

隱式金鑰驗證（Implicit key authentication）：只有預期的對等方能夠計算出會話金鑰（因為只有他們持有私鑰）。然而，你沒有證據證明他們確實計算了。

顯式金鑰驗證（Explicit key authentication）：你獲得了對等方已經計算出相同會話金鑰的證據。這通常通過**金鑰確認（key confirmation）**實現：一方發送一個從會話金鑰派生出的值（例如 MAC），另一方進行驗證。這源於 Guilhem 等人的組合結果：隱式 AKE + 金鑰確認 => 顯式 AKE。

目前的 RLPx 握手為發起者提供了顯式驗證（通過 ECDSA 簽章），但對接收者僅提供隱式驗證。最後兩個基於 DAKE 的協定在不使用任何簽章的情況下，為雙方實現了顯式驗證。

基於 KEM 的節點身份

總結來說，我們提議一個節點身份僅取決於 KEM 金鑰的系統。64 位元組的 \texttt{nodeId}（目前定義為 ECDSA 公鑰的 \texttt{nodeId} = \mathsf{Keccak512}(\texttt{x} \parallel \texttt{y})）被替換為：

\texttt{nodeId} = \mathsf{Keccak512}(\texttt{ID-HASH-DOMAIN} \parallel \mathsf{pk}_\text{KEM})

其中 \mathsf{pk}_\text{KEM} 是節點的長期 KEM 公鑰。我們對 KEM 金鑰進行雜湊處理而非直接使用，以確保無論 KEM 類型為何，\texttt{nodeId} 都能保持足夠小以放入 UDP 封包。

節點發現（Discovery）

我們專注於 Discv4，其原始設計使用 ECDSA 對每個 gossip 訊息進行簽章。以下顯示其封包結構：

使用 Falcon-512 簽章進行直接替換的結構如下：

事實上，PQ 簽章無法放入為發現訊息分配的 1280 位元組 UDP 幀中。我們不採用分段封包，而是採取更簡單的方法：用雜湊承諾（hash commitments）取代簽章。具體來說，我們使用 \mathsf{Keccak256} 對 \texttt{nodeId} 和原始 Discv4 規範中的標準訊息負載進行承諾。這產生了以下結構：

使用這種方法，我們在發現階段失去了身份驗證。任何人都可以偽造聲稱任何 \texttt{nodeId} 的發現封包。

為什麼這是可以接受的： 真正的身份驗證發生在隨後的 RLPx 握手階段。在現有的 P2P 設計中，攻擊者已經可以本地生成許多金鑰對，製造大量的虛假鄰居公告 Marcus et al., (2018)。在發現階段收到的 \texttt{peerId} 作為握手階段的輸入，允許我們驗證執行握手的一方與參與發現的一方是同一個。

原始 RLPx 握手

現有的 RLPx 協定使用 ECIES（橢圓曲線整合加密方案）進行握手。每個節點都有一個來自簽章方案（secp256k1）的長期金鑰對 (\mathsf{pk}, \mathsf{sk})。

發起者使用 ECDSA 對隨機隨機數（nonce）進行簽章，將 auth 訊息 ECIES 加密至接收者的靜態金鑰，並交換臨時 ECDH 金鑰以派生具有前向安全性的會話金鑰。

有趣的是，RLPx 並不提供接收者的隱式金鑰驗證。這是因為發起者並未檢查接收者是否能夠在第 4 步中解密發起者的臨時公鑰 (e_i_pk)。

基於 KEM 的協定演進

我們提出了三種 PQ 協定變體，並將其與原始 RLPx 進行比較。前兩個變體使用 X-Wing（一種結合了 X25519 和 ML-KEM-768 的混合 KEM (Barbosa et al., (2024))）作為底層 KEM。長期金鑰現在是 KEM 方案的 (\mathsf{pk}, \mathsf{sk})，而非簽章方案。

協定 1：隱式 AKE

第一個協定是隱式認證金鑰交換，雙方互相向對方的長期靜態金鑰進行封裝（encapsulate）。然後，他們結合產生的 KEM 共享秘密 (k_i, k_r) 來派生最終的會話金鑰。

這個 PQ 版本不可避免地比原始 RLPx 多需要一個回合（init 回合），因為發起者必須首先獲取接收者的公鑰。此協定提供的安全特性也比原始 RLPx 少：它不提供前向安全性，因為共享秘密是直接使用長期靜態金鑰封裝的；且僅提供隱式驗證，因為沒有機制確保雙方派生了相同的共享金鑰。

讓我們在接下來的兩個協定版本中解決這些限制。

協定 2：顯式 AKE

此協定旨在為雙方提供前向安全性和顯式金鑰驗證。它遵循 NIST SP 800-227 (Fig. 11, p. 42) 中描述的協定精神。然而，由於我們只需要金鑰驗證而非實體驗證（後者將私鑰綁定到現實世界的實體），因此不需要證書。

前向安全性是通過使用兩個獨立的 KEM 實現的：長期 KEM 金鑰用於身份驗證，臨時 KEM 金鑰用於前向安全性。顯式金鑰驗證是利用 Guilhem 等人的結果獲得的：隱式 AKE + 金鑰確認 = 顯式 AKE。顯式接收者驗證的代價是增加一條確認訊息（從會話金鑰派生的 MAC）和 256 位元組的額外通訊量。

注意： NIST SP 800-227 (Fig. 5, p. 23) 建議從 k_i 派生用於金鑰確認的金鑰。然而，在第 7 步中，我們遵循 Beguinet et al., (2025) 的構造並直接使用 k_i。在此處使用 KDF 不會改變任何通訊指標。

協定 3：顯式 DAKE

最後一個協定在結構上與協定 2 基本相同，但將兩個獨立的 KEM 封裝替換為雙重 KEM（double-KEM） (Maul)。這種構造在單個壓縮密文中，將單個金鑰封裝在兩個公鑰（長期 + 臨時）之下。

該協定深受 Beguinet et al., (2025) 的 \mathsf{DAKE}_2 協定啟發。

對於頻寬估算，我們考慮 \mathsf{DAKE}_2 NIST 第 3 類構造，其密文為 1440 位元組，公鑰為 1240 位元組（參見 Beguinet et al., (2025) 的表 2）。這與 X-Wing 的後量子安全等級相匹配。

由於雙重 KEM 壓縮，ack 訊息從 2,528 位元組縮減至 1,728 位元組。然而，這種方法僅壓縮了 ack 訊息；其他訊息基本保持不變。

由於 Maul 雙重 KEM 尚未有實現，我們對 Rebar 進行了基準測試，這是 Hashimoto et al., (2025) 提出的一種具有相似壓縮率的並行構造（強化 KEM，RKEM）。為了可重複性，您可以查看我們基準測試的代碼在此。

與兩個獨立的 ML-KEM-512 操作相比，強化 KEM (RKEM) 引入了計算開銷：

雖然 Rebar 引入了約 9 倍的計算開銷，但在握手期間這種影響可能會被稀釋，因為通訊延遲佔主導地位。

比較與總結

頻寬的增加（800 B 對比 7–8 KB）在理論上是顯著的，但握手在每個節點連接中僅發生一次，且以太坊節點維持長期的對等連接。一旦會話建立，對稱加密就會接管。因此，額外的往返（4 條訊息對比 2 條）引入了一個額外的 RTT 延遲，這對於預期持久存在的連接來說是可以接受的。

在提議的設計中，協定 2（顯式 AKE）提供了最平衡的權衡。它實現了所有期望的安全屬性（前向安全性 + 顯式金鑰驗證），同時僅依賴於標準、易於理解的混合 KEM 構造。

雖然協定 3 通過雙重 KEM 壓縮減少了頻寬，但在一次性握手的背景下，收益相對有限。考慮到額外的複雜性、缺乏成熟的實現以及非平凡的計算開銷，這些節省並不足以支撐放棄更簡單且更穩健的構造。

        1 則貼文 - 1 位參與者

        [閱讀完整主題](https://ethresear.ch/t/exploring-signature-free-post-quantum-rlpx-handshake/24413)