aere-docs/AERE-QUANTUM-SAFE-NETWORKING.md

Aere Network Quantum-Safe Networking (Transport Layer)

Spec #30, Wave 1. Design document. Status: NOT LIVE.

This document specifies making Aere's network transport post-quantum. It is a design and rollout spec, not a change log. Nothing described here is live on Aere mainnet at time of writing. The two parts have very different costs, and this document is explicit about that: the RPC part is close to a configuration and build change, the node-to-node part is real protocol engineering. Both are marked with their honest status inline.

Scope in one line: this is transport confidentiality work (protection against harvest-now-decrypt-later on the wire). It does not touch consensus, and it is not end-to-end application messaging. See Section 6 for the hard scope boundaries.

---

1. The gap: layer 12

Aere's quantum-resistance story is organized as a stack of layers. Most of that stack is already covered or on a defined roadmap. Reading the current layer map (aerenew/build-tracker/control.json, quantumLayers):

Layer	What it is	State today
1. Signatures / accounts	PQC signature verification, PQC accounts	have (live on mainnet since the AerePQC fork, block 9,189,161)
4. Encryption (ML-KEM)	ML-KEM precompile	have (precompile present; mainnet activation gated)
3. Verification (zk proofs)	PQ STARK verify, off BN254	building (#2), scope-corrected (see note)
2. Consensus (validator signatures)	PQC validator seals	next (built and tested, founder + audit + N>=9 gated)
5..10	finality/light-client, bridges, agent mandates, threshold, compliance, oracles	next (roadmap)
11. Migration (old accounts + network keys)	move legacy ECDSA funds to PQ, rotate network keys	gap (#14)
12. Transport / networking	how nodes and clients actually connect	gap (this document, #30)

Note on layer 3 (scope caveat, 2026-07-19 finding): the PQ STARK verifier skeleton (#2, 0x0AE8) built so far is a BabyBear + FRI STARK verifier, conformance-confirmed against Plonky3 and targeting Aere's OWN circuits. It does NOT yet verify SP1 6.1.0 proofs (SP1 6.1.0 is Hypercube / KoalaBear multilinear, a different stack), so "off BN254" for the SP1 zk-verifier path is a separate ~22 to 32 person-week retarget, not imminent. On-chain zk verifiers remain classical BN254 today. See AERE-STARK-SP1-RECURSION-AIR-PORT-SPEC-SUMMARY.md.

Layers 1 through 11 are about what the chain signs and verifies. Layer 12 is about the pipes: the encrypted channels over which a wallet talks to an RPC endpoint, and over which one node talks to another. Today those pipes negotiate their session keys with classical elliptic-curve cryptography (X25519, secp256k1). Both key exchanges are broken by a sufficiently large quantum computer running Shor's algorithm. That is the gap this document closes on paper and stages for rollout.

Important framing, stated up front so it is not lost: the symmetric ciphers on these channels (AES-256-GCM on TLS, AES-256 on the node-to-node transport) are not the problem. Grover's algorithm only halves their effective strength, which leaves AES-256 at a 128-bit security floor, still sound. The Shor-vulnerable part of both channels is exclusively the key agreement (how the two sides derive a shared secret). So the whole of layer 12 reduces to one move, applied in two places: replace or augment the classical key agreement with a hybrid post-quantum key-encapsulation mechanism (KEM).

---

2. Threat model: harvest-now-decrypt-later

The concrete threat this work addresses is harvest-now-decrypt-later (HNDL): an adversary records encrypted traffic today, stores it, and decrypts it years later once a cryptographically relevant quantum computer exists. Anything whose confidentiality must outlive the arrival of that machine is at risk the moment it crosses a classically-keyed channel.

Two properties of this threat shape the whole design:

1. It is a passive, present-day attack. The adversary does not need a quantum computer now. It needs a tap and a disk now, and the quantum computer later. This is why the fix is worth doing before quantum computers exist, and why "we will upgrade when we have to" is the wrong posture: traffic recorded today is already committed.

2. It targets confidentiality, via the key exchange. HNDL breaks the recorded session by recovering the session key from the recorded handshake. It does not require breaking authentication in real time. This is exactly why hybridizing the KEM (not necessarily the certificate or the signature) is the effective and sufficient first move, and why this is a transport-confidentiality document, not a transport-authentication one. PQ authentication of the channel (PQ certificates, PQ handshake signatures) defends a different threat, an active quantum MITM at connection time, and is a later, separate concern noted in Section 6.

What is genuinely sensitive on each Aere transport surface, and therefore worth HNDL protection, differs between the two surfaces, and the document is honest about that in each part (Section 4.6 for RPC, Section 5.4 for devp2p).

---

3. Where transport crypto lives in Aere today

There are exactly two transport surfaces on the network, and they use different cryptographic machinery. This is the single most important fact for understanding why the effort splits so unevenly.

Surface A: public JSON-RPC over TLS. A wallet, dapp, indexer, or ethers.js client connects to rpc.aere.network or rpc2.aere.network over HTTPS. TLS is terminated at nginx on the box, which reverse-proxies cleartext to the local Besu node on 127.0.0.1:8545 (Besu's RPC port is not publicly bound). This is confirmed by the live setup for the second public RPC (aerenew/docs/RPC2-NODE-2026-07-17.md, Section 3 and Section 5): nginx owns ports 80/443, terminates Let's Encrypt TLS, and is the sole public path to the node. The same shape holds for the primary infra RPC. The key exchange here is ordinary TLS 1.3, today negotiating classical groups (X25519 and the NIST P-curves).

Surface B: node-to-node over devp2p / RLPx. Validators and full nodes connect to each other over Ethereum's devp2p protocol on TCP/UDP port 30303 (the rpc2 firewall opens exactly this: 30303 tcp for RLPx and 30303 udp for discovery). The encrypted transport under devp2p is RLPx, and RLPx does not use TLS. It has its own handshake: an ECIES scheme (Elliptic Curve Integrated Encryption Scheme) over the secp256k1 curve, deriving AES and MAC keys for the framed session. This is a completely separate piece of cryptography from TLS, living inside the Ethereum client's networking stack.

The consequence: making Surface A post-quantum is a change to a well-known, widely supported, standards-track TLS knob at a standard TLS terminator (nginx + OpenSSL). Making Surface B post-quantum is a change to a bespoke handshake implemented in the guts of Besu and Nethermind, with no standards-track PQ variant to simply switch on. That asymmetry is the whole story of this document.

---

4. Part A: post-quantum TLS on the public RPC (the near-config part)

Effort: low. This is largely a build and configuration change, not a protocol change. Status: not live; straightforward enablement.

4.1 The hybrid group: X25519MLKEM768

The mechanism is a hybrid TLS 1.3 key-exchange group, X25519MLKEM768. "Hybrid" means the handshake runs two key exchanges concurrently and combines their outputs into the session secret:

• X25519, the classical elliptic-curve Diffie-Hellman already in use, and
• ML-KEM-768 (the NIST FIPS 203 standardized module-lattice KEM, formerly Kyber).

Because the shared secret mixes both, the session is secure as long as either primitive holds. A quantum adversary who breaks X25519 still faces ML-KEM-768; a lattice cryptanalysis result that dents ML-KEM still leaves X25519. Hybrid is therefore strictly no weaker than the classical group it replaces, which is exactly why it is safe to deploy now rather than betting the channel on a young post-quantum primitive alone.

Real-world status of this specific group, which is what makes Part A cheap:

• It is the IETF standards-track hybrid (the X25519MLKEM768 named group, IANA TLS Supported Groups code point 0x11EC), the successor to the earlier experimental X25519Kyber768Draft00.
• OpenSSL 3.5 (released April 2025, an LTS release) supports X25519MLKEM768 natively, with no external provider required. It also ships the related SecP256r1MLKEM768 and X448MLKEM1024 groups and native ML-KEM / ML-DSA / SLH-DSA.
• Chrome / BoringSSL ship X25519MLKEM768 and negotiate it by default, so a large fraction of real clients already offer the group. Firefox has shipped it as well.
• For OpenSSL 3.x builds older than 3.5, the reference way to add the group is oqs-provider loaded through the OpenSSL provider interface, backed by the liboqs library (the Open Quantum Safe project). This is the fallback path if a box cannot yet run OpenSSL 3.5.

4.2 Build prerequisite (the one real cost of Part A)

The only non-trivial step is that the TLS terminator must be linked against a crypto library that knows the group. Concretely, one of:

• Path 1 (preferred): OpenSSL 3.5+. Build or install nginx linked against OpenSSL 3.5 or newer. The group is then built in. This is the clean long-term path.
• Path 2 (bridge): OpenSSL 3.x + oqs-provider. Keep the existing OpenSSL, add the oqsprovider module via openssl.cnf, which registers X25519MLKEM768 as an available group. This avoids rebuilding the base TLS stack but adds an out-of-tree provider dependency.

The Aere RPC boxes run Ubuntu 24.04, whose default OpenSSL is in the 3.0.x series and therefore does not know X25519MLKEM768 out of the box. So Part A is honestly "a build/packaging step, then configuration," not "one line and reload." The exact OpenSSL version currently linked into nginx on the infra box and on rpc2 is [VERIFY] (run nginx -V and openssl version on each), which decides Path 1 vs Path 2.

Once the terminator understands the group, everything after is configuration.

4.3 nginx configuration

nginx exposes the TLS 1.3 key-exchange group list through the ssl_ecdh_curve directive (which maps to OpenSSL's group-list API). The change is to prepend the hybrid group ahead of the classical ones, so it is preferred when the client offers it and the classical groups remain as fallback:

server {
    listen 443 ssl;
    http2 on;
    server_name rpc.aere.network;

    # Post-quantum hybrid first, classical groups retained as fallback.
    ssl_ecdh_curve   X25519MLKEM768:X25519:secp256r1;

    ssl_protocols    TLSv1.3 TLSv1.2;
    ssl_certificate     /etc/letsencrypt/live/rpc.aere.network/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/rpc.aere.network/privkey.pem;

    # ... existing reverse-proxy to 127.0.0.1:8545, CORS handling,
    #     rate limiting, HSTS, host allowlist as already deployed ...
}

Notes that keep this honest and safe:

• The hybrid group applies to TLS 1.3 key exchange. TLS 1.2 remains classical; that is acceptable because modern RPC clients negotiate TLS 1.3, and TLS 1.2 stays only as a compatibility floor.
• Ordering the list with the hybrid first means a capable client (Chrome/BoringSSL, OpenSSL 3.5 clients, recent ethers/viem runtimes on a modern Node/OpenSSL) gets the PQ group, and an old client that does not offer it falls back to X25519 with no handshake failure. There is no flag day for clients.
• The server certificate is unchanged and still classical (the existing Let's Encrypt RSA/ECDSA cert). This is deliberate and correct for the HNDL threat (Section 2): the KEM protects session confidentiality; PQ certificate authentication is a separate, later concern (Section 6).
• Whether the specific nginx build in production honors X25519MLKEM768 via ssl_ecdh_curve (versus needing a newer nginx that passes the group list straight through to OpenSSL 3.5) is [VERIFY] against the actual nginx -V on the boxes.

4.4 How a client verifies the negotiated group

The point of the change is only real if a client can confirm the PQ group was actually used. With OpenSSL 3.5:

openssl s_client -connect rpc.aere.network:443 -groups X25519MLKEM768 </dev/null 2>/dev/null \
  | grep -i "Negotiated TLS1.3 group"
# expected: Negotiated TLS1.3 group: X25519MLKEM768

Other independent checks:

• Chrome DevTools, Security panel, shows the key-exchange group for the connection.
• A negative control: openssl s_client ... -groups X25519 should still connect (classical fallback works), proving the change is additive and not breaking.

A published verification snippet like the above belongs on the "verify yourself" page (quantum.html) so that the claim "Aere RPC negotiates post-quantum TLS" is independently checkable rather than asserted.

4.5 Backward compatibility and failure modes

• Old clients: unaffected. They never offer the hybrid group and negotiate X25519 as today.
• New clients: get the hybrid group automatically.
• Handshake size: ML-KEM-768 key shares are larger than an X25519 share (roughly a kilobyte-scale ClientHello key share versus 32 bytes). This is well within TLS limits and is the same overhead Chrome already ships to the whole web; it is a non-issue for RPC. Worth a one-time latency spot check after enablement, marked [MEASURE].
• Rollback: revert one directive (ssl_ecdh_curve) and reload nginx. There is no chain state involved, no consensus impact, and no persistent change. This is as low a blast radius as an infra change gets.

4.6 What Part A does and does not protect

• Protects: the confidentiality of RPC session traffic against HNDL. This is the genuinely valuable case, because RPC sessions can carry things whose confidentiality matters, for example the linkage between a client IP and the set of addresses it queries (eth_getBalance, eth_call targets), pending transactions submitted via eth_sendRawTransaction before they are public, and query patterns that deanonymize a user. Recorded today, those are exactly the sessions an HNDL adversary would want to decrypt later.
• Does not protect: on-chain data itself (it is public by design), nor the integrity or authenticity of the RPC response (that is TLS authentication plus, for the truly careful, client-side verification against block hashes). It also does not defend an active quantum MITM at connection time (PQ authentication, out of scope, Section 6).

4.7 Status

Not live. This is a straightforward enablement gated only on the build prerequisite (Section 4.2) and a founder go for touching the public RPC terminators. It carries no consensus risk and is fully reversible. It is the right first move (Section 7).

---

5. Part B: post-quantum devp2p / RLPx between nodes (the real-engineering part)

Effort: high. This is protocol engineering inside the client networking stack, not configuration. Status: roadmap. Implementation and interop are [MEASURE].

5.1 What RLPx does today

Node-to-node links use RLPx, the encrypted transport beneath devp2p. Its handshake is not TLS and shares none of TLS's tooling. In outline, as implemented in the Ethereum clients Aere runs (Besu on the validators and infra, Nethermind as the second client):

1. The initiator sends an auth message; the recipient replies with an ack.
2. Both are encrypted with ECIES over secp256k1 (the same curve Ethereum uses for account keys). Each side contributes an ephemeral secp256k1 key; an ECDH between the ephemeral keys, mixed with the static node keys and nonces, derives the session secrets.
3. From that shared secret the session derives AES-256 frame-encryption keys and MAC keys, and all subsequent devp2p frames (block and transaction gossip, discovery, sub-protocol messages) ride that symmetric session.

As with TLS, the symmetric layer (AES-256) is quantum-fine. The Shor-vulnerable part is the secp256k1 ECDH key agreement inside the ECIES handshake. That is the single thing that has to change.

5.2 What making it post-quantum requires

The move is conceptually the same as Part A, hybridize the key agreement, but there is no switch to flip. It requires patching the client's RLPx handshake to run a hybrid KEM (for example X25519 or secp256k1 ephemeral ECDH plus ML-KEM-768) and to feed the combined secret into the existing key-derivation step. Concretely that means, in each client:

• Extending the auth/ack handshake messages to carry an ML-KEM encapsulation alongside the existing ephemeral public key, without breaking the RLP encoding that stock peers expect.
• Mixing the ML-KEM shared secret into the KDF that currently derives the AES/MAC keys from the ECDH secret alone.
• A capability negotiation so a hybrid-capable node and a stock node can still connect: the patched node must detect whether the peer understands the extended handshake and cleanly fall back to classical RLPx if not. Without this, turning on PQ RLPx would partition the node from every peer that has not upgraded, which on a live validator set is a liveness hazard, not just an inconvenience.

This lives in the networking internals of two independent codebases, Besu (Java, the p2p.rlpx handshake path) and Nethermind (.NET, its RLPx handshake service). The exact class and method surfaces to modify in each are [VERIFY] against the pinned client versions Aere builds, and are deliberately not asserted here to avoid inventing detail.

5.3 Why this is real engineering, not config

• No standards-track PQ RLPx exists. Unlike X25519MLKEM768 for TLS, there is no ratified "PQ RLPx" named suite shipping in the upstream clients. Whatever Aere builds is either a bespoke extension or a proposal that has to be driven upstream (a natural candidate for the open AIP/EIP process rather than a private, proprietary variant).
• It is a two-client, coordinated change. Because Aere deliberately runs client diversity (Besu plus Nethermind), a hybrid RLPx must be implemented compatibly in both, or the two clients stop peering, which would break the very diversity property it is meant to strengthen. That is a cross-codebase protocol-compatibility problem, the hardest kind.
• It touches the live peer graph. Rolling it across a running validator set has to be done behind negotiation and fallback (Section 5.2) and soaked on a testnet first, exactly the caution the fault-injection and cross-client-determinism work exists to provide. This is roadmap-grade change management, not a config reload.

5.4 An honest note on how much this buys today

The confidentiality value of PQ RLPx is smaller today than PQ RPC-TLS, and this document says so plainly. Most of what crosses devp2p on a public blockchain is public data: blocks and transactions that are, by design, broadcast to everyone and land on-chain in cleartext seconds later. Recording that traffic under HNDL yields information the adversary can already read from the chain.

The parts of devp2p traffic that are genuinely confidential are narrower: the peer topology and timing (who connects to whom, useful for eclipse/deanonymization work), and crucially any future private payload that rides the p2p layer. That second category is where the value grows sharply: if Aere ships a threshold-encrypted mempool (roadmap item, anti-MEV), then pre-ordering transaction contents would flow encrypted over devp2p, and HNDL protection on that channel becomes materially important. So the honest sequencing is: PQ RLPx is the correct long-term completion of layer 12, but its urgency is lower than PQ RPC-TLS now and rises with encrypted-mempool / private-flow features later. It should be built deliberately, not rushed ahead of the RPC win.

5.5 Status

Roadmap. Design as above; implementation, cross-client interop, negotiation/fallback behavior, and testnet soak results are all [MEASURE] (none performed yet). This is real client-networking engineering and should be scoped and gated as such (founder go, plus the same testnet-soak discipline used for other consensus-adjacent changes).

---

6. Scope boundaries (stated plainly)

These boundaries are load-bearing. Read them literally.

1. Transport confidentiality only. This entire document is about protecting the confidentiality of data in transit against harvest-now-decrypt-later. It is not about authentication, not about integrity beyond what the existing channels already provide, and not about anything on-chain.

2. Consensus is untouched and stays classical. Aere consensus remains classical ECDSA QBFT. Nothing in this document changes how blocks are proposed, sealed, or finalized. PQ transport and PQ consensus are different layers (12 versus 2); the consensus flip is a separate, higher-risk, founder-and-audit-gated item and is not in scope here.

3. The PQC signature/account layer is separate and already live. Aere's live post-quantum signature verification and PQC accounts (layer 1, the AerePQC fork) are a different mechanism from transport key exchange. This document neither depends on nor modifies them. A wallet can use a PQC account over classical TLS today, and will be able to use an ECDSA account over PQ TLS after Part A; the two are orthogonal.

4. Post-quantum secure messaging is UMBRA's domain, not Aere's transport work. End-to-end encrypted application messaging (a user messaging another user with metadata privacy and PQ E2EE) is the province of UMBRA, a separate project with its own PQXDH-based message path. It is explicitly not part of Aere's transport layer and must not be conflated with it. Aere layer 12 secures the pipes between nodes and between clients and RPC endpoints; UMBRA secures messages between people. They are different systems solving different problems. Do not merge the narratives.

5. PQ authentication of the channel is a later, separate concern. Hybridizing the KEM defends confidentiality (the HNDL threat). Post-quantum authentication of the channel (PQ TLS certificates, PQ handshake signatures, PQ node identities on RLPx) defends against an active quantum adversary impersonating an endpoint at connection time. That is a distinct threat on a longer horizon and is out of scope for this document, which is deliberately about confidentiality first.

6. Nothing here is live. RPC PQ-TLS is a straightforward enablement pending a build step (Section 4.2). devp2p PQ is real engineering on the roadmap. Neither is deployed.

---

7. Rollout plan

Two phases, sequenced by the effort/value split this document has argued for.

Phase 1: PQ TLS on the public RPC (do first). Low effort, immediate and real HNDL protection for the largest and most sensitive transport surface (wallets and clients talking to rpc.aere.network and rpc2.aere.network). Steps:

1. [VERIFY] the OpenSSL version linked into nginx on infra and on rpc2 (nginx -V, openssl version); choose Path 1 (OpenSSL 3.5+) or Path 2 (oqs-provider).
2. Stage the build on one endpoint first. rpc2 is the natural canary: it is the newer, independent, non-validator box, so a mistake there cannot affect validators and the primary RPC stays up.
3. Add ssl_ecdh_curve X25519MLKEM768:X25519:secp256r1;, nginx -t, reload.
4. Confirm negotiation with the client check in Section 4.4; confirm classical fallback still works (negative control).
5. [MEASURE] a one-time handshake-latency delta.
6. Publish the verification snippet on quantum.html so the claim is independently checkable.
7. Roll the same change to the primary RPC. Rollback is one directive.

Phase 2: PQ devp2p / RLPx (roadmap, after Phase 1). High effort, real cross-client protocol engineering, lower present-day urgency (Section 5.4). Steps, all gated and none started:

1. Design the hybrid-KEM RLPx handshake extension with explicit capability negotiation and classical fallback; take it through the open AIP/EIP process rather than shipping a proprietary variant.
2. Implement compatibly in both Besu and Nethermind; verify hybrid-capable and stock peers interoperate.
3. Soak on an isolated testnet under the existing fault-injection and cross-client determinism harnesses.
4. Roll across the validator set behind negotiation/fallback, founder-gated, with the same change-management discipline as other consensus-adjacent work.
5. Reassess priority upward if/when a threshold-encrypted mempool or other private p2p payload lands, at which point PQ RLPx stops being topology-only protection and starts guarding genuinely confidential flow.

Completing both phases closes layer 12 of the quantum stack.

---

8. Open flags register

Flag	Item
[VERIFY]	Exact OpenSSL version currently linked into nginx on the infra RPC box and on rpc2 (decides OpenSSL-3.5 path vs oqs-provider path).
[VERIFY]	Whether the production nginx build honors X25519MLKEM768 through ssl_ecdh_curve, or requires a newer nginx passing the group list to OpenSSL 3.5.
[VERIFY]	Exact RLPx handshake class/method surfaces to modify in Besu (Java p2p.rlpx) and Nethermind (.NET RLPx handshake) against the pinned client versions Aere builds.
[MEASURE]	One-time TLS handshake-latency delta on the RPC endpoints after enabling the hybrid group.
[MEASURE]	devp2p PQ: implementation, Besu/Nethermind interop, negotiation/fallback behavior, and testnet soak results (none performed yet).

---

Aere Network. Spec #30, Wave 1. Transport-confidentiality design. Consensus stays classical ECDSA QBFT; PQ signatures/accounts are a separate, live layer; application messaging is UMBRA's separate domain. Nothing in this document is live.