Tunneling

WireGuard as the transport

Once a client has authenticated to a server (see Post-Quantum Cryptography), EON Path’s routing method brings up a standard WireGuard tunnel to carry traffic. WireGuard was chosen because it is a small, well-audited VPN protocol with a compact wire format, low connection latency, and consistently good throughput compared to older VPN protocols such as OpenVPN or IPsec. Packets on the tunnel are encrypted with ChaCha20-Poly1305, and the tunnel itself behaves like any other WireGuard interface: it can be inspected with standard WireGuard tooling, and its keepalive, MTU, and allowed-IP settings follow WireGuard’s usual configuration model.

Keying the tunnel from an authenticated exchange

WireGuard’s own key exchange is a classical X25519 Diffie-Hellman handshake. EON Path does not replace that handshake, but it strengthens the tunnel’s key material by deriving a pre-shared key (PSK) from the post-quantum key exchange performed during authentication, and configuring WireGuard to mix that PSK into its own key derivation. Concretely:

1. The client and server complete the ML-DSA-87 challenge-response authentication and ML-KEM-1024 key encapsulation described in Post-Quantum Cryptography.
2. Both sides derive the same shared secret from the ML-KEM-1024 decapsulation and hash it, with a domain separator, into a 256-bit WireGuard PSK.
3. The client and server then exchange their WireGuard (X25519) public keys over the same authenticated channel.
4. The server sends the client its tunnel configuration (addresses, subnet, MTU, keepalive) and both sides configure a WireGuard peer using the exchanged public keys and the post-quantum-derived PSK.
5. The WireGuard tunnel comes up using that peer configuration.

Because the PSK step happens over a channel that has already authenticated both parties with post-quantum signatures, an attacker who could eventually break WireGuard’s classical X25519 exchange would still need the post-quantum-derived PSK to decrypt tunnel traffic — the tunnel’s confidentiality does not rest on a single classical assumption.

Multi-server clients

Desktop and mobile clients can be configured with more than one server endpoint and switch between them, rather than being tied to a single hard-coded server. At the protocol level, EON Path’s WireGuard configuration model is built around a list of peer configurations rather than a single fixed peer, which is what makes it possible for a client to hold tunnel configuration for more than one server at a time.

What this doesn’t change

EON Path’s post-quantum handshake governs how a tunnel gets set up and keyed — it does not change WireGuard’s packet format or the way encrypted traffic looks on the wire. This keeps EON Path’s routing method compatible with standard WireGuard operational practices (monitoring, wg show, keepalive tuning) once a tunnel is established.