Post-Quantum Cryptography

Why post-quantum cryptography

Large-scale quantum computers, if built, would break the classical public-key cryptography (RSA, ECDH/ECDSA) that most VPNs and TLS connections rely on today. The risk is not only future: an adversary can record encrypted traffic now and decrypt it later once such a computer exists — a strategy known as “harvest now, decrypt later.” That makes long-lived secrets and long-lived infrastructure worth protecting with post-quantum algorithms today, even before large-scale quantum computers exist.

EON Path uses two NIST-standardized post-quantum algorithms for its VPN routing method: ML-DSA (FIPS 204, digital signatures) for authentication and identity, and ML-KEM (FIPS 203, key encapsulation) for key exchange. Both are specified at their highest standardized security level in EON Path’s authentication protocol: ML-DSA-87 and ML-KEM-1024, corresponding to NIST Level 5.

Authentication: ML-DSA-87 challenge-response

Clients authenticate to the server with an ML-DSA-87 public-key challenge-response protocol, conceptually similar to SSH public-key authentication:

1. The client sends its ML-DSA-87 public key to the server.
2. The server computes a SHA-256 fingerprint of the public key and looks it up through the API to confirm the key is registered and active.
3. The server sends back a 32-byte random challenge nonce.
4. The client signs the nonce, concatenated with a protocol-specific domain separator, using its ML-DSA-87 private key.
5. The server verifies the signature against the public key the client presented in step 1.

The domain separator tied to the signed message prevents a signature produced for this protocol from being replayed or reused against a different protocol that also asks a client to sign a nonce.

This challenge-response exchange replaces password- or bearer-token-based authentication entirely — there is no shared secret in transit and no token that can be stolen and reused. Earlier versions of the VPN routing method authenticated clients to the API using JSON Web Tokens (JWT); as of March 2026, that has been replaced by the ML-DSA-87 challenge-response protocol described above for the VPN connection itself.

Key exchange: ML-KEM-1024

After authentication, the server presents its own ML-DSA-87 identity key together with an ephemeral ML-KEM-1024 public key, signed with its identity key so the client can verify it came from the genuine server. The client encapsulates a shared secret against that ephemeral key and returns the resulting ciphertext. Both sides now hold the same 32-byte shared secret, from which the WireGuard pre-shared key is derived with a domain-separated SHA-256 hash. That derivation also binds the pre-shared key to a hash of the full handshake transcript, so tampering with any earlier message in the exchange produces mismatched keys on the two sides and the handshake fails closed. Because the WireGuard tunnel’s pre-shared key is derived from a post-quantum key encapsulation, the tunnel’s confidentiality does not depend solely on WireGuard’s classical X25519 key exchange.

Server identity pinning

Before trusting a server’s ML-KEM key, the client verifies the server’s ML-DSA-87 identity. EON Path supports two verification methods: a pinned hash, where the endpoint configuration stores the expected SHA-256 hash of the server’s public key directly, and a DNS TXT record lookup, where the client fetches the expected hash from a DNS name configured for that endpoint. Server identity keys are generated automatically the first time the server daemon starts. Identity pinning is mandatory for the routing method: a client will not proceed with a tunnel to a server whose identity it cannot verify, which closes off endpoint impersonation and on-path attacks that rely on presenting a different key than the one the client expects.