Post-quantum OpenVPN

Table of contents

  1. Introduction/TLDR
  2. The new OpenVPN Instances
  3. A brief overview of OpenVPN encryption
  4. Caveats
  5. ML-DSA-87
  6. AES-256-GCM: Post-Quantum Safety Margins
  7. Precompiled OpenVPN binaries

Introduction/TLDR

We added ML-DSA-87 (post-quantum) OpenVPN instances to the network. Our latest Windows client (widget v3.64) includes support for ML-DSA-87 under
Options -> Security -> TLS cipher. The client configs for these instances are now on the OpenVPN config generator page, and available directly from here and on GitHub.

You must have OpenSSL 3.5.0 installed to connect to these OpenVPN instances.
Both UDP and TCP are supported, same as the other instances, but
these new instances only work on port 5063.

The new OpenVPN Instances

At the end of our port striping v3 post we mentioned keeping an eye on OpenSSL 3.5.0 because it included support for post-quantum algorithms like ML-KEM, SLH-DSA, and ML-DSA (a.k.a. Dilithium). OpenVPN doesn't natively support these algorithms yet, but most of OpenVPN's TLS certificate processing gets handed over to OpenSSL, so as long as the client and server both have OpenSSL 3.5.0, post-quantum cryptographic algorithms can be used (for TLS authentication). We spun up a few test OpenVPN instances when OpenSSL 3.5.0 was still in beta, and our assumption that we could use something like ML-DSA-87 for the TLS certificates was correct.

Halfway through migrating the servers to port striping v3, the stable version of OpenSSL 3.5.0 came out (April 8, 2025), so we went back to the migrated servers and added these new ML-DSA-87 instances, then continued migrated the remaining servers, but this time also including these new instances.

The port striping v3 migration was finished on April 18, 2025, so the ML-DSA-87 instances have been running since then, we just haven't announced it yet so we could do more testing (and write this article). Everything seems to be working as expected, so we're announcing them now.

A brief overview of OpenVPN encryption

OpenVPN secures the VPN tunnel using four key mechanisms:

  1. Authentication – The CA certificate (between <ca> and </ca> in the configs) is used by the client to verify the server's identity, which stops an attacker from impersonating the server during a man-in-the-middle attack.

  2. Key Exchange – The --tls-cipher setting uses asymmetric encryption (TLS) to exchange the ephemeral (temporary) symmetric keys that actually encrypt your traffic. OpenVPN refers to this as the "control channel".

  3. Control Channel Protection – With --tls-crypt or --tls-crypt-v2, the TLS handshake is encrypted (and authenticated) using a pre-shared key, which protects against tampering with the control channel (and some passive surveillance).

  4. Encryption – The --cipher or --data-ciphers setting defines the symmetric algorithm (e.g., AES-256-GCM) for encrypting traffic. OpenVPN refers to this as the "data channel". These symmetric keys are rotated every 20 minutes for forward secrecy, using the control channel.

Caveats

In these new ML-DSA-87 OpenVPN instances, only authentication is post-quantum. The key exchange and encryption still rely on classical algorithms:

  • Key Exchange: TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384 (or TLS_AES_256_GCM_SHA384 in TLS 1.3) uses ECDHE (Elliptic Curve Diffie-Hellman Ephemeral), which is not quantum-resistant. However, people using --tls-crypt-v2 would be using a strong AES 256-bit pre-shared key that does provide an extra layer of protection against a quantum attacker trying to target the handshake. --tls-crypt (v1) doesn't help that much in this regard since in v1 everyone shares the same key.

  • Encryption: AES-256-GCM is considered quantum-resistant—but only against Grover’s algorithm, which halves the effective key strength (AES-256 → ~128-bit security in a quantum context).

For true post-quantum security, the key exchange would also need a PQC algorithm (like ML-KEM). We will have to wait for OpenVPN to officially add support for those before we can use them. For now, AES-256 remains a robust choice for encryption.

 

ML-DSA-87

