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 looks the key’s fingerprint up through the API to confirm the key is registered and active.
3. The server sends back a random challenge.
4. The client signs the challenge, bound to this protocol, using its ML-DSA-87 private key.
5. The server verifies the signature against the public key the client presented in step 1.

Because the signed message is bound to this protocol, a signature produced here cannot be replayed or reused against a different protocol that also asks a client to sign a challenge.

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.

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 shared secret, from which the WireGuard pre-shared key is derived. 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 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.