Home A - Z
Page Index

An Otter Wiki

Post-quantum cryptography security in OpenVPN

In general symmetric ciphers (AES-GCM, Chacha20-Poly1305) that are used for data-channel encryption are still safe to use in post-quantum cryptogrpahy. No change is necessary in this area.

The cryptographic algorithm that are affected are the assymetric algorithms that in use. 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)

tls-crypt and tls-crypt-v2 work by protecting the whole control channel and the TLS handshake inside control channel with a pre-shared key. Often this kind of protection is called "poor man's post quantum cryptogrpahy".

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 the 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 done in a way that the common secret is not recoverable later, even if the secrets of the client and/or server are at some point compromised. This priniciple is called Perfect Forward Secrecy and typically achieved by using finite field Diffie-Hellmann (see also --dh) or Elliptic-curve Diffie–Hellman. TLS 1.3 typically use the ECDH with the X25519 curve for the key agreemnt.

For achieving perfect foward 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 fulfil this 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 talking about software including post-qunatum crypto.

Post-quantum signing singing/certificates

Having post-quantum key-agreement is much critical right now. Especially for a TLS/VPN connection where verification of certificates is only needed for 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 it is for the key-agreement.

But creating certificates with post-quantum algorithm is also possible. E.g. creating a self-signed certificate that is usable with --peer-fingerprint using the ML-DSA-65 algorith cna be done 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'