Security Model

Threat model

EON Path’s routing method is designed to resist the following threats:

Out of scope

Some threats are explicitly out of scope for EON Path’s own security controls, and are the operator’s or user’s responsibility instead:

• Physical access to a client or server endpoint
• A compromised operating system on either end of the connection
• Side-channel attacks against the underlying cryptographic implementations
• Denial-of-service attacks beyond basic per-IP rate limiting

Authentication: ML-DSA-87 challenge-response

Clients authenticate to the server with an ML-DSA-87 public-key challenge-response protocol: the client presents its public key, the server checks it against the management API, issues a random challenge, and the client proves possession of the matching private key by signing that challenge. There is no password or bearer token involved in the VPN handshake itself, so there is no such secret in transit and nothing of that kind to steal or replay. See Post-Quantum Cryptography for the full protocol walkthrough.

Mandatory server identity pinning

Authenticating the client is only half of the handshake — the client also needs to know it is talking to the genuine server before it trusts that server’s key material. EON Path makes this check mandatory rather than optional: before deriving any tunnel key material, the client verifies the server’s ML-DSA-87 identity against either a pinned fingerprint hash configured for that endpoint, or a DNS TXT record published for the server’s domain. If neither is configured, or the identity presented does not match, the client refuses to proceed — it fails closed rather than falling back to an unauthenticated connection. This closes off a class of attacks where an adversary who controls the network path, or who can otherwise get in front of a client’s connection attempt, presents their own key instead of the real server’s.

Transcript binding

The handshake does not stop at authenticating the client and verifying the server’s identity. The final WireGuard pre-shared key is derived from the post-quantum key exchange’s shared secret combined with a hash of the entire handshake transcript up to that point — every message exchanged during authentication and key exchange feeds into the value both sides use to compute their key. If an attacker were to tamper with, reorder, or substitute any earlier message in the exchange, the two sides would derive different pre-shared keys and the resulting WireGuard tunnel simply would not come up, rather than silently succeeding with attacker-influenced key material.

Transport security: WireGuard

Once the handshake completes, traffic flows over a standard WireGuard tunnel. WireGuard’s own handshake and transport are built on the Noise protocol framework, and packets are encrypted with ChaCha20-Poly1305. EON Path does not modify WireGuard’s wire format or packet handling; it strengthens the tunnel’s key material by feeding the post-quantum-derived pre-shared key into WireGuard’s own key derivation alongside its native X25519 exchange, so an attacker would need to defeat both the classical and the post-quantum contribution to recover tunnel traffic. See Tunneling for how the two are combined.

Key management principles

• No long-lived shared secrets for tunnel traffic. Every session derives a fresh WireGuard pre-shared key from a fresh ML-KEM-1024 exchange; keys are not reused across sessions.
• Server identity keys are generated automatically. A server’s ML-DSA-87 identity key pair is created the first time the server daemon starts, removing a manual key-provisioning step that could otherwise be skipped or done insecurely.
• Client keys stay with the client. A client’s ML-DSA-87 private key is generated and kept on the client; only the corresponding public key is registered with the management API.
• Revocation is supported, not just registration. A registered public key can be marked as revoked through the management API, after which the server will no longer complete a handshake for that key.
• Credentials for the management API are never stored in plaintext. Account passwords and API keys are hashed before storage; comparisons use constant-time checks to avoid leaking timing information.

A separate surface: the management API

The threats and mitigations above cover the VPN authentication protocol. The management API is a distinct system with its own authentication (username/password login, JWT-based bearer tokens with expiration) used for account operations — registering keys, requesting IP leases, and similar account management. It is not part of the VPN handshake’s trust path beyond the single fingerprint lookup described above. See API for how the two surfaces relate.

Reporting a vulnerability

If you believe you’ve found a security vulnerability in EON Path, please report it to security@eoncore.eu. Include:

• A description of the vulnerability and its potential impact
• Steps to reproduce it
• A suggested fix, if you have one

Please report vulnerabilities privately and give us a reasonable amount of time to address the issue before any public disclosure.