FAQ
Why use post-quantum cryptography now, if large quantum computers don’t exist yet?
Because an adversary doesn’t need a quantum computer today to benefit from one in the future. Traffic encrypted with classical algorithms can be recorded now and decrypted later, once a sufficiently powerful quantum computer exists — a strategy known as “harvest now, decrypt later.” For long-lived infrastructure and long-lived secrets, that risk is worth protecting against today rather than waiting. See Post-Quantum Cryptography for the algorithms EON Path uses and why.
Can I connect to an EON Path server with a plain WireGuard client?
No. EON Path’s routing method uses a standard WireGuard tunnel for the data
plane, but getting to that tunnel requires the ML-DSA-87 challenge-response
handshake and mandatory server identity verification described in
Security Model — a plain WireGuard client has no way to
perform that handshake or obtain the resulting pre-shared key. Once the
tunnel is up, though, it behaves like a normal WireGuard interface and can
be inspected with standard WireGuard tooling (wg show, for example).
What’s the performance overhead of the post-quantum handshake?
Very little, and it’s a one-time cost. ML-KEM and ML-DSA are designed to be fast: individual operations (key generation, signing, verification, encapsulation, decapsulation) are measured in microseconds on modern hardware, even at the largest standardized parameter sizes EON Path uses (ML-KEM-1024, ML-DSA-87). That cost is paid once, when a client connects to a server; after the tunnel comes up, traffic is carried by ordinary WireGuard with ChaCha20-Poly1305 encryption, so ongoing throughput and latency are the same as any other WireGuard tunnel. See Post-Quantum Cryptography for the algorithms involved.
Can EON Path be used with an IPv6-only backend network?
Yes. EON Path’s SIIT (stateless IP/ICMP translation) feature lets an IPv4-only client application reach an IPv6-only server-side network without any changes on the client: the client’s TUN device still sees and sends plain IPv4 packets, and SIIT translates them to and from IPv6 immediately before and after they cross the WireGuard tunnel. See Address Translation (SIIT) for how the translation works and when it applies.
What platforms are supported?
The server runs on Debian 11+ and Ubuntu 22.04+ (amd64), packaged as
.deb files. The desktop client supports macOS (Apple Silicon and Intel),
Windows, and Linux. Native iOS and Android apps exist and share the same
authentication and tunnel code as the desktop client; public app-store
availability is pending. See Install for details on each
platform.
What license is EON Path released under?
EON Path is proprietary, commercially licensed software — it is not open source. Use is governed by a commercial license agreement; unauthorized copying, modification, or distribution of the software is not permitted.
How is EON Path different from setting up plain WireGuard myself?
Plain WireGuard leaves key distribution and peer verification up to you: you generate and exchange public keys out of band, and there’s no built-in way to check that the peer you’re configuring is who you think it is. EON Path adds a post-quantum-authenticated handshake in front of WireGuard that automates and hardens that step — clients and servers authenticate each other with ML-DSA-87 signatures, server identity is verified against a pin or DNS record before any key material is trusted, and the WireGuard pre-shared key is derived fresh for each session from an ML-KEM-1024 key exchange rather than being configured once and reused indefinitely. A management API also handles key registration, revocation, and IP-lease assignment, which plain WireGuard has no equivalent for.
What happens if a server’s identity can’t be verified?
The client refuses to connect. Server identity pinning is mandatory for EON Path’s routing method: if an endpoint has no pinned identity hash or DNS TXT record configured, or if the identity presented during the handshake doesn’t match what’s expected, the client fails closed rather than falling back to an unverified connection. See Server identity pinning for details.
Does EON Path support connecting to more than one server?
Yes. Desktop and mobile clients can hold configuration for multiple server endpoints and switch between them, rather than being tied to a single hard-coded server. See Tunneling for how this works at the WireGuard configuration level.
Are the VPN handshake and the management API the same authentication system?
No, and it’s a common point of confusion. The VPN handshake authenticates a client to a server using ML-DSA-87 signatures, with no password or token involved. The management API is a separate REST service with its own username/password login and JWT bearer tokens, used only for account operations like registering keys and requesting IP leases. The two meet at exactly one point: the server looks up a connecting client’s public-key fingerprint through the management API during the handshake. See API for the full picture.
How do I report a security vulnerability?
See Security Model for the disclosure process and contact address.