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 being used.
+
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)
@@ 11,9 10,7 @@
# 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".
+
OpenVPN has two channels for communication - the control channel and the data channel. The control channel is where authentication and key exchanges occur, 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:
@@ 23,19 20,9 @@
# 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
TLS 1.3 typically uses ECDH with the X25519 curve for the key agreemnt.
+
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](https://de.wikipedia.org/wiki/Perfect_Forward_Secrecy) and is typically achieved by using finite field Diffie-Hellman (see also `--dh`) or [Elliptic-curve Diffie–Hellman](https://en.wikipedia.org/wiki/Elliptic-curve_Diffie–Hellman). TLS 1.3 typically uses ECDH with the X25519 curve for the key agreement.
-
For achieving perfect foward secrecy with post-quantum a
-
[hybrid ECDHE-MLKEM Key Agreement](https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/) is
-
used. Examples are X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024. Typically X25519MLKEM768
-
is used.
+
Pre-sharing the keys as is done with tls-crypt and tls-crypt-v2 is not perfect forward secrecy, although the key exchange occuring inside of the control channel is. For achieving perfect forward secrecy with post-quantum a [hybrid ECDHE-MLKEM Key Agreement](https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/) 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:
@@ 45,22 32,17 @@
tls-groups X25519MLKEM768
-
will only allow connections that use this post-quantum safe key-agreement. A connection that cannot fullfil this will
-
fail similar to this:
+
will only allow connections that use this post-quantum safe key-agreement. A connection that cannot fulfill this requirement will fail similar to this:
This also requires OpenVPN to be used with a TLS library that supports these new key-agreement algorithms like
-
OpenSSL 3.5.0.
+
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-quantum crypto.
+
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
-
Having post-quantum key-agreement is much more 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.
+
Having post-quantum key-agreement is much more 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 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):
