Exploring Signature-Free Post-Quantum RLPx Handshake
by Manuel B. Santos (@manel1874) and Danno Ferrin (@shemnon) form Tectonic Labs.
This note collects ideas on how to design a signature-free authenticated key exchange (AKE) for the execution-layer P2P stack.
Acknowledgments to Mike Lodder for running benchmarks on the Rebar scheme.
Motivation
As noted in a recent PSE blogpost, Ethereum’s P2P stack relies heavily on elliptic-curve cryptography. The blog post identifies several post-quantum (PQ) migration requirements for Ethereum’s consensus and execution P2P layers and concludes with a call for further exploration. Their initial analysis, based on a drop-in replacement of PQ primitives, highlights some practical constraints. For example, in the UDP-based Discv4/5 protocols, a drop-in replacement exceeds the 1280-byte UDP frame limit.
Here we focus on the execution P2P stack and explore a specific direction: can we remove signatures from the execution P2P layer entirely? Instead of replacing ECDSA with a PQ signature scheme, we bind node identity to KEM keys and use KEMs for both key exchange and authentication. We present a progression of protocols and compare their security features and bandwidth trade-offs. For reference, we also describe the current RLPx handshake protocol.
Note: Two of the proposed protocols use the standard KEM API, providing crypto-agility and modularity for this layer. In practice, we instantiate the KEM with X-Wing (Barbosa et al., (2024)) to provide hybrid security. The final authenticated key exchange uses a specific lattice-based double-KEM construction, which provides less modularity.
Authentication Flavors in Key Exchange
Before diving into protocol designs, it helps to clarify what “authentication” means in a key exchange, since the protocols we present achieve different forms of it. We follow the definitional framework of Guilhem et al., (2019):
-
Implicit key authentication: Only the intended peer could compute the session key (because only they hold the private key). However, you have no proof that they actually did.
-
Explicit key authentication: You obtain evidence that the peer has computed the same session key. This is typically achieved through key confirmation: one party sends a value (e.g., a MAC) derived from the session key, and the other verifies it. This follows from a composition result by Guilhem et al.: implicit AKE + key confirmation => explicit AKE.
The current RLPx handshake provides explicit authentication for the initiator (via an ECDSA signature) but only implicit authentication for the recipient. The two last DAKE-based protocols achieve explicit authentication for both parties, without using any signatures.
KEM-Based Node Identity
In summary, we propose a system in which node identity depends solely on KEM keys. The 64-byte \texttt{nodeId} (currently defined as \texttt{nodeId} = \mathsf{Keccak512}(\texttt{x} \parallel \texttt{y}) of the ECDSA public key) is replaced with:
where \mathsf{pk}_\text{KEM} is the node’s long-term KEM public key. We hash the KEM key rather than using it directly, keeping \texttt{nodeId} small enough for UDP packets regardless of the KEM type.
Discovery
We focus on Discv4, which in its original design signs every gossip message with ECDSA. Below we show the structure of its packet:
A drop-in replacement with a Falcon-512 signature would look something like this:
Indeed, PQ signatures do not fit within the 1280-byte UDP frame allocated for discovery messages. Instead of fragmenting packets, we take a simpler approach: replace signatures with hash commitments. More specifically, we commit to the \texttt{nodeId} and the standard message payload from the original Discv4 specification using \mathsf{Keccak256}. This leads to the following structure:
With this approach, we loose authentication at discovery time. Anyone can forge a discovery packet claiming any \texttt{nodeId}.
Why it is acceptable: real identity validation happens during the subsequent RLPx handshake phase. In the existing P2P design, an adversary can already locally generate many key pairs, creating a large number of fraudulent neighbor announcements Marcus et al., (2018). The \texttt{peerId} received during discovery serves as input to the handshake phase and allows us to verify that the party performing the handshake is the same one that participated in discovery.
Original RLPx Handshake
The existing RLPx protocol uses ECIES (Elliptic Curve Integrated Encryption Scheme) for the handshake. Each node has a long-term key pair (\mathsf{pk}, \mathsf{sk}) from a signature scheme (secp256k1).
The initiator signs a random nonce with ECDSA, ECIES-encrypts an auth message to the recipient’s static key, and exchanges ephemeral ECDH keys to derive session keys with forward secrecy.
Interestingly, RLPx does not provide recipient implicit key authentication. This occurs because the initiator does not check whether the recipient was able to decrypt the initiator’s ephemeral public key (e_i_pk) in step 4.
A Progression of KEM-Based Protocols
We present three PQ protocol variants and compare them with the original RLPx. The first two variants use X-Wing (a hybrid KEM combining X25519 and ML-KEM-768 (Barbosa et al., (2024)) as the underlying KEM. Long-term keys are now (\mathsf{pk}, \mathsf{sk}) of a KEM scheme rather than a signature scheme.
Protocol 1: Implicit AKE
The first protocol is an implicit authentication key exchange in which both parties encapsulate to each other’s long-term static keys. They then combine the resulting KEM shared secrets (k_i, k_r) to derive a final session key.
This PQ version inevitably requires one more round (the init round) than the original RLPx, because the initiator must first obtain the recipient’s public key. This protocol also provides fewer security features than the original RLPx: it offers no forward secrecy, since the shared secrets are directly encapsulated using long-term static keys, and only implicit authentication, since there is no mechanism ensuring both parties derived the same shared keys.
Let’s address these limitations in the next two protocol versions.
Protocol 2: Explicit AKE
This protocol aims to provide forward secrecy and explicit key authentication for both parties. It follows the spirit of the protocol described in NIST SP 800-227 (Fig. 11, p. 42). However, since we only require key authentication and not entity authentication (which binds a private key to a real-world entity), certificates are not necessary.
Forward secrecy is achieved by using two separate KEMs: long-term KEM keys for authentication and ephemeral KEM keys for forward secrecy. Explicit key authentication is obtained using the result from Guilhem et al.: implicit AKE + key confirmation = explicit AKE. The price of explicit recipient authentication is one additional confirmation message (a MAC derived from the session key) and 256 bytes of additional communication.
Note: NIST SP 800-227 (Fig. 5, p. 23) recommends deriving a key for key confirmation from k_i. However, in Step 7 we follow the construction from Beguinet et al., (2025) and use k_i directly. Using a KDF here would not change any communication metrics.
Protocol 3: Explicit DAKE
The final protocol has essentially the same structure as Protocol 2, but replaces two independent KEM encapsulations with a double-KEM (Maul). This construction encapsulates a single key under two public keys (long-term + ephemeral) in a single compressed ciphertext.
The protocol is heavily inspired by the \mathsf{DAKE}_2 protocol from Beguinet et al., (2025).
For the bandwidth estimation, we consider the \mathsf{DAKE}_2 NIST Category 3 construction with a ciphertext of 1440 bytes and a public key of 1240 bytes (see Table 2 of Beguinet et al., (2025)). This matches the same post-quantum security level as X-Wing.
The ack message shrinks from 2,528 bytes to 1,728 bytes thanks to double-KEM compression. However, this approach only compresses the ack message; the other messages remain mostly unchanged.
Because Maul double-KEM does not yet have an implementation, we benchmarked Rebar, a concurrent construction (reinforcing KEM, RKEM) by Hashimoto et al., (2025), with a similar compression rate. For reproducibility, you can check the code for our benchmarks here.
The reinforcing KEM (RKEM) introduces a computational overhead compared to two independent ML-KEM-512 operations:
Although Rebar introduces a \sim 9\times computational overhead, the impact will likely be diluted during the handshake because communication latency dominates.
Comparison & Final Remarks
The bandwidth increase (800 B vs. 7–8 KB) is significant on paper, but the handshake occurs only once per peer connection and Ethereum nodes maintain long-lived peer connections. Once the session is established, symmetric encryption takes over. So, the additional round-trip (4 messages vs. 2) introduces one extra RTT of latency, which is acceptable for a connection that is expected to persist.
Among the proposed designs, Protocol 2 (Explicit AKE) offers the most balanced trade-off. It achieves all the desired security properties (forward secrecy + explicit key authentication) while relying only on standard, well-understood hybrid KEM constructions.
Although Protocol 3 reduces bandwidth through double-KEM compression, the gains are relatively modest in the context of a one-time handshake. Given the additional complexity, lack of mature implementations, and non-trivial computational overhead, these savings do not justify moving away from a simpler and more robust construction.