ML-DSA-87 is a NIST Level 5 post-quantum digital signature algorithm based on lattice cryptography. Specifically, it's derived from CRYSTALS-Dilithium, and relies on the Module Learning With Errors (MLWE) problem. It offers strong resistance against both classical and quantum attacks, with an estimated 256-bit classical security level.

Compared to traditional schemes:

Algorithm       Classical Security
─────────────── ───────────────────
Ed25519         ≈ 128-bit
RSA-8192        ≈ ~170-bit
Ed448           ≈ 224-bit
secp521r1       ≈ 256-bit
ML-DSA-87       ≈ 256-bit + post-quantum

It's basically the best available option at the moment, so we picked it for these new instances.

 

AES-256-GCM: Post-Quantum Safety Margins

Unlike the other instances, these new ML-DSA-87 instances do not use ChaCha20-Poly1305. While both AES-256 and ChaCha20-Poly1305 currently provide 128-bit security against quantum attacks via Grover's algorithm, we've chosen only AES-256-GCM for these post-quantum instances due to fundamental differences in their cryptographic safety margins:

1. The Grover's Algorithm Ceiling

  • Both ciphers face the same theoretical quantum attack limit: Grover's algorithm can square root the effective security, reducing:

    • AES-256's classical 256-bit key to ~128-bit quantum security

    • ChaCha20's 256-bit key to the same ~128-bit quantum security

  • But this is where the similarities end - implementation details create different safety profiles

2. Structural Safety Margins

AES-256-GCM maintains several conservative design choices that may prove valuable against future cryptanalysis:

  • Fixed 128-bit block size (vs ChaCha20's 512-bit state):

    • Forces attackers to work with smaller, more constrained cryptographic primitives

    • Provides cleaner security proofs against quantum linear algebra attacks

  • Mathematically rigid substitution-permutation network:

    • 30+ years of intensive study reveals no significant shortcuts

    • Post-quantum analysis shows particularly robust resistance to amplitude amplification attacks

3. The ChaCha20 Tradeoff

While ChaCha20's larger 512-bit internal state offers advantages in some scenarios:

  • Its ARX (Add-Rotate-XOR) design has:

    • Less formal security analysis against quantum attacks

    • Potential vulnerability to future quantum-assisted differential cryptanalysis

  • The extended state size doesn't directly translate to higher security against quantum search

4. Why Margin Matters Now

We're enforcing AES-256-GCM because:

  • Post-quantum security requires planning for unknown attacks beyond Grover's

  • AES provides:

    • Better-studied resistance to quantum algebraic attacks

    • More conservative security reductions

    • A track record of resisting decades of advanced cryptanalysis

  • This matches NIST's conservative approach in their PQ standardization process

 

Precompiled OpenVPN Binaries

These are for Linux and Windows users who want to use these new ML-DSA-87 instances but can't install OpenSSL 3.5.0 for whatever reason. The Linux OpenVPN binary was built against a static OpenSSL 3.5.0, meaning you can use it without having OpenSSL 3.5.0 installed (though 64-bit Linux is required). It was built with musl in a Docker running an older Alpine Linux, so it should run on older Linux distros (~2018 to now). The Windows openvpn.exe was also compiled against a static OpenSSL, and it also requires a 64-bit Windows. These two binaries are OpenVPN 2.6.14 (the latest as of this post).

Linux: https://cryptostorm.is/bin/openvpn.bin [sig]

Windows: https://cryptostorm.is/bin/openvpn.exe [sig]

For OpenVPN GUI on Windows, replacing the above openvpn.exe with the one in your
C:\Program Files\OpenVPN\bin\ folder should get you on OpenVPN 2.6.14 + OpenSSL 3.5.0, but if for whatever reason you don't want to upgrade your OpenVPN, you can instead place these two .dll files in C:\Program Files\OpenVPN\bin\ and your existing openvpn.exe will use them, which will get you on OpenSSL 3.5.0 so that you can use these ML-DSA-87 instances (Your existing OpenVPN has to be newer than 2.4.3).

https://cryptostorm.is/bin/libcrypto-3-x64.dll [sig]
https://cryptostorm.is/bin/libssl-3-x64.dll [sig]

Posted on