Architecture

Components

EON Path is split into a small number of independently deployable components:

• Server daemon. Terminates client connections, runs the post-quantum key exchange, and manages the WireGuard tunnel and, where enabled, the IPv4/IPv6 SIIT translation and NAT for internet access.
• API server. A web management service that stores registered public keys and endpoint configuration. During authentication, the server daemon looks up a client’s public key fingerprint against the API to confirm it is registered and active.
• Desktop client. A GUI application (Wails: Go backend, web frontend) that manages one or more server connections, verifies server identity, and drives the tunnel handshake.
• Mobile apps. Android and iOS clients built on the same Go core as the desktop client, sharing the cryptographic identity and key-exchange code so behavior is consistent across platforms.

How they interact

A connection starts as a TCP key-exchange session between a client (desktop or mobile) and the server daemon: the client authenticates itself with an ML-DSA-87 signature, the two sides verify each other’s identity, and they derive a WireGuard pre-shared key from a post-quantum key encapsulation exchange. During authentication, the server daemon calls out to the API server to confirm the client’s public key is registered. Once the handshake completes, the client and server exchange WireGuard public keys and bring up a WireGuard tunnel configured with the derived key material — from that point on, traffic flows over the encrypted tunnel like any other WireGuard session.

    flowchart LR
    subgraph Clients
        D[Desktop client]
        M[Mobile app]
    end

    subgraph Server[Server daemon]
        K[Key-exchange listener]
        W[WireGuard tunnel]
    end

    A[API server]
    N((Internet))

    D -- "ML-DSA-87 challenge-response + ML-KEM-1024 KEX" --> K
    M -- "ML-DSA-87 challenge-response + ML-KEM-1024 KEX" --> K
    K -- "verify key fingerprint" --> A
    K -- "configure peer" --> W
    D <-. "encrypted VPN traffic" .-> W
    M <-. "encrypted VPN traffic" .-> W
    W --> N
  

Two ways to connect

EON Path supports two connection methods. The routing method — the focus of this documentation — brings up a full Layer 3 WireGuard VPN tunnel, keyed through the post-quantum handshake described above, and is available on desktop and mobile clients. An older proxy method tunnels individual application connections through an SSH channel authenticated with the same family of post-quantum key material, exposed to local applications as a SOCKS/HTTP proxy; it is desktop-only and does not provide a full VPN tunnel. Both methods authenticate clients and servers with post-quantum cryptography; this documentation focuses on the routing method, since it is the one used by both desktop and mobile clients and the one that pairs with WireGuard and SIIT.

Where things run

The server daemon and API server are typically deployed together on server-side infrastructure that the desktop and mobile clients connect to over the network — for example a server reachable at vpn.example.com. The API server does not need to be reachable by end users directly; only the server daemon’s key-exchange and WireGuard ports need to be open to clients.