Post-quantum networking for Minerva nodes (design, no code yet)

Status: design for review. Nothing in this document is implemented; the devp2p stack is upstream CoreGeth (secp256k1 node keys, RLPx with ECDH over secp256k1, discovery v4/v5). The account layer is already post-quantum; this is the plan for the transport and node identity, kept separate because it is a protocol change for every client and must not block the account layer.

1. What is at risk and what is not

Surface	Today	ECDSA/ECDH break
Account authorization	ML-DSA-65 native transactions, registry-enforced	unaffected
Block ordering	Proof-of-Work	unaffected (hash based)
Node identity (enode id)	secp256k1 public key	an attacker can impersonate a bootnode or a known peer
Transport confidentiality	RLPx ECDH over secp256k1, AES/MAC	a recorded session can be decrypted later (harvest now, decrypt later)
Discovery records (ENR)	secp256k1 signatures	forged records, eclipse attacks become cheaper

Consequences of a break on the network layer are eclipse and censorship, not theft: funds still need ML-DSA signatures. That ordering sets the priority: account layer first (done), transport second.

2. Node identity: ML-DSA-65 node certificates

• Each node generates an ML-DSA-65 key pair (minerva-geth nodecert new), kept next to the secp256k1 node key. The certificate is MINERVA_NODE_CERT_V1 || chainId || enodeId (secp256k1 pubkey) || notBefore || notAfter || mldsaPublicKey signed with the ML-DSA key over the whole record (context MINERVA_NODE_CERT_V1).
• Binding the secp256k1 enode id into a PQ-signed record means a peer that proves possession of the ML-DSA key during the handshake (section 3) has also claimed that enode id; forging the secp256k1 key alone does not let an attacker present someone else's identity.
• Bootnode operators publish enode://... plus the certificate hash in bootnodes.json (nodeCertHash); the launch material generator fills it once the command exists.
• Certificates are short lived (90 days) and rotated with the same tooling; no revocation list, expiry does the job.

3. Handshake: minerva/1 capability

RLPx hello already negotiates capabilities. minerva/1 adds two messages right after hello:

1. CertExchange { cert, nonce }: each side sends its certificate and a fresh 32-byte nonce.
2. CertProof { signature }: ML-DSA-65 signature over peerNonce || ownNonce || rlpxSessionSecretHash (context MINERVA_NODE_PROOF_V1). Binding the RLPx session secret hash into the proof ties the PQ identity to this particular transport session, so a certificate cannot be replayed on another connection.

Peer policy per fork block minervaNodeIdentity (new chain-config field, same mechanism as the account forks):

• before: optional; nodes record which peers proved a certificate (admin_peers shows it);
• after: a peer without a valid proof is disconnected within the handshake; bootnodes are required to have proved certificates before their ENRs are trusted.

Size: certificate about 2.1 KB, proof 3.3 KB, once per connection. Negligible against block propagation.

4. Transport: hybrid key agreement

RLPx's auth/ack run ECDH on secp256k1. The upgrade adds ML-KEM-768 (FIPS 203):

• auth carries an ML-KEM-768 encapsulation key (1,184 bytes) in a new field;
• ack carries the ciphertext (1,088 bytes);
• session keys are derived as KDF(ecdhSecret || mlkemSharedSecret), so the session is secure as long as either primitive holds (hybrid, as in TLS 1.3 X25519MLKEM768).

Same fork-block gate; before activation a node that does not send the field gets a classical session, after activation the field is required. Discovery packets stay classical for now (ENR signatures are 64 bytes; an ML-DSA ENR is a separate proposal), which is why node identity is proved in-band in section 3 rather than through ENRs.

5. Tooling and operations

• minerva-geth nodecert new|show|rotate; minerva doctor gains a node-identity check (certificate present, not expired, matches the enode id).
• minerva_networkInfo reports the identity and transport activation blocks.
• Operators publish certificate hashes with the release (signed SHA256SUMS covers the manifest).

6. Rollout

1. Prototype minerva/1 on the devnet behind --minerva.nodeidentity=optional; no consensus change (handshake only).
2. Hybrid key agreement on the devnet; measure handshake latency and failure rates.
3. Testnet: optional for one release, then required at a published fork block.
4. Mainnet genesis: both active from block 0 if the testnet run is clean.

7. Open questions for review

• Whether to carry the ML-DSA public key in the ENR (v5 record size limit is 300 bytes; it does not fit) or keep the in-band proof only: this design keeps it in-band.
• ML-KEM key reuse: fresh per connection (simplest, 1 keygen per dial) or cached per hour.
• Interaction with the Engine API and light clients: out of scope; Minerva runs PoW with full nodes only.