Post-quantum cryptography security in OpenVPN

This is a defense against potential attacks from quantum computing powerful enough to break certain cryptographic algorithms. In general, symmetric ciphers such as AES-GCM and Chacha20-Poly1305 that are used for data-channel encryption, are still safe to use. No change is necessary in this area. The cryptographic algorithms that are affected are the asymmetric algorithms. These are commonly used to establish the symmetric encryption keys for data encryption.

There are three major aspects of post-quantum security in OpenVPN that this article discusses:

1. pre-shared key control security (tls-crypt/tls-crypt-v2)
2. post-quantum key agreement
3. post-quantum signing/certificates

pre-shared key control security (tls-crypt/tls-crypt-v2)

OpenVPN has two channels for communication - the control channel and the data channel. The control channel is where authentication and key agreement occurs, whereas the data channel transports the encrypted payload. The tls-crypt and tls-crypt-v2 options work by using pre-shared symmetric keys to encrypt the whole control channel and the TLS handshake that occurs there. In essence symmetric keys protect the asymmetric part of the process. Often this kind of protection is called "poor man's post-quantum cryptography".

Quoting the man page:

provides "poor-man's" post-quantum security, against attackers who will never know the pre-shared key (i.e. no forward secrecy).

Post-quantum key agreement

The key agreement is what TLS server and client use to agree on a common secret that will be used to derive all encryption keys for the connection. Typically this should be done in a way that ensures the common secret is not recoverable later, even if the secrets of the client and/or server are at some point compromised. This principle is called Perfect Forward Secrecy and is typically achieved by using finite field Diffie-Hellman (see also --dh) or Elliptic-curve Diffie–Hellman. TLS 1.3 typically uses ECDH with the X25519 curve for the key agreement.

To achieve perfect forward secrecy with post-quantum a hybrid ECDHE-MLKEM Key Agreement is used. Examples are X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024. Typically X25519MLKEM768 is used.

OpenVPN version 2.7.0 and newer will display the key agreement in use during connection:

Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, [...], key agreement: X25519MLKEM768

The allowed key-agreement can be configured using the --tls-groups configuration options. E.g. using

tls-groups X25519MLKEM768

will only allow connections that use this post-quantum safe key-agreement. A connection that cannot fulfill this requirement will fail similar to this:

OpenSSL: error:0A000065:SSL routines::no suitable key share:

This also requires OpenVPN to be used with a TLS library that supports these new key-agreement algorithms like OpenSSL 3.5.0.

Using a post-quantum key-agreement is also what currently (in 2025) people are talking about when they are talking about software that includes post-quantum crypto.

Post-quantum signing/certificates

Asymmetric algorithms are used in two major use cases in OpenVPN - verification of identity using certificates, and in the key-agreement for encryption. It is much more critical to focus on the post-quantum key-agreement now. Especially for a TLS/VPN connection where verification of certificates is only needed during the connection itself, and being able to verify signatures and identity later is at least currently of lesser concern. So at least at the moment, the urgency here is not as big as for the key-agreement.

But creating certificates with post-quantum algorithms is also possible. E.g. creating a self-signed certificate that is usable with --peer-fingerprint using the ML-DSA-65 algorith can be created using OpenSSL (3.5.0 or later):

openssl req -x509 -newkey ML-DSA-65  -keyout styx-mldsa-65.key -out styx-mldsa-65.key -nodes -sha256 -days 3650 -subj '/CN=styx-mldsa-65'