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:

```nginx
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:

```bash
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.*