Towards a Quantum-Safe P2P for Ethereum

Motivation

As quantum computing continues to evolve, there is increasing interest in understanding how Ethereum’s existing peer-to-peer (P2P) networking stack might adapt to emerging post-quantum (PQ) cryptographic standards. PSE members Adria and Guorong undertook a brief exploratory project to assess what adopting PQ algorithms in Ethereum’s P2P layer would entail. This exploration aimed primarily at gaining clarity around potential challenges and identifying realistic directions for future PQ-focused efforts. Ultimately, the project highlighted significant practical limitations, providing valuable insights that we hope will help inform further PQ initiatives.

The Current Stack

P2P networking handles node discovery and data transport between nodes. Nodes are identified by an Ethereum Node Record (ENR), a self-signed dictionary containing the node ID, public key(s), and network location.

Node discovery is achieved via Discv5, which uses UDP (with a maximum packet size of 1280 bytes). UDP avoids maintaining persistent connections, aids NAT traversal, and complicates packet linking in traffic analysis (packets are randomized and encrypted). After an initial handshake, nodes communicate using session keys—nodes send a FINDNODE request and receive ENRs in NODES responses.

Following discovery, the execution layer uses the RLPx protocol, while the consensus layer uses libp2p. RLPx provides ciphered and authenticated transport with its own handshake and supports subprotocols—primarily EthWire for transporting blocks, transactions, and receipts. The consensus layer communicates via libp2p over TCP or QUIC, using encrypted sessions established with the well-known Noise Protocol handshake.

Post-Quantum State of the Art

Currently, several widely used algorithms are not considered PQ safe:

New PQ primitives exist, but they are not “drop-in” replacements. Their differing properties require careful integration. For instance, FN-DSA includes an internal hasher, so signing the entire message is preferable over signing a digest. Most of these algorithms have undergone lengthy NIST reviews, with more expected in the future. Remember that we are already using non-standardized algorithms such as secp256k1, Keccak, Groth16, and STARKs. Sometimes "only using approved" is not a good idea.

Note that PQ public keys and signatures are significantly larger than current ECDSA sizes (33 bytes for public keys, 65 bytes for signatures). For example, Falcon requires a padded signature size of 666 bytes and a public key of 897 bytes (which can be combined into 1328 bytes for transport). Check this nice Cloudflare table.

A New PQ P2P Crypto Stack?

The following table summarizes the cryptographic substitutions proposed for each transport layer:

The replacement for ECDH is essentially as described in the NIST Workshop on Guidance for KEMs; a test implementation can be found at https://github.com/adria0/pq-aka. As you can see, this construction is not a NIKE, so it requires roundtrips.

Let's do a quick check if we are targeting the PQ threats here:

Forward Secrecy:
Critical to prevent “harvest-then-decrypt” attacks. Although urgent in post-quantum scenarios, it does not seem to be a problem at the P2P layer.

Ownership:
Cryptographically secured assets (protected by EthWire transaction signatures) must remain secure. Account abstraction could improve protection by, for example, requiring an additional Falcon signature in the calldata. (Note: This is not strictly a P2P transport problem.)

Availability:
Systems must maintain performance despite increased data sizes. The expansion from 65 to 1328 bytes for signatures can stress the network. Techniques such as storing public keys in indexed registry smart contracts and transmitting only the signature may mitigate this. It is not clear how much this increase could congest the network, enlarge block sizes, or lengthen block times. To avoid moving from UDP to TCP, perhaps QUIC could help.

Security:
While we are now using safe algorithms, PQ algorithms are still under scrutiny and may be vulnerable. A recommended strategy is to use composite keys—combining traditional and post-quantum keys—to hedge against potential weaknesses, albeit with additional performance overhead. This is a strong recommendation from the IETF pquip team.

Dependency:
Compromises in dependent systems (DNSSEC, TLS) could undermine network security, providing alternate attack vectors. Fortunately, P2P primarily uses IP/IPv6 addresses, so it seems unaffected.

Note on libp2p Exploration

libp2p is the P2P networking stack, mainly used for the consensus layer in the Ethereum blockchain. One of our explorations includes migrating libp2p networking to a PQ-safe implementation. The current libp2p implementations depend on ECC (secp256k1, etc.) for communication (key exchange) and authentication (generation and validation of node IDs).

Here, the specific target is QUIC—a transport protocol built on UDP. At the moment, the adoption of QUIC is quite high among CL clients, and it is expected to grow in the future.

We have explored migrating the key exchange part of rust-libp2p to a PQ-safe implementation (e.g., using Kyber KEM) in this fork. Additionally, there is an example. Our conclusions are as follows:

• Using a KEM algorithm for key exchange does not significantly degrade communication, as the main process relies on symmetric cryptography which is less affected by quantum computing.
• Other aspects (authentication, node ID generation, etc.) require further in-depth research but are not immediately urgent.

Additionally, we have learned:

• Major tech firms (Cloudflare, IBM, Google) are conducting experiments on PQ migration of networking protocols:
  • Cloudflare's Post-Quantum for All
  • Microsoft's Post-Quantum TLS
• These companies, especially Cloudflare, have detailed benchmarks on their experiments.
• From their perspective, migrating communication cryptography is more urgent than authentication, as the communication component is vulnerable to Harvest Now, Decrypt Later attacks.
• Their client-server experiments might be applicable to P2P networking with less effort, given that P2P combines client and server functionalities.

A Call for Action

While the proposed changes are not entirely appealing as drop-in replacements, they represent initial attempts to integrate PQ cryptographic methods within the existing framework. However, these efforts highlight significant limitations and underscore the need for innovation in this area.

We must reconsider transport protocols:

• Discv5 over UDP appears impractical due to oversized ENRs and fragmented handshakes.
• A redesign of secure discovery protocols using current PQ algorithms is necessary, supported by robust network simulations and advanced P2P engineering.
• Transitioning to QUIC combined with a PQ-Noise approach for P2P communication appears promising as a replacement for RLPx.

Techniques such as aggregated gossip signatures could help mitigate increased network traffic. Research into compressing signatures and transient information after finalization is also encouraged.

Despite criticisms regarding its internal complexity and limited PQ adaptation, libp2p—especially its Kademlia DHT—remains a candidate for evolving to meet future PQ challenges.