Table of contents
Introduction/TLDR
In our post-quantum OpenVPN post, we said:
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.
OpenVPN added PQC support in version 2.7.0, so if you have that (or newer) and OpenSSL 3.5.0 (or newer) then a hybrid post-quantum TLS key exchange will be used when you connect to cryptostorm. That means the gap mentioned in the older post is closed for clients using a recent enough OpenVPN/OpenSSL.
You can see it in the OpenVPN log at:
Control Channel: TLSv1.3, cipher TLSv1.3 TLS_CHACHA20_POLY1305_SHA256, peer certificate: 521 bits ECsecp521r1, signature: ecdsa-with-SHA512, peer signing digest/type: ecdsa_secp521r1_sha512 ECDSA, key agreement: X25519MLKEM768
That X25519MLKEM768 part means the TLS key exchange is using a hybrid of the classical X25519 ECDH algorithm and the post-quantum ML-KEM-768 algorithm.
The short version is: our ML-DSA-87 OpenVPN instances now have post-quantum authentication and a post-quantum hybrid key exchange. The secp521r1, Ed25519, Ed448, and RSA instances can also use the same hybrid key exchange when the client's OpenVPN/OpenSSL is new enough, though their certificate/authentication side is still whatever that instance uses.
Post-quantum key exchanges in OpenVPN
The previous post-quantum OpenVPN post was mostly about ML-DSA-87 certificates. That was useful because it meant the server authentication side could use a post-quantum signature algorithm, but the TLS key exchange was still classical.
OpenSSL 3.5 added support for PQC algorithms like ML-KEM, ML-DSA, and SLH-DSA, and its default TLS keyshares include X25519MLKEM768. OpenVPN 2.7.x can make use of that when it is built against a new enough OpenSSL.
That matters because the key exchange is the part that agrees on the temporary symmetric keys used for the VPN session. With X25519MLKEM768, an attacker would have to break both sides of the hybrid agreement to recover the key exchange: the classical X25519 side and the ML-KEM-768 side.
The data channel is still encrypted with normal symmetric ciphers like AES-256-GCM or ChaCha20-Poly1305, depending on the instance/client settings. That is fine; post-quantum VPN work is mostly about replacing the asymmetric parts first, because those are the parts Shor's algorithm threatens. AES-256 still has a large security margin even in the usual Grover's algorithm discussion.
Windows client v4
We also rewrote our Windows client.
The old "widget" did its job for a long time, but it started as a single Perl script and slowly accumulated years of fixes, feature additions, Windows compatibility workarounds, and UI tweaks. The new one is still Perl/Tkx, but the code has been split into smaller modules and most of the client-side logic was rewritten.
The visible changes are the ones most users will care about:
- newer server selection UI;
- newer OpenVPN/OpenSSL builds, so the client can use the hybrid post-quantum key exchange described above;
- Xray/REALITY support, so OpenVPN UDP or TCP can be wrapped in something that looks much closer to normal HTTPS traffic;
- the stunnel HTTPS and SSH tunneling are still there for networks where those work better;
- better TAP adapter handling, and updated TAP drivers for Windows 7 and newer Windows systems;
- a more careful killswitch and IPv6 leak-blocking path;
- no more bundled DNSCrypt since the client doesn't use DNS anymore;
- DNS leak protection, ad-blocking DNS, and TunnelCrack protection options;
- more translations (English, Japanese, Swedish, Italian, Russian, Chinese, Persian, Arabic, German, French, Dutch, Finnish, and Spanish) and a new language selection UI on the main window;
- post-connect checks for client updates and server-list updates.
Xray is probably the biggest transport change. Our older HTTPS obfuscation used stunnel, which works for TCP OpenVPN but doesn't help with UDP OpenVPN or WireGuard. Xray/REALITY can carry UDP or TCP payloads through a TLS-looking outer connection, which makes it a better fit for the current network setup described in the Xray post.
This client currently uses the latest OpenVPN TAP drivers. DCO support, and possibly WireGuard support, will come later. For now the goal was to get the new OpenVPN/OpenSSL/Xray stack working across the widest set of Windows systems we still care about, including Windows 7 32-bit.
The Windows client download is at https://cryptostorm.is/windows#widget.
The source code is at https://github.com/cryptostorm/cstorm_widget.